Skip to main content

Requirements

This page covers the network, hardware, and BMC requirements for the Metal3 driver, the bare-metal provisioning path this site documents in depth. Other vMetal drivers have their own network, hardware, and BMC requirements, documented separately as they become available.

Hardware requirements​

vMetal requires physical servers with out-of-band management capabilities:

  • Each server must have a BMC (Baseboard Management Controller) that supports Redfish or IPMI.
  • Each server must have a NIC configured for PXE boot with a known MAC address.
  • The control plane cluster running Metal3 and Ironic must have network access to the BMC endpoints of all managed servers.

Network requirements​

The provisioning network must be configured to allow PXE boot traffic between the DHCP server and the bare metal servers:

  • Deploy the vMetal DHCP server component for the documented PXE flow. It serves DHCP, TFTP, and HTTP boot assets and proxies traffic between IPA on the provisioning network and Ironic on the cluster network.
  • Multus CNI is required when the DHCP server pod needs a network interface on the provisioning network in addition to the cluster network. See DHCP server and Multus CNI.
  • The network must allow DHCP, TFTP, and HTTP traffic for PXE boot operations.

Metal3 distinguishes three logical network zones: BMC, provisioning, and tenant. The provisioning and tenant zones can share a segment. See Network zones for how they relate, and Connectivity requirements for the default ports and directions.

The tenant network carries Kubernetes node and workload traffic after a server finishes PXE boot. As with any Kubernetes node network, it must provide access to the tenant cluster's API endpoint and to required DNS, registry, and workload services.

BMC requirements​

vMetal supports BMC protocols through Metal3's Bare Metal Operator (BMO). Common address formats include:

  • Redfish: redfish://<host>[:<port>]/<system-id> (HTTPS, the default) or redfish+http://<host>[:<port>]/<system-id> (unencrypted, development only). Consult the server vendor for its Redfish system ID.
  • IPMI: ipmi://<host>[:<port>]. The port defaults to 623.

Avoid redfish+http:// in production. It sends BMC credentials and commands without transport encryption.

For vendor-specific drivers, boot methods, firmware constraints, and address formats, see Supported hardware in the Metal3 Bare Metal Operator documentation.

What Metal3 does over the BMC connection​

Ironic uses the BMC connection to read and change power state and to select the boot device. Hardware inventory is collected by the Ironic Python Agent (IPA) after Metal3 boots the server into the inspection ramdisk; it is not read from the BMC. The deployed BMO and Ironic stack can also configure RAID and update firmware with supported drivers and hardware, but vMetal does not currently request those operations.

Privilege scope​

Use a dedicated BMC service account with permission to read power state, power the server on and off, reset it, and set its boot device. Do not assume that a vendor's Operator role is sufficient. With an ipmi:// address, the BMO version shipped by default requests the IPMI ADMINISTRATOR privilege level. To request OPERATOR instead, append ?privilegelevel=OPERATOR to the BMC address and verify all lifecycle operations against your firmware. Redfish role names and permission mappings vary by vendor. RAID and firmware configuration, if used outside vMetal's current automation, can require broader permissions.

Redfish versus IPMI​

Redfish is the more modern, more consistently structured protocol. Prefer it when your hardware supports it. Redfish conformance varies by vendor and firmware version, so confirm that the BMO address scheme and features you plan to use, such as virtual media, support your hardware. IPMI is older and exposes fewer capabilities through BMO's generic IPMI driver; for example, that driver does not provide RAID or firmware interfaces.

Self-signed or vendor-issued BMC certificates are common. See Disable certificate verification for how to handle them without disabling TLS verification in production.

Handoff checklist for a data center or colocation provider​

Share this checklist with whoever racks and cables the servers, if that isn't your own team.

  • Each server has a BMC reachable from the control plane cluster, over Redfish or IPMI.
  • Dedicated BMC service accounts have the power and boot-device permissions described above; any IPMI privilege-level override has been tested.
  • Each server's PXE NIC and its MAC address are documented.
  • The provisioning network allows DHCP, TFTP, and HTTP traffic, per Connectivity requirements.
  • Each server can fetch its OS image URL over HTTP or HTTPS without credentials supplied separately from the URL.
  • The tenant network can reach the tenant cluster API endpoint and required DNS and registry services.
  • The BMC network is reachable from the control plane cluster, on its own segment or routed as required.
  • Cabling for the BMC, provisioning, and tenant networks is documented per server, especially where they run on separate physical NICs.

Platform requirements​

  • vMetal requires an active vCluster Platform installation with a license plan that includes vMetal.
  • The control plane cluster where Metal3 and Ironic are deployed must be connected to the platform.
  • BareMetalHost resources and their associated Secrets must be in the same namespace as the Metal3 components.

Provisioning constraints​

  • Servers in error state require manual investigation. Check the BareMetalHost status conditions for details.
  • Provisioning a server involves a full PXE boot cycle, which takes longer than VM-based provisioning. Expect several minutes depending on hardware, network speed, and OS image size.
  • The OS image must be reachable over HTTP or HTTPS from the bare metal server itself, not just from the control plane cluster. The server's IPA downloads it directly. vMetal passes the image URL and checksum to Metal3 but does not supply separate authentication headers or credentials for the download.

Managed Kubernetes restrictions​

When using managed Kubernetes services as the control plane cluster for Metal3:

  • GKE Autopilot: Not supported as a control plane cluster because of restrictions on privileged workloads and host networking.
  • EKS Auto Mode / Fargate: Not supported as a control plane cluster. Use standard managed node groups instead.
  • Ensure the managed cluster's nodes can reach the BMC network. This may require VPC peering, VPN, or direct network connectivity.