Hide Forgot
libvirt currently defaults to pci-ohci on ppc64. However, this USB controller has some issues (see Bug 1212275) that are unlikely to ever be fixed; moreover nec-xhci is USB3 as opposed to USB2, which should give better performance anyway. QEMU has already started using nec-xhci (see Bug 1284333) because of these reasons. libvirt, on the other hand, can't change its default due to the fact that up until very recently the USB controller model was not formatted in the guest configuration. oVirt should use nec-xhci by default for new ppc64 guests. Bug 1373184 has already been filed for virt-manager and related tools.
After thinking about the "bug", I think ovirt-engine is the proper place where we should add the controller. All we need is engine to send {'device': 'usb', 'model': 'nec-xhci', 'type': 'controller'} for ppc64le guests as VDSM has all the machinery to build the XML.
Final solution is still being discussed, decreasing priority.
... not any more
Please note that this is relevant also for Bug 1381184 (headless VM RFE): In case of a headless VM & the if the serial console is disabled- the usb controller should not be added while running this VM. Currently is is not supported by libvirt and usb device is always added while starting a VM, eventhough the list sent by engine doesn't include the usb device.
(In reply to Sharon Gratch from comment #4) > Please note that this is relevant also for Bug 1381184 (headless VM RFE): > In case of a headless VM & the if the serial console is disabled- Why would you want to have neither graphical nor serial console? Surely the latter should be present for headless guests. > the usb > controller should not be added while running this VM. > Currently is is not supported by libvirt and usb device is always added > while starting a VM, eventhough the list sent by engine doesn't include the > usb device. You can simply include <controller type='usb' model='none'/> in the guest XML to opt out of the default USB controller.
I suggest following solution: If (VM dialog > Console > USB Support == Enabled) original behavior remains (1 quaterion of controllers ("ich9-uhci3", "ich9-ehci1", "ich9-uhci1", "ich9-uhci2") per each started sextuple of required slots) otherwise one controller as defined in osinfo.properties per each started sextuple of required slots
this is required for 4.0 on RHEL 7.3 as well, otherwise bug 1299681 won't get fixed
On Mon, 2017-01-09 at 15:38 +0000, bugzilla@redhat.com wrote: > --- Doc Text *updated* by jniederm@redhat.com --- > If SPICE USB redirection is enabled (VM-like dialog > Console > USB Support), the behavior remains unchanged: each VM has a quadruple of usb controllers: ich9-ehci1, ich9-uhci1,ich9-uhci2, ich9-uhci3. > If SPICE USB redirection is disabled, then VM has newly USB controller as specified in osinfo-defaults.properties configuration file, i.e. it is configurable per guest operating system and effective cluster version. Previously no usb controller was send to libvirt and libvirt created a default usb controller. Why does the behavior change based on whether or not SPICE USB redirection is enabled? Is that feature only available with ICH9 controllers? > Default for all intel (x86, x86-64) operating systems is "piix3-uhci", for ppc64 systems it is "nec-xhci". Why piix3-uhci instead of ich9-* for x86 guests? Moreover, x86/q35 guests should default to nex-xhci just like ppc64/pseries guests. (And, just for the record, so should aarch64/virt guests, but I understand aarch64 might be just considered out of scope.) -- Andrea Bolognani / Red Hat / Virtualization
(In reply to Andrea Bolognani from comment #8) > On Mon, 2017-01-09 at 15:38 +0000, bugzilla@redhat.com wrote: > > --- Doc Text *updated* by jniederm@redhat.com --- > > If SPICE USB redirection is enabled (VM-like dialog > Console > USB Support), the behavior remains unchanged: each VM has a quadruple of usb controllers: ich9-ehci1, ich9-uhci1,ich9-uhci2, ich9-uhci3. > > If SPICE USB redirection is disabled, then VM has newly USB controller as specified in osinfo-defaults.properties configuration file, i.e. it is configurable per guest operating system and effective cluster version. Previously no usb controller was send to libvirt and libvirt created a default usb controller. > > Why does the behavior change based on whether or not SPICE > USB redirection is enabled? Is that feature only available > with ICH9 controllers? remove-viewer doesn't support USB 3 redirection yet, it may come with RHEL 7.4. This way a well tested set of spice compatible controllers remained untouched. > > > Default for all intel (x86, x86-64) operating systems is "piix3-uhci", for ppc64 systems it is "nec-xhci". > > Why piix3-uhci instead of ich9-* for x86 guests? From commit message of https://gerrit.ovirt.org/#/c/68923/: "piix3-uhci that as opposed to ich9-ehci1 is supposed to work properly with usb devices that require USB-1.0 like smartcard." > > Moreover, x86/q35 guests should default to nex-xhci just > like ppc64/pseries guests. (And, just for the record, so > should aarch64/virt guests, but I understand aarch64 might > be just considered out of scope.) > > -- > Andrea Bolognani / Red Hat / Virtualization
(In reply to jniederm from comment #9) > > Why does the behavior change based on whether or not SPICE > > USB redirection is enabled? Is that feature only available > > with ICH9 controllers? > > remove-viewer doesn't support USB 3 redirection yet, it may come with RHEL > 7.4. This way a well tested set of spice compatible controllers remained > untouched. > > > > Default for all intel (x86, x86-64) operating systems is "piix3-uhci", for ppc64 systems it is "nec-xhci". > > > > Why piix3-uhci instead of ich9-* for x86 guests? > > From commit message of https://gerrit.ovirt.org/#/c/68923/: > "piix3-uhci that as opposed to ich9-ehci1 is supposed to work properly with > usb devices that require USB-1.0 like smartcard." Okay, so: * x86 - no SPICE -> piix3-uhci + you're limited to USB 1.1 but you can have smartcards - SPICE -> ich9-ehci1 + you have USB 2.0 but give up smartcard support * non-x86 - nec-xhci + SPICE is not supported IIUC that means q35 guests will be stuck with USB 2.0 as well, which is too bad... Hopefully SPICE will start supporting USB 3.0 (and non-x86 architectures) soon! :)
(In reply to Andrea Bolognani from comment #10) > (In reply to jniederm from comment #9) > > > Why does the behavior change based on whether or not SPICE > > > USB redirection is enabled? Is that feature only available > > > with ICH9 controllers? > > > > remove-viewer doesn't support USB 3 redirection yet, it may come with RHEL > > 7.4. This way a well tested set of spice compatible controllers remained > > untouched. > > > > > > Default for all intel (x86, x86-64) operating systems is "piix3-uhci", for ppc64 systems it is "nec-xhci". > > > > > > Why piix3-uhci instead of ich9-* for x86 guests? > > > > From commit message of https://gerrit.ovirt.org/#/c/68923/: > > "piix3-uhci that as opposed to ich9-ehci1 is supposed to work properly with > > usb devices that require USB-1.0 like smartcard." > > Okay, so: > > * x86 > - no SPICE -> piix3-uhci > + you're limited to USB 1.1 but you can have smartcards > - SPICE -> ich9-ehci1 > + you have USB 2.0 but give up smartcard support > * non-x86 > - nec-xhci > + SPICE is not supported Yes. I just want to add that non-SPICE branches in tree above shows defaults. User can choose arbitrary controller. > > IIUC that means q35 guests will be stuck with USB 2.0 as > well, which is too bad... > > Hopefully SPICE will start supporting USB 3.0 (and non-x86 > architectures) soon! :)
4.0.6 has been the last oVirt 4.0 release, please re-target this bug.
Verified with two engines, one with x86_64 DC and one with PPC64 DC, rhevm-4.1.0.4-0.1.el7.noarch and rhevm-4.1.0.2-0.1.el7.noarch respectively. Verified that on PPC the default usb set in osinfo-defaults.properties is nec-xhci and that it's defined well in vm's xml. Checked the that the default for x86 is 'piix3-uhci' when usb support is disabled, and 4 controllers ich9-ehci1, ich9-uhci1,ich9-uhci2, ich9-uhci3 when usb support is enabled for spice console. Verified that the changing the value in osinfo-defaults.properties changes the default controller type successfully.