[libvirt] Availability of libvirt-4.6.0 Release Candidate 2

[Peter Krempa]

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 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.


> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180802/edf76486/attachment-0001.sig>