Instance Types and Features

Provide a feature that gives users the ability to view and manage server component and firmware versions through both the API and Metal Console. Specifically, users will be able to view the current firmware version of each server component through the API and the Customer Portal, giving them greater visibility and control over their systems. In addition, users should be able to update the firmware version of each server component through the API and the Metal Console, simplifying the process of managing and maintaining system firmware. This will allow users to quickly and easily update their firmware versions to the latest available release, ensuring that their systems are secure and up-to-date.

Users want to access Equinix Metal for trials, learning, demos, testing, and general exploration but without the high cost of "big iron" production gear. Smaller bite-sized config Subsidized if possible Reduced SLA and other considerations (e.g. bandwidth limitations) Technical support and content focused on users, not companies Basically a really cool homelab, but sitting at Equinix and paired with all the cool platform features, automation, and advanced networking features.

Currently, iPXE requires iPXE definitions files to be available on a public web server. This means the system will need to be exposed publicly.

Currently when using your own subnet for provisioning an instance, the API will allow you to select the elastic IP block but it does not provide the option to specify a range within that block. For example let say a customer has a /30 IP block containing 4 IPs. When the whole block is available, they would like to use the second /31 available in that block instead of the first. We should add a dropdown list that dynamically changes as the customer selects the subnet size, for example if they select /31 subnet size the drop down list will show both blocks available within the /30 elastic IP block that the customer can specify to use. The improvement should be similar to what we currently offer when attaching an Elastic IP to an instance where it shows all the available blocks within an Elastic IP subnet.

There is no way for a customer to use the API to be able to identify what NICs are on what hardware. It would be awesome to be able to give our customers/partners the ability to identify the specific NIC hardware via an API command. Currently the work around some customers are using is to deploy a server and run a lspci on the network via linux for every machine they want to identify the NIC for.

Enable customers to order Cisco Meraki vMX on Network Edge Marketplace

I'd love to have 256-way servers available, for maximum performance. These would be incredibly competitive, surpassing the best available offerings from AWS and GCP at the moment (whose normal offerings top out at 96 and 224 CPUs respectively). While I'm sure some applications will want a huge amount of memory to go with that, in my case I'd be happy with around 2GB per CPU. It'd likely make sense to have a "high compute" version in that range, as well as an offering with 4+GB per CPU for more memory-intensive workloads.

Refering VMware KB, when accesing to ESXi you can switch between DCUI/Console using [ALT+F1] key. https://kb.vmware.com/s/article/2148363?lang=en_us But in out-of-band console metal access to ESXi, it seems the keys don't work and only DCUI can be used. Of course SSH connection can be used instead under normal conditions, but I assume their are possible situations in which SSH connection cannot be established, such as switch failure on the upper level of the Metal server, or incorrect NW settings put into the ESXi. In those cases out-of-band console operations are needed to check status and operate virtual machines, or recover Network. Therefore it will be good if there is a way to execute console operations out-of-band in ESXi.

Support dedicated Hitachi storage appliances in Metal

Enable customers to order Arista SDWAN device on Network Edge Marketplace (Note Arista CloudEoS already on NE marketplace)