Re: Making QEMU easier for management tools and applications

[Christophe de Dinechin <dinechin@redhat.com>]

> On 7 Jan 2020, at 13:57, Kevin Wolf <kwolf@redhat.com> wrote:
> 
> Am 07.01.2020 um 11:55 hat Michal Privoznik geschrieben:
>> On 1/7/20 10:36 AM, Kevin Wolf wrote:
>>> The easy way out would be tying libvirt to a specific QEMU version. And
>>> I'm only half joking.
>>> 
>>> If libvirt didn't exist yet and we needed a management library for QEMU,
>>> what we would build now would probably not look much like libvirt looks
>>> today. We wouldn't try to have basic support for every hypervisor out
>>> there, but integrate it much closer with QEMU and avoid much of the
>>> backwards compatibility requirements that the interface between QEMU and
>>> libvirt has (which requires us to deal with compatibility twice for
>>> everything).
>> 
>> By doing this, you would force your consumers to implement compatibility
>> layer each on their own. Freshly finished blockdev is a beautiful example -
>> OpenStack, oVirt and whatnot - they all are/can use blockdev without even
>> noticing, because the API provided by libvirt is stable and provides
>> abstraction, i.e. you don't need to change anything in your domain XML to
>> use blockdev.
> 
> Yes and no.
> 
> You could still keep using the same abstraction that libvirt has always
> used while doing this. What my imaginary newly written management
> library would do differently isn't necessarily the interface between
> libvirt and applications, but getting rid of backwards compatibility
> requirements in the interface between QEMU and libvirt.
> 
> But of course, blockdev isn't even a feature per se. It's getting the
> abstraction right so that it's actually abstract enough to represent
> everything. As long as libvirt keeps using an abstraction that is based
> on simplistic setups, it won't be able to expose the full feature set of
> QEMU. This is less than satisfying. In the long run, libvirt will have
> to extend its abstraction to make full use of new features either way.
> 
>> Of course, you can apply the argument one more time and have mgmt
>> application tied to a specific version of qemu. But even that is not
>> good enough, because with backports version is just meaningless
>> number.
> 
> I think this would be too much indeed.
> 
>>> Maybe it would even be part of the QEMU repository, allowing a single
>>> patch series to implement a new feature in the system emulator and
>>> expose it in the API immediately instead of waiting for the next QEMU
>>> release before libvirt can even think about implementing support for it.
>> 
>> Thing is, it's not just qmp that a mgmt application has to master, it's also
>> process managing (and with growing number of helper binaries this is not as
>> trivial as fork() + exec()). This would need to be the bare minimum your API
>> layer has to provide to be consumable by anybody.
>> But then you have some advanced subsystems to take care of (CGroups,
>> SELinux, etc.) which are used heavily by OpenStack. oVirt and friends.
> 
> Someone has to do this anyway. Note that here I'm still talking about
> the hypothetical case where no libvirt existed yet.
> 
> If we cared only about OpenStack, oVirt and friends, this would still
> all be QEMU-based, so not a big problem to have it tied to QEMU.
> 
> I'm not sure what this looks like in practice in libvirt: Are these
> components shared between multiple hypervisor interfaces or is it only
> for QEMU anyway?
> 
> If multiple hypervisors make use of it, how crazy would it be to imagine
> reversing which project consumes which? Instead of having the libvirt
> core consume the hypervisor-specific sublibraries, could a QEMU-specific
> part live closer to QEMU and consume the libvirt core as an external
> library?
> 
> I guess much of what I write in this thread is pure heresy. :-)
> Maybe most of it isn't even useful. But maybe there is an idea or two in
> it that are worth having a closer look at.

Well, I don’t know if it is heresy, but at least as far as sandboxing / jailing
is concerned, I suggested something similar in earlier iterations of
the discussion. My way to say that I am part of your heresy, I guess.

> 
>>> So should libvirt move in that direction? Do people actually still make
>>> much use of its multi-hypervisor nature, or would it make sense to split
>>> it into separate libraries for each hypervisor that can be much tighter
>>> integrated with (a specific version of) the respective hypervisor?
>> 
>> Truth to be told, I don't think libvirt is held back by its attempts to
>> provide hypervisor agnostic APIs. Sure, it leads to some weirdness (e.g.
>> different naming in libvirt and qemu), but as a libvirt developer I don't
>> remember feeling blocked by this multi-hypervisor nature (not to mention
>> that this has saved us couple of times).
> 
> I would imagine so, because the problem doesn't become visible in the
> daily work, but only in the bigger picture: The other hypervisors are
> what prevent libvirt from being more tightly intergrated with QEMU.
> 
> This means that there is a boundary between QEMU and libvirt that makes
> it really slow to get new features to the user. And both QEMU and
> libvirt waste a lot of time for maintaining backwards compatibility in
> things that wouldn't necessarily have to be stable interfaces if the
> management library were developed in lockstep with QEMU.
> 
>> Also, it would be not correct to think that a feature is implemented for all
>> hypervisors in libvirt. I mean, when implementing a feature I usually
>> implement it only for qemu driver and don't even look at other drivers
>> (unless I'm doing a change in a core that causes build failures). On the
>> other hand, I do sometimes review patches posted by developers from other
>> companies which have interest in different hypervisors (e.g. there is a SUSE
>> guy working on LXC driver, and another SUSE guy working on libxenlight
>> (basically Xen)), so I do spend some time not working on qemu driver, but
>> I'd say it's negligible.
> 
> Time spent on non-QEMU isn't really my concern. Time spent maintaining
> stable interface between QEMU and libvirt, and time spent waiting for
> QEMU releases before libvirt development starts are my concern.
> 
> Kevin