[libvirt] [PATCH 0/5] Support embedding the QEMU driver in client apps directly

Michal Privoznik mprivozn at redhat.com
Mon May 27 08:55:06 UTC 2019


On 5/17/19 2:24 PM, Daniel P. Berrangé wrote:
> This patch series proposes a new way to build a "libvirt QEMU shim"
> which supports more use cases than the previous approach from last year,
> as well as being vastly simpler to implement.
> 
> Specifically
> 
>   - We can use this to embed the QEMU driver in unit tests allowing
>     the full range of odriver functionality to be exercised during
>     *unit* testing without interfering with the host OS libvirtd.
> 
>   - Apps like libguestfs can embed the QEMU driver to allow them to
>     spawn VMs that are immediate children of their app, thus inheriting
>     process context, as well as hiding these "service VM" from the
>     main libvirtd.
> 
>     This would avoid a common irritation where libguestfs VMs suddenly
>     appear & disappear in virt-manager's VM list.
> 
>   - Apps like kubevirt could use this to eliminate the need to use the
>     RPC layer for libvirt. It can directly embed the QEMU driver giving
>     it more direct control over how it is run & again inheriting process
>     state. This is useful for kubevirt's  one VM per container model
>     where Kubernetes itself provides the aggregated view, thus making
>     libvirtd's aggregated view redundant
> 
>   - The previous shim was very much one shim == one QEMU process. This
>     new embed approach supports that of course, but there's also the
>     option to run multiple VMs if desired.
> 
>   - Using a virtual root directory for QEMU driver state meams we do
>     not need to solve the hard refactoring problem of getting the main
>     libvirtd to detect the VMs launched via the shim. They can safely
>     live independantly.
> 
>   - Thanks to the driver refactoring work it is still possible for the
>     embedded drivers to talk to main libvirtd to use the secondary
>     drivers for storage/network/etc if needed. Ideally we would allow
>     those secondary drivers to be embedded too but that's not implemented
>     here. Most important would be the secrets driver. Other drivers are
>     much less important.
> 
> Daniel P. Berrangé (5):
>    access: report an error if no access manager is present
>    libvirt: pass a root directory path into drivers
>    qemu: honour the root parameter during driver initialization
>    libvirt: support an "embed" URI path selector for QEMU driver
>    qemu: introduce a new style libvirt_qemu_shim program
> 
>   src/access/viraccessmanager.c           |  5 ++
>   src/driver-state.h                      |  1 +
>   src/interface/interface_backend_netcf.c |  1 +
>   src/interface/interface_backend_udev.c  |  1 +
>   src/libvirt.c                           | 41 ++++++++++++++-
>   src/libvirt_internal.h                  |  1 +
>   src/libxl/libxl_driver.c                |  1 +
>   src/lxc/lxc_driver.c                    |  2 +
>   src/network/bridge_driver.c             |  1 +
>   src/node_device/node_device_hal.c       |  1 +
>   src/node_device/node_device_udev.c      |  1 +
>   src/nwfilter/nwfilter_driver.c          |  1 +
>   src/qemu/Makefile.inc.am                |  7 +++
>   src/qemu/qemu_conf.c                    | 41 +++++++++------
>   src/qemu/qemu_conf.h                    |  3 +-
>   src/qemu/qemu_driver.c                  |  9 ++--
>   src/qemu/qemu_shim.c                    | 70 +++++++++++++++++++++++++
>   src/remote/remote_daemon.c              |  1 +
>   src/remote/remote_driver.c              |  8 +++
>   src/secret/secret_driver.c              |  1 +
>   src/storage/storage_driver.c            |  1 +
>   src/vz/vz_driver.c                      |  1 +
>   22 files changed, 179 insertions(+), 20 deletions(-)
>   create mode 100644 src/qemu/qemu_shim.c
> 

Codewise, we'll need a more clean approach, but since this is just a PoC 
lets not care about that for now.

I like this, I wonder if there are some hidden traps, but if we make 
this a preview only for some time then we should be able to catch them 
soon enough.

IIUC this is orthogonal to splitting libvirtd into multiple daemons, 
i.e. containers that are target of this feature already have way of 
setting up networking so they will not rely on our network driver. 
However, we might need to give users a helping hand in identifying what 
domain XMLs will call other drivers (daemons). I mean, I've just tried 
to start a domain I have with this shim you added in 5/5 and found that 
it tries to conenct to storage driver and network driver (yes, I have a 
disk type='pool' and interface type='network').

Michal




More information about the libvir-list mailing list