[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [BUG] When PLUG a bridge interface to an active VM, the generated LIVE and CONFIG mac address are different

On 8/27/19 2:44 PM, Ján Tomko wrote:
On Tue, Aug 27, 2019 at 02:13:28PM +0200, Michal Privoznik wrote:
On 8/22/19 10:43 AM, Xu Yandong (Yandong Xu) wrote:

When plug a bridge interface to an active VM with both LIVE AND CONFIG flags, libvirt generate different mac address to LIVE and CONFIG instance, so After I reboot the VM, DHCP server doesn't assign the same IP address to the new
bridge interface.

This is kind of expected. In general, live and inactive XMLs can be significantly different.

Well, if the live and inactive XMLs have sufficiently diverged, then
I don't see the point of calling AttachDevice with both AFFECT_LIVE and
AFFECT_CONFIG - you might as well use two different API calls.

However for a guest with the definitions in sync, quietly accepting a
both flags while attaching a device with different MAC addresses (so
essentially two different devices) feels wrong.

And I guess it's out of libvirt's scope to try and autofill missing data in such way that fits both libe and inactive XMLs. For instance, a PCI address can be taken/free in live XML because of hotplug/hotunplug but that might not be the case for inactive XML. Should libvirt try and find a slot that suits both XMLs?

That possibly might be out of scope, but autofilling the mac address as
early as virDomainNetDefParseXML also is not ideal.

I'm failing to see how moving MAC address generation to a post parse callback would solve this issue, sorry.

But as I said in the other reply I've just sent, we are autogenerating much more than MAC addresses. And even more so for other devices.

I see two ways to fix this:
1) prefer live XML in this case and if the device with autogenerated values is not fit to inactive XML then hopefully qemuDomainAttachDeviceConfig() will fail, or

2) document this behaviour.

But aparently, my wish made in 1) is not happening, is it? The original commit 55ce65646348884656fd7bf3f109ebf8f7603494 that caused this issue claims clearly that we would generate the same address for two different devices. And nothing in our code raised the red flag. Therefore, I like 2) more. After all, if you asked libvirt to autofill some values then don't mind if it did so.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]