Re: [libvirt] [PATCH 8/9] qemu: domain: Reflect USB controller model in guest XML
On Thu, 2016-08-04 at 14:32 +0200, Ján Tomko wrote:
> + } else if (cont->type ==
VIR_DOMAIN_CONTROLLER_TYPE_USB &&
> + cont->model == -1) {
> + /* Pick a suitable default model for the USB controller if none
> + * has been selected by the user.
> + *
> + * We rely on device availability instead of setting the model
> + * unconditionally because, for some machine types, there's a
> + * chance we will get away with using the legacy USB controller
> + * when the relevant device is not available.
> + *
> + * See qemuBuildControllerDevCommandLine() */
> + if (ARCH_IS_PPC64(def->os.arch)) {
> + /* Default USB controller for ppc64 is pci-ohci */
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PCI_OHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PCI_OHCI;
<thinking_out_loud>
So, if I understand correctly, if we left the model for PPC64 at -1:
[A] before 8156493 Fix USB model defaults for ppc64 [v1.3.1-rc1~47]
we pass -usb on the command line, drop the controller from migration
XML and possibly re-add it on the destination
[B] after that commit
we pass -device pci-usb-ohci, lose that information in migration
[C] after 192a53e0 send default USB controller in xml [v1.3.5-rc1~459]
We use -device pci-usb-ohci, passing the address to the
destination
Migration between [A] and anything else is AFAIK broken since the
address used by -usb never matches the one we pick for the -device,
https://bugzilla.redhat.com/show_bug.cgi?id=1357468
Migration between [C] and [B] should just work as long as hotplugging
did not change the order of the devices and the controller auto-added on
the destination gets the same address as the one that was removed.
You mean between [B] and [C]? When migrating between [C] and
[B], the destination will receive the <controller> element,
including the PCI address, so it should have no problem just
using it.
</thinking_out_loud>
Is it possible to create a -device syntax that will match the -usb
command line generated by [A] (e.g. by specifying a 0000:00.00 PCI
addr)?
Yes, something like
-device pci-ohci,id=usb,bus=pci.0,addr=0x0
will work for QEMU, but we have no way of representing that in
the guest configuration:
<address type='pci'
domain='0x0000' bus='0x00'
slot='0x00' function='0x0'/>
will result in libvirt assigning a new PCI address for the
device in recent libvirt versions, and an outright error in
older libvirt versions, including [A].
Assuming that we made it possible to specify such an address,
it would be impossible for the target of the migration to make
out whether the migration is coming from [A] or [B] - one of
the two would be broken anyway.
This change should fix migration from [B] and [C] and back:
* model=-1 coming from those hosts will get adjusted to OHCI on parsing
* we should not format model=-1 when migrating back to those hosts
Migration between [B] and [C] should already work in both
directions AFAICT. Can you give me an example where it
wouldn't?
> + } else {
> + /* Default USB controller for anything else is piix3-uhci */
> + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_PIIX3_USB_UHCI))
> + cont->model = VIR_DOMAIN_CONTROLLER_MODEL_USB_PIIX3_UHCI;
For non-PPC64, migration was not broken before.
Ancient QEMUs not supporting QEMU_CAPS_PIIX3_USB_UHCI will still get
model=-1 (or not, I doubt anyone will run new libvirt with them).
Should we set it unconditionally for i440fx machines?
Everything else gets the model changed to PIIX3-UHCI.
I think we still want to make a last-ditch effort to provide
some sort, any sort, of USB controller. Or rather, that we
have to. Honestly, I'd rather just drop the -usb handling
altogether and expect users not to mix modern-day libvirt
with QEMU versions from 5+ years ago.
Of course, this breaks migration to pre-0.9.x libvirt which did not
support USB controllers. I am okay with that, but you might want to get
a second opinion on that.
How far back can you reasonably expect to migrate a guest? How
would you even migrate a guest that uses USB controllers to a
version of libvirt that doesn't support USB controllers?
--
Andrea Bolognani / Red Hat / Virtualization