[libvirt] Availability of libvirt-4.6.0 Release Candidate 2

[John Ferlan]

On 08/01/2018 04:44 PM, Laine Stump wrote:
> (Let's see now.... which people were the ones who believe it's a huge
> insult to Cc them in list replies, and which are the ones who appreciate
> the Cc and use it as a flag to raise the visibility of the message in
> their mail client ..... ?????. Ah, I give up, just leaving in the Cc's
> and let the complaints fly)(For the record, I like explicit Cc's when
> you want to make sure I see something - that sends a copy to my phone,
> which can be mildly annoying if it's a series of 40 patches, but also
> very effective in getting my attention :-P)
> 
> On 08/01/2018 06:40 AM, 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?
> 
> (Let's see, you said my name once in the Cc, and once here. You really
> need to say it *three* times to get my attention ala Beetlejuice or
> Biggy Smalls. (and it helps to recite it into a mirror in a dark room,
> apparently)).
> 
>>>
>> 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?
> 
> Yeah, this has been a problem for a long time (it's also problematic
> for, e.g. the index of PCI controllers, which can cascade into
> differences in the PCI addresses of devices that are connected to those
> controllers; similar problem for other types of controllers of course).
> I think I even tried fixing it once, but the solution was inadequate.
> 
> The problem comes when someone uses a mixture of --live only, --config
> only, and --live+--config device attaches/detaches. At the base of the
> problem is the fact that the live and config domaindef objects are
> stored completely independent of each other, and the code that assigns
> PCI addresses "seeds" the list of in-use address from a single domaindef
> object. Perhaps we need to merge these into a single object where each
> device is marked as "live", "config" or "both" - then any new device
> added would be guaranteed to not conflict with any existing device in
> live or config - the unified device list would be used to determine what
> addresses are used, and the new device would just be added once to one
> domaindef object (just with live and config flags set) so there would be
> no need to copy it.
> 
> Or, well..., after about 30 seconds of thought I realize this would lead
> to different behavior if someone e.g. deleted a currently-active device
> only from the config, then wanted to add that same device back again -
> the re-added device would end up with a different PCI address. So maybe
> that isn't the right solution either.
> 
> At any rate, there is no perfect solution in sight for the current
> release, so the question is whether the new (bad) behavior is better or
> worse than the old (also bad) behavior. My understanding is that the old
> behavior could lead to a config that had two devices at the same PCI
> address, which is definitely undesirable. The new behavior could lead to
> the PCI address of a newly-added device being different the next time
> the guest is shutdown and restarted. I would tend to prefer the latter,
> with the caveat that this new behavior provides a config that works
> (from libvirt's domain parsing POV), but might create a strange error in
> the guest that would be extremely difficult to troubleshoot (especially
> 6 months from now after we've all forgotten about this patch (and
> forgotten about the idea that a more complete fix was needed).
> 
> So I'm undecided about my opinion. And when undecided I tend toward
> inaction. Now *that's* helpful, isn't it?
> 

Laine is stumped ;-).

I'm still stumped over what strange error could be created. How is the
virtual {PCI|SCSI} address changing any different from "real hardware"
if someone adds something new into their physical system? Or the other
fun adventure, a physical move from location A to location B where
someone "forgot" to properly label what went where and upon reassembly
things are ordered differently.

Consider some (perhaps not so) long ago SCSI devices where you'd need to
grab a small, sharp, pin like object to toggle switches to define the
address for the device when it got plugged in. That means the user had
to guess and figure out what address to use. Good luck if you conflicted
with something else. After some time it was also difficult to tell which
end was the low address toggle/bits.

Still, while SCSI/PCI addresses were one part of the question - I think
the second concern was that for the "live & config" case - the
unprovided MAC would be different as well. What kind of problems could
that lead to?

John