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.