This is part of a series of posts about my experience working with OpenShift and CNV. In this post, I’ll look at how the recently released CNV 2.4 resolves some issues in managing virtual machines that are attached directly to local layer 2 networks

In an earlier post, I discussed some issues around the management of virtual machine MAC addresses in CNV 2.3: in particular, that virtual machines are assigned a random MAC address not just at creation time but every time they boot. CNV 2.4 (re-)introduces MAC address pools to alleviate these issues. The high level description reads:

The KubeMacPool component provides a MAC address pool service for virtual machine NICs in designated namespaces.

In more specific terms, that means that if you enable MAC address pools on a namespace, when you create create virtual machine network interfaces they will receive a MAC address from the pool. This is associated with the VirtualMachine resource, not the VirtualMachineInstance resource, which means that the MAC address will persist across reboots.

This solves one of the major pain points of using CNV-managed virtual machines attached to host networks.

To enable MAC address pools for a given namespace, set the mutatevirtualmachines.kubemacpool.io label to allocate:

oc label namespace <namespace> mutatevirtualmachines.kubemacpool.io=allocate