Is it possible to configure libvirt's MAC generation?

Peter Crowther peter.crowther at melandra.com
Fri Jun 12 17:28:23 UTC 2020


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 <arequipeno at 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!
> ========================================================================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20200612/c0667fed/attachment.htm>


More information about the libvirt-users mailing list