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

[Michal Privoznik]

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:
>>> Hi,
>>>
>>> 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.

Michal