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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
