W dniu 29.01.2018 o 13:04, Andrea Bolognani pisze: >> This doesn't really help nova in practice, because it needs to operate >> correctly with pre-existing libbvirt releases, and even on x86 it should >> not be relying on the default USB1 controller, but rather adding a USB2 >> or USB3 controller. > Right. Nova should still be fixed to explicitly opt in to the USB > controller regardless of libvirt's defaults, as per the above. I wrote a patch for Nova to do that [1]. Have to test. But the problem is that Nova creates XML with domain definition and give it to libvirt. Which expects 'qemu-xhci' or 'nec-xhci' for XHCI USB Host. If I want to play nice I have to go for 'nec-xhci' because it works with Qemu 2.8 while (much better) 'qemu-xhci' requires Qemu 2.10 version. What IMHO libvirt should support is "generic-xhci" controller which would be 'qemu' or 'nec' as libvirt knows which Qemu version it deals with and I have no idea is there a way to find that data in higher layers (like Nova). 1. https://review.openstack.org/#/c/538003/ Software compatibility is a bitch. Layering does not make it easier. In Nova code I can not do "exec('qemu-system-aarch64 --version') as 'nova-compute' container does not even have that binary installed - in 'kolla' based deployments it exists in 'nova-libvirt' image. In Nova I do not know is 'qemu-xhci' available as it is neither in 'virsh capabilities' nor 'virsh domcapabilities' output. In Nova I can not say "libvirt: please give me best-available xhci" as there is no way for it. And even if it gets added then I can not use it because people may not have latest one. In Nova I prefer to add 'nec-xhci' usb host controller to be sure that I will get working usb without checking which libvirt/qemu versions I have. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
