[libvirt] Availability of libvirt-4.6.0 Release Candidate 2

[John Ferlan]

On 08/02/2018 03:57 AM, Peter Krempa wrote:
> On Wed, Aug 01, 2018 at 17:44:56 -0400, John Ferlan wrote:
>> On 08/01/2018 04:44 PM, Laine Stump wrote:
> 
> [...]
> 
>>> 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
> 
> Well, the issue is that you issue an API to add the device, which in
> real life would translate into plugging it into the machine.
> 
> Afterwards you turn the machine off and back on. Without any API (or
> physical contact) you expect that the hardware will not move places by
> itself.

If you chose the address yourself, then it wouldn't change. IOW: If I
physically plugged into a specific spot, then no change.

But in this case, the consumer said, I don't care, choose one for me and
we did. If the consumer said LIVE and CONFIG every time, then I'd
venture to guess/assume since the algorithm is the same that the
resulting libvirt chosen address would be the same.

The problem comes when the same customer chooses CONFIG (or LIVE) at
least once before choosing CONFIG & LIVE in a followup.

> 
> If the API call includes both AFFECT_LIVE and AFFECT_CONFIG we should
> make sure that the device plugged in is exactly the same. If they are
> issued separately we don't care at all though.
> 
> Btw, having this analogy, specifying only AFFECT_CONFIG is probably
> similar to putting a post-it note on top of the power button for the
> next person to attach the hardware prior to powering it up.
> 

Given the same physical situation of leaving a post-it note to plug this
thing in later into slot 3, but someone comes after the note is written
but before the power button is pressed and plugs something else into
slot 3 because it was just "next", then when it comes time to act upon
the post-it note where does said person plug this into since slot 3 is
taken?  Do they unplug whatever was plugged into slot 3, plug the
post-it note thing into slot 3 and then plug the other thing into slot 4
or do they just plug the post-it note device into slot 4.  I'd say it's
a coin flip and no worse than what we'd be doing. Conversely, if that
person plugging in live read the note and then chose slot 4, then when
it comes time to act upon the post-it note to plug at slot 3, everyone
is happy.  Of course in this case, we had a human deciding to "assign"
the addresses to specific devices or in XML terms provide the <address>
to assign the device rather than deciding upon the next available slot.

John

> 
>> 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.
> 
> Note that in that era it would be very bad in some cases when the
> hardware would change the jumper configuration by itself as sometimes
> the drivers could not autoconfigure. The addresses were put in config
> files.
> 

Still trying to picture how "hardware would change the jumper
configuration by itself" without any human interaction. Those toggle
switches and connectors were a pain to deal with if you didn't have the
right tools. If only the hardware would have done it by itself, then we
wouldn't need the jumpers or toggle switches.