On Thu, Jul 21, 2016 at 04:56:56PM +0200, Andrea Bolognani wrote:
> On Wed, 2016-07-20 at 16:09 +0200, Andrea Bolognani wrote:
> > > It seems that we could solve this by just changing the logic in
> > > qemuDomainAssignDevicePCISlots() so that when it is auto-assigning
> > > addresses, it always uses 00:00.0 for the USB controller when guest
> > > arch is ppc64.
> > >
> > > Existing guests deployed from a libvirt version using -device won't
> > > be affected, because we'll have recorded a PCI address for that
> > > in the XML and continue to use that. ie the auto-allocation logic
> > > won't run for them.
> > >
> > > Existing guests deployed from a libvirt version using -usb should
> > > then get the fixed PCI address of 00:00.0 when they upgrade to the
> > > fix libvirt (assuming they didn't get run with a broken libvirt
> > > in between).
> >
> > Mh, that could actually work! Thanks :)
> >
> > I'll try to cook up a patch tomorrow.
>
> Unfortunately Martin pointed out a problem with this plan:
> even though they're not actually using it, old guests have
> been assigned a PCI address for the USB controller. Which
> means we can't tell whether
>
> <controller type='usb' index='0'>
> <address type='pci' domain='0x0000' bus='0x00'
> slot='0x03' function='0x0'/>
> </controller
>
> is an old guest that should be assigned the 00:00.0 address
> or a new guest that should keep using the 00:03.0 address :(
If we revert 8156493d8db95de91dd9ace743df0fd4dff98281 we'll go back to
using -usb and the PCI addr reported in the XML is just completely wrong
vs what's actually being used. If the user requests an explicit addr for
the USB controller, we'll ignore it and that could cause boot failure if
the user has requested something else in addr 00:00.0
I think we have no choice but to stick with using -device, because
that is clearly the preferred syntax long term, and it allows us to
actually honour the addresses requested in the XML, which the original
code was not doing. IOW the old code < 1.3.1 using -usb was clearly
broken, so I don't think reverting is an option we can take. Furthermore
reverting it will instead break anyone with libvirt 1.3.1 -> 2.0.0
So no matter what we do some portion of users are screwed. On balance
I think users of libvirt < 1.3.1 will just have to take the pain. We
can document a procedure to minimize that pain.
Specifically if you have libvirt < 1.3.1 and want to upgrade them
1. Use virsh save-image-edit to change the XML for all existing
saved images, and fix the PCI address slot to be 0 instead of 3.
This should allow new libvirt to load the image, since itsXML
will now reflect the reality of what was used.
2. For any running guests edit /var/run/libvirt/qemu/*.xml to
again fix the PCI address slot from 3 to 0. Then restart
libvirtd so it reloads its config. This should then allow
those running guests to be live migrated
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list