[libvirt] Availability of libvirt-4.6.0 Release Candidate 2

[John Ferlan]

On 08/01/2018 06:47 AM, Peter Krempa wrote:
> On Wed, Aug 01, 2018 at 12:40:14 +0200, Michal Privoznik wrote:
>> On 07/31/2018 07:19 PM, Ján Tomko wrote:
>>> And I'm still unsure about leaving in
>>> commit 55ce65646348884656fd7bf3f109ebf8f7603494
>>>    qemu: Use the correct vm def on cold attach
>>> https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=55ce6564634
>>> Which means attach-device --live --config will attach an interface
>>> with a different MAC address in live and persistent definition. Laine?
>>>
>>
>> Well, It's not only MAC address that can change. The device address
>> might change too. This points to a broader problem. When we are parsing
>> a device XML we fill in the blanks in postParse callbacks. However,
>> those look only at either live or at inactive XML. Not at both at the
>> same time. So how can we fill in the blanks that would be valid for both
>> XMLs?
> 
> We can fill in the definition and then copy it and validate it
> afterwards. That way the blanks are filled and we can then validate that
> it fits into the other definition. The description here sounds that in
> this release we made things worse than it was before though.
> 
> 
Like I said in response to Jano's note after the push:

https://www.redhat.com/archives/libvir-list/2018-July/msg01736.html

if the patch is reverted that's fine.

The referenced bz is for someone that doesn't define an <address> for a
<disk> or <hostdev> (I would think a common occurrence) and the counter
concern is for someone that doesn't supply a <mac> for an <interface> (a
perhaps less common, but equally concerning condition). In one instance
(duplicated <address>) the subsequent guest boot fails. In other other
instance (difference <mac>) the subsequent guest boot has a different
mac. In both instances the <address> could be different and most likely
will be. The docs are not precise on what happens when adding a <mac> to
both --live and --config. The network docs indicate to allow libvirt to
generate the mac to "assure that it is compatible with the
idiosyncrasies of the platform where libvirt is running".

Whether someone uses --config or --live or --config and --live it's
perhaps very difficult to impossible to be able to provide a solution
that will make "everyone" happy. To say we can "copy" from one or the
other I would think is problematic since who's to say which is "more
correct" once the guest is running. Someone could add 4 devices to
--config, then 2 to --live, and then decide to add 1 to both - if they
don't supply specific addresses, then IIRC even before this patch it's
not possible to "match" the two.

Having to have <address> code look through @def and @newDef to find an
unused address that could be used for both could be a challenging
algorithm especially since SCSI <disk>'s and <hostdev>'s can live on the
same adapter. Furthermore, SCSI <disk>'s have this preference related to
the @dst target name that really could get complicated with looking at
both live and config. Perhaps this just becomes one of those "hypervisor
defined" activities (regardless of whether the patch is removed or not)
and we just move on.

John

[hopefully this makes it to the list - given the unreliability to
receive libvir-list traffic over the last 24 hours here at Red Hat /-|]