Is it possible to configure libvirt's MAC generation?
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! ========================================================================
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@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! ========================================================================
On 6/12/20 12:28 PM, Peter Crowther wrote:
Specify the MAC address as part of the domain XML for the bootstrap node. See https://libvirt.org/formatdomain.html#elementsNICS.
Unfortunately, the domain XML is created by the OpenShift installer, over which I have no control. :-( Digging into the libvirt source, it doesn't look like there's any way to configure MAC address generation. I'm now investigating whether I can mangle the source MAC of the outgoing DHCP packets with ebtables. Uugh. -- ======================================================================== In Soviet Russia, Google searches you! ========================================================================
One solution would be to dump the XML for the domain and then run something like sed on it to change what ever you want and then update the domain. Of course that will only work if the domain is stopped. On 6/12/20 2:00 PM, Ian Pilcher wrote:
On 6/12/20 12:28 PM, Peter Crowther wrote:
Specify the MAC address as part of the domain XML for the bootstrap node. See https://libvirt.org/formatdomain.html#elementsNICS.
Unfortunately, the domain XML is created by the OpenShift installer, over which I have no control. :-(
Digging into the libvirt source, it doesn't look like there's any way to configure MAC address generation. I'm now investigating whether I can mangle the source MAC of the outgoing DHCP packets with ebtables.
Uugh.
-- Alvin Starr || land: (647)478-6285 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
On Fri, Jun 12, 2020 at 02:18:13PM -0400, Alvin Starr wrote:
One solution would be to dump the XML for the domain and then run something like sed on it to change what ever you want and then update the domain. Of course that will only work if the domain is stopped.
Another one is to use the virt-xml tool to update only the part you need: virt-xml <domain> --edit --network network=default,mac.address='<new_mac>' ^This would require you to restart the domain for the change to take effect. virt-xml <domain> --update --remove device --network mac.address='<old_mac>' virt-xml <domain --update --add-device --network network=default,mac.address='<new_mac>' ^This would not, because it translates to hot-unplug and hot-plug respectively. Just an alternative to using sed. Regards, Erik
On 6/15/20 03:45, Erik Skultety wrote:
On Fri, Jun 12, 2020 at 02:18:13PM -0400, Alvin Starr wrote:
One solution would be to dump the XML for the domain and then run something like sed on it to change what ever you want and then update the domain. Of course that will only work if the domain is stopped.
Another one is to use the virt-xml tool to update only the part you need:
virt-xml <domain> --edit --network network=default,mac.address='<new_mac>'
^This would require you to restart the domain for the change to take effect.
virt-xml <domain> --update --remove device --network mac.address='<old_mac>' virt-xml <domain --update --add-device --network network=default,mac.address='<new_mac>'
^This would not, because it translates to hot-unplug and hot-plug respectively.
Just an alternative to using sed.
Regards, Erik
Just a reminder that it's generally a very bad idea to regex XML[0]. :) Cheers! [0] https://stackoverflow.com/a/1732454/733214 -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
participants (6)
-
Alvin Starr -
brent s. -
Erik Skultety -
Ian Pilcher -
Marc Roos -
Peter Crowther