Re: [libvirt] [PATCH] qemu: Use legacy USB on ppc64

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