9:27 a.m.
Hello,
As I understand it guestfs appliances normally work as servers
and run high-level commands from some external channel.
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.
Has anyone tried this already?
2:54 p.m.
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:
** NB: you REALLY NEED to use --ro here unless you know exactly
** what you are doing...
$ LIBGUESTFS_BACKEND=direct guestfish --ro -a /dev/sda -i
Enter key or passphrase ("/dev/sda2"): xxx
Welcome to guestfish, the guest filesystem shell for
editing virtual machine filesystems and disk images.
Type: 'help' for help on commands
'man' to read the manual
'quit' to quit the shell
Operating system: Fedora release 18 (Spherical Cow)
/dev/fedora/root mounted on /
/dev/sda1 mounted on /boot
/dev/fedora/home mounted on /home
<fs> list-filesystems
/dev/sda1: ext4
/dev/fedora/archlinux20121201x64: unknown
/dev/fedora/f18x64: unknown
/dev/fedora/f20rawhidex32: unknown
/dev/fedora/f20rawhidex64: unknown
/dev/fedora/home: ext4
/dev/fedora/root: ext4
/dev/fedora/swap: swap
/dev/fedora/ubuntu1210: unknown
/dev/fedora/ubuntu1304: unknown
/dev/fedora/win7x32dynamic-a: unknown
/dev/fedora/win7x32dynamic-b: unknown
/dev/fedora/win7x32dynamic-c: unknown
/dev/fedora/windows2012: unknown
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.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
3:05 p.m.
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).
https://github.com/g2p/blocks#readme
3:11 p.m.
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).
https://github.com/g2p/blocks#readme
supermin + supermin-helper + blocks might be useful to get this to work
(or another image builder like Oz, but I haven't played with this much).
I'm not yet sure I should integrate with guestfs, but it might be useful
for VMs. If so, libguestfs-live could be used in the kexec case.
3:25 p.m.
On Sat, Jun 01, 2013 at 10:05:20PM +0200, Gabriel wrote:
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 promise to look at this in more detail when I'm back at work next
week, but a quick question: where would the 'client' end of the
connection (ie. libguestfs) be running in this scenario?
I would like to do something like that for my blocks tool
(which does conversions to LVM and bcache).
https://github.com/g2p/blocks#readme
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
3:34 p.m.
>> 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 promise to look at this in more detail when I'm back at work next
week, but a quick question: where would the 'client' end of the
connection (ie. libguestfs) be running in this scenario?
In kexec, everything would be local (LIBGUESTFS_BACKEND=direct or unix:).
If blocks is reworked to integrate with guestfs, there might be several
options depending if python is client-side or daemon side, but it doesn't
make much difference for the kexec case.
> I would like to do something like that for my blocks tool
> (which does conversions to LVM and bcache).
>
> https://github.com/g2p/blocks#readme
2:51 a.m.
On Sat, Jun 01, 2013 at 10:05:20PM +0200, Gabriel wrote:
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).
https://github.com/g2p/blocks#readme
So .. yes it appears it would be possible.
You'll want to get familiar with adding new APIs, since almost
certainly the current APIs won't cover everything you need to do. See
these links:
https://github.com/libguestfs/libguestfs/commit/d66145622550ff4f4ce9a5f8a...
https://github.com/libguestfs/libguestfs/commit/dee1dd64c3cd5e67393dec679...
http://libguestfs.org/guestfs.3.html#extending-libguestfs
Note the Python bindings are generated automatically (as are all the
other bindings).
If the client and server are always going to be on the same machine,
then there's not a lot of reason to use libguestfs, since you can
presumably just run the commands directly (as you appear to do now).
On the other hand if you want to control the daemon remotely, then
libguestfs would give you some flexibility.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
4114
days inactive
4116
days old
6 comments
3 participants
participants (3)
-
Gabriel -
Gabriel de Perthuis
-
Richard W.M. Jones