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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
