TODO list for libguestfs ====================================================================== This list contains random ideas and musings on features we could add to libguestfs in future. - RWMJ Python bindings --------------- Ideas for the Python bindings: https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html FTP server or FUSE? ------------------- Originally we had intended to implement an NFS server inside the appliance, which would allow the guest filesystems to be mounted on the host, and large changes to be made. We eventually rejected the idea of using NFS, partly because it requires root to mount filesystems in the host, and partly because of problems handling UID mappings between host and guest filesystem. Then we look at implementing an FTP server instead. FTP clients are widely available for many languages, don't require root, and don't have any UID mapping problems. However there is the problem of getting the TCP connection into the guest, and that FTP requires a secondary data connection either in or out of the guest (the NFS situation is even more dire). Thirdly we looked at implementing a FUSE-based filesystem. This is plausible - it could be implemented just by adding the additional FUSE operations to the standard guestfs(3) API, and then implementing a simple FUSE daemon. (The FUSE website has some very helpful documentation and examples). I [RWMJ] am not particularly convinced that a FUSE-based filesystem would really be useful to anyone, but am prepared to accept patches if someone does all the work. See also the mountlo project: http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=150116 BufferIn -------- BufferIn should turn into and simple strings in other languages that can handle 8 bit clean strings. Limit on transfers would still be 2MB for these types. - then implement write-file properly 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? PPC problems ------------ [This section should be filed as bugs, but no one seems to care for PPC hosts and the hardware is rapidly becoming obsolete] ppc (32 bit) works with qemu from git, however there is no serial console ppc64 requires extra parameters: -M mac99 -cpu ppc64 however it still fails: invalid/unsupported opcode: 01 - 01 - 1a (06301e83) 00000000018c2738 1 invalid bits: 00400000 for opcode: 0b - 19 - 15 (2d746572) 0000000000009230 no serial console in ppc or ppc64 because no one can tell us what console=ttyXX option to use Supermin appliance to febootstrap --------------------------------- Supermin appliance functionality should be moved into febootstrap. Ideas for extra commands ------------------------ General glibc / core programs: chgrp dd (?) utime / utimes / futimes / futimens / l.. more mk*temp calls trunc[ate??] ext2 properties: chattr lsattr badblocks blkid debugfs dumpe2fs e2image e2undo filefrag findfs logsave mklost+found 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->wait_ready; $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->wait_ready (); $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?