Re: [libvirt] [PATCH] qemu: Add USB and memory balloon by default for aarch64/virt guests
[re-added danpb to CC]
On Tue, 2018-01-30 at 22:48 +0100, Marcin Juszkiewicz wrote:
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).
libvirt will already (at least for ppc64/pseries, aarch64/virt and
x86_64/q35 guests) automatically pick qemu-xhci over nec-xhci or
USB2 controllers if the QEMU binary supports it. You don't need to
specify the model at all, just add
<controller type='usb'/>
to the XML and you'll get an optimal default; that's what I meant
when I talked about "opting in" above.
For x86/pc guests the default is still USB1 IIRC, which we might
want to change to USB2 instead - you're unlikely to want USB3 in
that case because of guest OS compatibility reasons. Still, having
to special-case a single machine type is better than trying to
figure out the model yourself every single time.
Some of the above was introduced fairly recently or has not even
made it into a release yet, so if you need your application to
work with older libvirt releases then I see two options:
* code the model selection up yourself. As you mentioned above,
there are a number of factors that make this quite tricky;
* live with the fact that your guests might end up with nec-xhci
or even a USB1 controller until libvirt has been updated to a
recent enough version. Your guests will still get *some* USB
controller with the above, so USB devices will work.
Personally I'd go for the latter, but it really depends on your
needs and constraints.
--
Andrea Bolognani / Red Hat / Virtualization