Tag Archives: FUSE

Browsing guests using FUSE

What’s interesting about this screenshot is that I’m browsing into a guest filesystem using the GNOME file browser (nautilus), with the guest mounted using FUSE and libguestfs. You can visit directories, open files, and drag files out of the guest (but not drag them into the guest yet — we haven’t enabled file writes at the moment).

(This is /var/log from a Fedora 12 Alpha guest, displayed in a Fedora 11 host. Notice the “Free Space: 5.7 GB” label which accurately shows the amount of free space in the guest filesystem).


FUSE support via the guestmount command is in libguestfs 1.0.77.

1 Comment

Filed under Uncategorized

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


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.


Filed under Uncategorized