[Stefan asked an interesting question on IRC about how / whether it is
possible to use libguestfs remotely. The answer is too detailed for IRC]
Consider this model of the libguestfs architecture[i]:
(2) libguestfs (3) Linux
(1) API protocol syscalls
program <--------> libguestfs <--------> qemu <--------> devices
guestfsd disk images
kernel
There are three places where you might want to use libguestfs
remotely.
You can remote libguestfs at (3). For example if your disk is located
remotely and made available to the local machine using iSCSI, it
appears as /dev/sdX and you can just access that directly with
libguestfs. Another possibility is to use the NBD or http drivers
built into qemu. Another possibility is to use sshfs (which we
already advocate for access to VMware ESX VMFS[ii]).
One user has successfully remoted libguestfs at (1), but it depends on
the programming language you are using. He used rpyc[iii] to
automatically generate Python stubs for libguestfs plus a remote
daemon. Same is probably possible in Java using (eg) RMI. It's
obviously a lot more complicated if you just consider the C API.
The interesting case is (2), and I believe it's also possible to
remote libguestfs here. In libguestfs 1.10 we added support for
accessing live guests. The way this works under the hood is that
instead of launching the qemu backend, you tell libguestfs to connect
to an existing Unix domain socket. To access a live guest, the idea
is that this is set up to point to a virtio-serial channel into the
running guest. But you could use the same underlying API[iv] to
connect to a remote qemu that you run yourself. You could start the
remote qemu using (eg.) ssh and have it forward the virtio-serial
channel back to something on the local side (nc -U?). Additionally
you would have to work out how to send the appliance over to the
remote side and/or arrange that there's a compatible appliance and
qemu available to run remotely.
As a final note, I should add that libguestfs will have different
performance characteristics depending on which remote method you use.
The reason is that some functionality exists only in the library
(eg. setting and getting various flags), some functionality runs
mainly in the library but makes lots of calls over the protocol
(eg. the core inspection API), and some functionality happens almost
entirely in guestfsd.
Rich.
[i]
http://libguestfs.org/guestfs.3.html#architecture
[ii]
https://rwmj.wordpress.com/2011/05/10/tip-use-libguestfs-on-vmware-esx-gu...
[iii]
http://rpyc.wikidot.com/
[iv]
http://libguestfs.org/guestfs.3.html#attaching_to_running_daemons
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw