On Mon, Jan 24, 2011 at 05:40:05PM -0600, Anthony Liguori wrote:
BTW, how dependent is guestfsd on the guest that libguestfs uses? I
wasn't even aware that it could be used outside of that context.
The daemon is compiled separately -- separate ./configure, make, etc.
You can run it on its own.
On the other hand, it does need to talk to something on the other end
of the virtio-serial guestfsd socket, and that other thing would
usually be the libguestfs library ...
One thing that Dan Berrange did was to patch[1] libguestfs so it could
talk to any existing guestfsd (you pointed it at a Unix domain
socket). He was using this to write test regression tests for
'virt-install': ie. install a guest, put guestfsd inside it, then boot
up the guest and check that everything was installed correctly by
querying it from an external libguestfs.
For various unrelated reasons these patches weren't quite ready to go
upstream, but it's on our ROADMAP[2] to add something like this.
In which case what you would do would be:
(a) put guestfsd into existing guests
(b) add a nice option to guestfish to attach to existing VMs, eg:
guestfish --attach Fedora14
[guestfish live attached to Fedora 14's virtio-serial guestfsd socket]
><fs> copy-in ./dirs /tmp/
"copy-in" would be dangerous currently if used on a live VM, but
in this case it would be quite safe
(c) do the work of porting guestfsd to Windows, FreeBSD etc
Rich.
[1] https://www.redhat.com/archives/libguestfs/2010-July/msg00010.html
refined a bit more later on.
[2] http://libguestfs.org/ROADMAP.txt
"* Allow alternate methods to start the appliance, including through
libvirt and by connecting to an existing appliance. This was
originally planned for 1.8 but we didn't get patches in time."