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

Daniel P. Berrange posted 5 patches 6 years, 4 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20171220164750.26419-1-berrange@redhat.com
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
[libvirt] [PATCH 0/5] Proof of concept for libvirt_qemu shim process
Posted by Daniel P. Berrange 6 years, 4 months ago
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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list