This is something I was thinking about a little over the christmas
break. I've no intention of implementing this in the immediate
future, but wanted to post it while it was fresh in my mind.
Historically we have had 2 ways of using the stateful drivers like
QEMU/LXC/UML/etc.
- "system mode" - privileged libvirtd, one per host, started at boot
- "session mode" - unprivileged libvirtd, one per non-root user, autostarted
Within context of each daemon, VM name uniqueness is enforced. Operating
via the daemon means that all applications connected to libvirtd get the
same world view. This single world view is exactly what you want when
dealing with server / cloud / desktop virtualization, because it means
tools like 'virt-top', 'virt-viewer', 'virsh' can see the same VMs as
virt-manager / oVirt / OpenStack / Boxes / etc.
Recently we've seen increasing importance of a new use case which I will
refer to as "embedded" virtualization. The best example of this use case
is libguestfs which has long run a dedicated QEMU instance, but just now
switched to using libvirtd. The other use case is virt-sandbox which is
doing application confinement using LXC/KVM.
In both these cases, operating via libvirtd is sub-optimal. Users of so
called "embedded" virtualization, explicitly don't want to have interaction
with other libvirt applications. They likely don't even want to expose the
concept of virtualization to their users. For them virtualization is intended
to be just a hidden impl detail of their application.
Some issues which arise when using embedded virtualization
- Need to invent sensible unique names for each VM launched. This
leads to pollution of logfiles for QEMU instances run.
- User sees libguestfs / virt-sandbox VMs in virt-manager / oVirt
which they may then try to "manage", breaking libguestfs / etc
- Disassociated process context, so if 'virt-sandbox' is placed in
a cgroup, the VMs it launches are in a different cgroup. Likewise
if custom env variables are set, work is needed to propagate those
to VMs.
This leads me to wonder whether it is worth exploring the idea of a new
type of libvirt connection.
- "embed mode" - no libvirtd, driver runs in application context
The idea here is to take libvirtd out of the equation and directly use
the QEMU driver code in the libvirt.so client / application. Since
libvirtd (mostly) uses the same APIs as the public libvirt.so clients,
there isn't much required to make this work.
- A way for the application to invoke virStateInit for the driver
- Application must provide an event loop impl
- A way to specify alternative dirs for logs/state/config/etc
An application would access this mode using a different path for the
driver, and specifying the path to use for logs/state/config etc.
eg libguestfs might use
qemu:///embed?statedir=/tmp/libguestfsXXXXX/
to get an instance of the QEMU driver that is completely private
to itself. One question is whether there should be a single embed
instance per process, or whether an application should be allowed
to open multiple completely isolated embed instances. The latter
might require is to eliminate more static variables in our code.
This kind of embedded mode is not without its downsides though
- How to access virtual network / storage / node device APIs ?
- Extra SELinux policy work to allow each app to have the same
kind of privileges that libvirtd has to let it start VMs
- How to troubleshoot - can't use things like
'virsh qemu-monitor-command'
since the embedded instance is private to the application
in question.
One answer to the latter question, might be to actually allow the
application to expose the same RPC service as libvirtd does. So
virsh could connect to libguestfs using
qemu:///embed?socketdir=/tmp/libguestfsXXXXX/libvirt-sock
For the question of network/storage/node device access, the long
term answer is probably to split up the system libvirtd instance
into separate pieces. eg a virtnodedeviced, virtnetworkd,
virstoraged, virtqemud, virtlxcd, etc. Now a client app would
connect to their embedded QEMU instances, but to the shared
nodedevice/network/storage daemons.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list