On Tue, 2017-03-07 at 16:35 +0100, Pavel Hrdina wrote: > > If I look at qemu-system-ppc64 -usb, that provides an 'nec-xhci' device. > > > > I'm curious why libvirt picked pci-ohci ? Was -usb previously providing > > a pci-ohci device instead of nec-xhci ? > > We switched from -usb to -device in Libvirt 1.3.1 but we start to record > the default model in XML in Libvirt 2.2.0 (yes it should have been done > in the Libvirt 1.3.1). So probably in the time of Libvirt 1.3.1 the default > in Qemu was pci-ohci but they've probably switched to nex-xhci as they > decided that they will not fix the issues with pci-ohci. Yup, the switch from pci-ohci to nec-usb-xhci as QEMU default happened about a year ago for that very reason, see https://bugzilla.redhat.com/show_bug.cgi?id=1284333 > > I guess the thing that could justify the switch is that we don't guarantee > > what default devices you'll get for any given guest. It is dependent on > > the particular version of the machine type used. So in that sense if you > > have an XML doc which is not fully populated with device info, you are > > already liable to see changes in default devices based on which QEMU > > you happen to define the XML against first. > > I agree with that, if you let Libvirt to chose some default you probably > don't care that much what the default will be. I completely agree with the argument in general. That said, libvirt should only make the choice *once* and store it in the guest XML, which is something that releases between 1.3.1 and 2.1.0 unfortunately neglected to do. If at all possible, guests created using one of the affected releases should not be changed at all, even though switching from pci-ohci to nec-xhci is something that I don't expect would actually break any guest. > > > There is a concern whether we should allow ABI change for persistent > > > migration which is more general issue that will affect some other changes > > > that are already "allowed" for persistent migration. I'm starting to feel > > > that we should remove the "VIR_DOMAIN_DEF_PARSE_ABI_UPDATE" from > > > "virDomainDefParseNode" call in "qemuMigrationCookieXMLParse" function > > > which currently allows to do ABI changes for persistent migration. I think we should really think hard about this and possibly change our current approach. While it might be true that offline migration doesn't have quite as restrictive requirements as live migration, that doesn't mean we should be updating the guest ABI willy-nilly. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
