FUSE support for libguestfs

FUSE + libguestfs, so you can mount guests on the host filesystem! Long-term this would let you double-click on a guest’s disk image icon and then go inside the guest, dragging and dropping files in and out.

It’s quite slow at the moment, but it does basically work …

# guestmount -a Win2003x32.img -m /dev/sda1 --ro /mnt/tmp
# ll /mnt/tmp/
total 786837
-rwxrwxrwx 1 root root         0 2009-07-10 10:50 AUTOEXEC.BAT
-rwxrwxrwx 1 root root       210 2009-07-10 10:44 boot.ini
-rwxrwxrwx 1 root root         0 2009-07-10 10:50 CONFIG.SYS
drwxrwxrwx 1 root root      4096 2009-07-10 14:13 Documents and Settings
-rwxrwxrwx 1 root root         0 2009-07-10 10:50 IO.SYS
-rwxrwxrwx 1 root root         0 2009-07-10 10:50 MSDOS.SYS
-rwxrwxrwx 1 root root     47772 2007-02-18 12:00 NTDETECT.COM
-rwxrwxrwx 1 root root    297072 2007-02-18 12:00 ntldr
-rwxrwxrwx 1 root root 805306368 2009-07-10 16:04 pagefile.sys
drwxrwxrwx 1 root root      4096 2009-07-10 16:04 Program Files
drwxrwxrwx 1 root root         0 2009-07-10 10:55 System Volume Information
drwxrwxrwx 1 root root     57344 2009-07-16 03:01 WINDOWS
drwxrwxrwx 1 root root         0 2009-07-10 10:51 wmpub

Update

The number of layers going on here is scary. Note that this is a Windows NTFS filesystem so inside the appliance it’s being managed by another FUSE filesystem, NTFS-3g.

I hope I got this right. I think its:

Linux VFS (in the host) -> fuse -> guestmount process -> libguestfs -> XDR protocol over a TCP socket -> host kernel -> QEMU’s SLIRP stack -> guest kernel -> guestfsd -> Linux VFS (in the guest) -> fuse -> mount-ntfs-3g -> Windows block device -> QEMU (emulating the block device) -> host kernel -> real block device

Replies come all the way back through the same chain …

This makes the cost of a round trip expensive, probably a dozen context switches and a large amount of code, and hence it makes it all important to reduce those round trips when we look at optimizing this.