[libvirt] [PATCH 0/5] Proof of concept for libvirt_qemu shim process

This patch series provides a proof of concept impl of the libvirt_qemu shim process I previously suggested here: https://www.redhat.com/archives/libvir-list/2017-November/msg00526.html The end goal is that we'll be able to fully isolate managemen to each QEMU process. ie all the virDomain* APIs would be executed inside the libvirt_qemu shim process. The QEMU driver in libvirtd would merely deal with aggregating the views / tracking central resource allocations. This series, however, does *not* do that. It is a very much smaller proof of concept, principally to: - Learn about pros/cons of different approaches for the long term goal - Provide a working PoC that can be used by the KubeVirt project such that they can spawn QEMU in a separate docker container than libvirtd is in, and inherit namespaces & cgroup placement, etc So, in this series, libvirtd functionality remains essentially unchanged. All I have done is provide a new binary 'libvirt_qemu' that accepts an XML file as input, launches the QEMU process directly, and then calls a new virDomainQemuReconnect() API to make libvirtd aware of its existance. At this point libvirtd can deal with it normally (some caveats listed in last patch). Usage is pretty simple - start libvirtd normally, then to launch a guest just use $ libvirt_qemu /path/to/xml/file It'll be associated with whatever libvirtd instance is running with the same user account. ie if you launch libvirt_qemu as root, it'll associate with qemu:///system. By default it will still place VMs in a dedicated cgroup. To inherit the cgroup of the caller, use <resource register="none"/> in the XML schema to turn off cgroup setup in libvirt_qemu. Having written this PoC, however, I'm less convinced that a bottom up, minimal impl which incrementally picks certain subsets of QEMU driver APIs to call is the right way to attack this problem. ie I was intending to have this minimal shim, then gradually move functionality into it from libvirtd. This feels like it is going to create alot of busy-work, delaying the end goal. I think instead a different approach might be better in the short term. Take the existing libvirtd code as a starting point, clone it to a libvirt_qemu and just start cutting out existing code to make a lighter weight binary that can only run a single guest, whose XML is passed in. We would still ultimately need to deal with much of the same issues, like getting VMs reported to the central libvirtd, but I think that might get to the end result, where all APIs run inside the shim, quicker. The key difference is that we could sooner focus on the harder problems of dealing with shared resource allocation tracking, instead of doing lots of code rewiring for API execution. Daniel P. Berrange (5): conf: allow different resource registration modes conf: expose APIs to let drivers load individual config / status files qemu: add a public API to trigger QEMU driver to connect to running guest qemu: implement the new virDomainQemuReconnect method qemu: implement the 'libvirt_qemu' shim for launching guests externally include/libvirt/libvirt-qemu.h | 4 + po/POTFILES.in | 1 + src/Makefile.am | 49 ++++ src/conf/domain_conf.c | 42 +++- src/conf/domain_conf.h | 12 + src/conf/virdomainobjlist.c | 98 +++++--- src/conf/virdomainobjlist.h | 17 ++ src/driver-hypervisor.h | 5 + src/libvirt-qemu.c | 48 ++++ src/libvirt_private.syms | 4 + src/libvirt_qemu.syms | 5 + src/lxc/lxc_cgroup.c | 34 +++ src/lxc/lxc_cgroup.h | 3 + src/lxc/lxc_process.c | 11 +- src/qemu/qemu_cgroup.c | 69 +++++- src/qemu/qemu_conf.h | 2 +- src/qemu/qemu_controller.c | 551 +++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 59 ++++- src/qemu/qemu_process.c | 31 ++- src/qemu/qemu_process.h | 1 + src/remote/qemu_protocol.x | 18 +- src/remote/remote_driver.c | 1 + src/util/vircgroup.c | 55 ++-- src/util/vircgroup.h | 10 +- 25 files changed, 1046 insertions(+), 86 deletions(-) create mode 100644 src/qemu/qemu_controller.c -- 2.14.3