Re: [libvirt] [PATCH] qemu: Add USB and memory balloon by default for aarch64/virt guests
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.