On Sat, 01 Jun 2013 20:54:15 +0100, Richard W.M. Jones wrote:
On Sat, Jun 01, 2013 at 02:27:50PM +0000, Gabriel de Perthuis wrote:
> Hello,
> As I understand it guestfs appliances normally work as servers
> and run high-level commands from some external channel.
This is the normal architecture when you're using libguestfs to access
a VM or disk image:
http://libguestfs.org/guestfs.3.html#architecture
> But it might be possible to bundle a guestfish script to run
> commands from and do away with the external system.
> That would make it useful on non-virtualised systems.
It's worth noting you can edit any device, including host devices
directly. For example on my laptop:
It's also possible to get libguestfs to connect to an arbitrary
socket, so-called 'libguestfs live'. That could include a guestfsd
daemon running on the local host. Run the daemon and set
LIBGUESTFS_BACKEND=unix:/path/to/some/socket
http://libguestfs.org/guestfs.3.html#backend
https://rwmj.wordpress.com/2011/07/07/how-does-libguestfs-live-work/#content
It would also be possible to run qemu-nbd or sshd on a physical
machine and access it using libguestfs (>= 1.22) from another machine.
Indeed this is a possible architecture under discussion for the new
version of virt-v2v.
Hope that gives you some ideas. If you have a specific use scenario
you are interested in, then please let us know.
I was thinking of running some operations on the root filesystem
by kexec-rebooting into an appliance to get exclusive access.
I would like to do something like that for my blocks tool
(which does conversions to LVM and bcache).