Specify the MAC address as part of the domain XML for the bootstrap node. See https://libvirt.org/formatdomain.html#elementsNICS.
If using virt-install, set it as part of the --network option: "--network NETWORK,mac=12:34..." - Peter On Fri, 12 Jun 2020 at 18:07, Ian Pilcher <arequip...@gmail.com> wrote: > Is it possible to configure libvirt to generate "predictable" MAC > addresses for virtual NICS? (A configuration which accomplishes this > by limiting the pool of available addresses would be acceptable for > my use case.) > > Read on for why I want to do this ... > > I have a somewhat unusual use case. I am working with the OpenShift > bare metal "IPI" installation process, which is documented here: > > https://openshift-kni.github.io/baremetal-deploy/4.4/Deployment.html > > At a high level, the installation process goes like this: > > 1. Install RHEL 8 on the "provisioner" node. > > 2. Configure a couple of bridges on the provisioner node, which will be > used by the "bootstrap VM" (see below). > > 3. Create a configuration file & do various other things. > > 4. Run the installer > > a. Installer creates a "bootstrap VM" on the provisioning node, which > does the actual work of kicking off the OpenShift installation. > The bootstrap VM runs Red Hat Enterprise Linux CoreOS (RHCOS). > > b. Bootstrap VM requests an IP address via DHCP. <====== ****** > > Step 4b is problematic in this environment. Because of routing and > firewall rules, I really need the bootstrap VM to have a predictable IP > address. > > It is possible to configure a static IP address on the bootstrap VM via > the CoreOS ignition file, and we've successfully done this, but ... > > RHCOS requests an IP address via DHCP *before* it processes the ignition > file. If this fails, it appears to simply give up. So we need to have > our DHCP server provide an address to the bootstrap VM, even if it isn't > ever used. And of course, we're not allowed to configure the DHCP > server to respond to any old MAC address that comes along; we're only > allowed to respond to known MAC addresses. > > Hopefully this all makes sense, and hopefully it explains why being > able to configure libvirt's MAC pool/sequence would allow things to work > in this environment. > > Thanks! > > -- > ======================================================================== > In Soviet Russia, Google searches you! > ======================================================================== > >
