Re: [Libguestfs] What are the advantages and disadvantages of running with or without libvirt?

There's two parts to this question. On Tue, Jan 12, 2016 at 05:26:10PM +0200, Yaniv Kaul wrote: The basic concept of the backend is how do we run the libguestfs appliance (http://libguestfs.org/guestfs-internals.1.html#architecture). There are two ways we could run the appliance: either we run qemu directly as a forked subprocess of the program that is linked to libguestfs.so (LIBGUESTFS_BACKEND=direct); or we could run qemu via libvirt (LIBGUESTFS_BACKEND=libvirt). The two code paths are largely equivalent but also quite different in their implementation: https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c https://github.com/libguestfs/libguestfs/blob/master/src/launch-libvirt.c You would think that direct is faster, but I benchmarked this a while back and there's essentially no measurable difference. There are however big differences, and restrictions. Off the top of my head: - libvirt implements sVirt (http://selinuxproject.org/page/SVirt) so it's considerably more secure for examining untrusted disk images - libvirt allows hotplugging of drives, ie. you can call guestfs_add_drive_opts after launching the handle - there are some differences in how networking is done, although they are rather obscure (and networking is not enabled by default anyway, so it would not affect you unless the main program called guestfs_set_network (g, 1) before guestfs_launch) - libvirt is the supported method to run qemu in RHEL - libvirt is way more complex and fails much more frequently :-( It's unfortunately because of the last point that if libvirt fails to start the qemu appliance, we print an error message telling you to try with LIBGUESTFS_BACKEND=direct. Libvirt has different namespaces where you can run guests, eg. for Xen you have to use the xen:/// namespace, for qemu you have a choice (qemu:///session or qemu:///system). The libguestfs appliance mostly runs in the qemu:///session (non-root per-user) namespace, except when you run libguestfs as root when it has to run in the qemu:///system namespace, but that's just a bug in libvirt - https://bugzilla.redhat.com/show_bug.cgi?id=890291 . BUT! I said there were two parts to this question, and this is the second part ... There are several other places where libguestfs calls libvirt, and they are not related to how libguestfs runs its appliance, and that seems to be what you're hitting here: The virt-sysprep --connect option isn't anything to do with how libguestfs runs its appliance, and it's not even significant in the virt-sysprep command you've shown here. The virt-sysprep --connect option affects how virt-sysprep (and other tools) process the '-d' option. If you write: virt-sysprep -d some_libvirt_domain --mkdir /foo then virt-sysprep asks libvirt for the XML of `some_libvirt_domain' (basically equivalent to running `virsh dumpxml some_libvirt_domain') and it then parses the libvirt XML to find the disks of `some_libvirt_domain' so it knows where to create the /foo directory. https://github.com/libguestfs/libguestfs/blob/master/src/libvirt-domain.c... Because libvirt has different namespaces for libvirt domain names, we allow you to select the namespace using the -c/--connect option, so you could for example do: virt-sysprep -c xen:/// -d some_xen_domain which is equivalent to doing `virsh -c xen:/// dumpxml some_xen_domain' and parsing that XML. This has nothing to do with how we run the libguestfs appliance. It's complicated ... and often we get confused too. HTH, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org