Before this patch, the XML sent to virDomainAttachDeviceFlags() was parsed once, with the resulting object added to both the live and config domain objects. After this patch, the incoming XML is parsed twice, and thus the MAC address (if unspecified in the XML) is autogenerated twice. The result is that the device that shows up in the running guest has MAC address "A", but when the guest is shut down and then restarted, the device has MAC address "B". Since guest OS network device configuration is often based on MAC address, this means that the newly minted guest network config is now incorrect. How to reproduce: 1) create this file as /tmp/if.xml: <interface type='network'> <source network='default'/> </interface> 2) add this device to a running domain: # virsh attach-device MuhGuest /tmp/if.xml --live --config 3) note the MAC address of the new device # virsh dumpxml MuhGuest | grep "mac address" 4) shutdown the guest. # virsh destroy MuhGuest 5) start the guest # virsh start MuhGuest 6) note the *different MAC address of the new device # virsh dumpxml MuhGuest | grep "mac address"
This is caused by upstream commit 55ce6564634, which was the response to Bug 1559867, and first appeared in libvirt-4.6.0. (It also coincidentally fixed Bug 1664324, and you can see my first report of the regression described in *this* BZ in Bug 1344899 Comment 33.) There was much discussion over several months about the "proper" way to fix this (and the general problem of maintaining consistency between live and config data), but the discussion was aiming too high (my opinion), leading all proposals to fail. Today in a discussion on IRC, danpb suggested that we just continue to parse the XML twice (once for --live and once for --config), and simply add in a small hack to copy the MAC address from one to the other after the parsing but before the new device is added to the object. This is slightly ugly (again my opinion), but is also simple.
Patch sent upstream: https://www.redhat.com/archives/libvir-list/2019-December/msg01071.html
Pushed upstream. Will be in libvirt-6.0.0 commit 6c17606b7cce7bf77baef956bde8a0b056666011 Author: Laine Stump <laine> Date: Tue Dec 17 10:24:00 2019 -0500 qemu: homogenize MAC address in live & config when hotplugging a netdev
Verify this bug with libvirt-daemon-6.0.0-4.module+el8.2.0+5642+838f3513.x86_64: 1. prepare a running guest: virsh list Id Name State ---------------------- 2 vm1 running 2. hotplug and coldplug a vNIC device: # cat net.xml <interface type='network'> <source network='default'/> </interface> # virsh attach-device vm1 net.xml --live --config Device attached successfully 3. check both live and inactive xml: # virsh dumpxml vm1 --inactive |grep -A5 network <interface type='network'> <mac address='52:54:00:ca:4a:f9'/> <source network='default'/> <model type='rtl8139'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> # virsh dumpxml vm1 |grep -A5 network <interface type='network'> <mac address='52:54:00:ca:4a:f9'/> <source network='default' portid='48804a58-6650-40ee-8fd7-80a9600e5d93' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> 4. destroy and start guest # virsh destroy vm1 Domain vm1 destroyed # virsh start vm1 Domain vm1 started 5. check mac address and make sure not changed: # virsh dumpxml vm1 |grep -A5 network <interface type='network'> <mac address='52:54:00:ca:4a:f9'/> <source network='default' portid='6db356ed-7e30-45d0-9dbd-78e0ad007b95' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2017