[libvirt] [PATCH] qemu: Add USB and memory balloon by default for aarch64/virt guests

[Marcin Juszkiewicz]

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.