TODO list for libguestfs ====================================================================== This list contains random ideas and musings on features we could add to libguestfs in future. - RWMJ FUSE API -------- The API needs more test coverage, particularly lesser-used system calls. The big unresolved issue is UID/GID mapping between guest filesystem IDs and the host. It's not easy to automate this because you need extra details about the guest itself in order to get to its UID->username map (eg. /etc/passwd from the guest). febootstrap / debootstrap inside appliance ------------------------------------------ This was originally proposed as a way to install new operating systems in the appliance. However no one has come up with a workable solution. Haskell bindings ---------------- Complete the Haskell bindings (see discussion on haskell-cafe). Complete bind tests ------------------- Complete the bind tests - must test the return values and error cases. virt-inspector - make libvirt XML --------------------------------- It should be possible to generate libvirt XML from virt-inspector data, at least partially. This would be just another output type so: virt-inspector --libvirt guest.img Note that recent versions of libvirt/virt-install allow guests to be imported, so this is not so useful any more. "Standalone/local mode" ----------------------- Instead of running guestfsd (the daemon) inside qemu, there should be an option to just run guestfsd directly. The architecture in this mode would look like: +------------------+ | main program | |------------------| | libguestfs | +--------^---------+ | | reply cmd | | +----v-------------+ | guestfsd | +------------------+ Notes: (1) This only makes sense if we are running as root. (2) There is no console / kernel messages in this configuration, but we might consider capturing stderr from the daemon. (3) guestfs_config and guestfs_add_drive become no-ops. Obviously in this configuration, commands are run directly on the local machine's disks. You could just run the commands themselves directly, but libguestfs provides a convenient API and language bindings. Also deals with tricky stuff like parsing the output of the LVM commands. Also we get to leverage other code such as virt-inspector. This is mainly useful from live CDs, ie. virt-p2v. Should we bother having the daemon at all and just link the guestfsd code directly into libguestfs? Supermin appliance to febootstrap --------------------------------- Supermin appliance functionality should be moved into febootstrap. Ideas for extra commands ------------------------ General glibc / core programs: chgrp more mk*temp calls ext2 properties: chattr lsattr badblocks blkid debugfs dumpe2fs e2image e2undo filefrag findfs logsave mklost+found ext2undelete SELinux: chcat restorecon ch??? Oddball: pivot_root fts(3) / ftw(3) Other initrd-* commands ----------------------- Such as: initrd-extract initrd-replace Simple editing of configuration files ------------------------------------- Some easy non-Augeas methods to edit configuration files. I'm thinking: replace /etc/file key value which would look in /etc/file for any instances of key=... key ... key:... and replace them with key=value key value key:value That would solve about 50% of reconfiguration needs, and for the rest you'd use Augeas, 'download'+'upload' or 'edit'. RWMJ: I had a go at implementing this, but it's quite error-prone to do this sort of editing inside the C-based daemon code. It's far better to do it with Augeas, or else to use an external language like Perl. Quick Perl scripts ------------------ Currently we can't do Perl "one-liners". ie. The current syntax for any short Perl one-liner would be: perl -MSys::Guestfs -e '$g = Sys::Guestfs->new(); $g->add_drive ("foo"); $g->launch; $g->mount ("/dev/sda1", "/"); ....' You can see we're well beyond a single line just getting to the point of adding drives and mounting. First suggestion: $h = create ($filename, \"/dev/sda1\" => \"/\"); $h = create ([$file1, $file2], \"/dev/sda1\" => \"/\"); To mount read-only, add C 1> like this: $h = create ($filename, \"/dev/sda1\" => \"/\", ro => 1); which is equivalent to the following sequence of calls: $h = Sys::Guestfs->new (); $h->set_autosync (1); $h->add_drive_ro ($filename); $h->launch (); $h->mount_ro (\"/dev/sda1\", \"/\"); Command-line form would be: perl -MSys::Guestfs=:all -e '$_=create("guest.img", "/dev/sda1" => "/"); $_->cat ("/etc/fstab");' That's not brief enough for one-liners, so we could have an extra autogenerated module which creates a Sys::Guestfs handle singleton (the handle is an implicit global variable as in guestfish), eg: perl -MSys::Guestfs::One -e 'inspect("guest.img"); cat ("/etc/fstab");' How would editing files work? ntfsclone --------- Useful imaging tool: http://man.linux-ntfs.org/ntfsclone.8.html virt-rescue pty --------------- See: http://search.cpan.org/~rgiersig/IO-Tty-1.08/Pty.pm http://www.perlmonks.org/index.pl?node_id=582185 Note that pty requires cooperation inside the C code too (there are two sides to a pty, and one has to be handled after the fork). Windows-based daemon/appliance ------------------------------ See discussion on list: https://www.redhat.com/archives/libguestfs/2009-November/msg00165.html qemu locking ------------ Add -drive file=...,lock=exclusive and -drive file=...,lock=shared Change libguestfs and libvirt to do the right thing, so that multiple instances of qemu cannot stomp on each other. virt-disk-explore ----------------- For multi-level disk images such as live CDs: http://rwmj.wordpress.com/2009/07/15/unpack-the-russian-doll-of-a-f11-live-cd/ It's possible with libguestfs to recursively look for anything that might be a filesystem, mount-{,loop} it and look in those, revealing anything in a disk image. However this won't work easily for VM disk images in the disk image. One would have to download those to the host and launch another libguestfs instance. List, mount filesystems by UUID and label ----------------------------------------- [See related: http://www.redhat.com/archives/libguestfs/2009-August/msg00031.html] List filesystems by UUID or label. Mount filesystems by UUID or label. (I'm not really sure if we can do this at the moment but we ought to be able to do it, and perhaps make it easier by having a direct command). Map filesystems to disk blocks ------------------------------ Map files/filesystems/(any other object) to the actual disk blocks they occupy. And vice versa. Is it even possible? Integration with host intrusion systems --------------------------------------- Perfect way to monitor VMs from outside the VM. Look for file hashes, log events, login/logout etc. http://www.ossec.net/ http://la-samhna.de/samhain/ http://sourceforge.net/projects/aide/ http://osiris.shmoo.com/ http://sourceforge.net/projects/tripwire/ -N option should be generated ----------------------------- '-N' option should be generated code, and should generate documentation in guestfish(1) manpage. Fix 'file' ---------- https://www.redhat.com/archives/libguestfs/2010-June/msg00053.html https://www.redhat.com/archives/libguestfs/2010-June/msg00079.html Regression test on virt-inspector --------------------------------- Occasionally we break virt-inspector through some change. We should add a regression test for it. However this is hard because we'd need to avoid having to carry huge images. Freeze/thaw filesystems ----------------------- Access to these ioctls: http://git.kernel.org/linus/fcccf502540e3d7 Tips for new users in guestfish ------------------------------- $ guestfish Tip: You need to 'add disk.img' or 'alloc disk.img nn' to make a new image. Type 'notips' to disable tips permanently. > add mydisk Tip: You need to type 'run' before you can see into the disk image. > run Tip: Use 'list-filesystems' to see what filesystems are available. > list-filesystems /dev/vda1 Tip: Use 'mount fs /' to mount a filesystem. > mount /dev/vda1 / Tip: Use 'll /' to view the filesystem or ... > ll / New guestfish commands ---------------------- 'list-filesystems' => list mountable filesystems We could implement this as a new API call, replacing a number of areas of the current code where this is done already (in virt-inspector and elsewhere). What we normally do to find out if a partition contains a mountable filesystem is to just blindly mount it, and see if that succeeds. However the kernel won't let us do this if the filesystem is already mounted somewhere, so a naive implementation of this in the daemon won't work. We would have to check if the partition was already mounted. Could we make guestfish interactive if commands are used without params? ------------------------------------------------------------------------ > sparse [[Prints man page]] Image name? disk.img Size of image? 10M Common problems --------------- How can we solve these common user problems? - http://lists.fedoraproject.org/pipermail/users/2010-June/374931.html In guestfish, specified -m non-existent filesystem. We could suggest a list of filesystems, or suggest they run the virt-list-filesystems command. Progress of long-running operations ----------------------------------- For example, copying in virt-resize. How can we display the progress of these operations? This is a basic usability requirement, and frequently requested.