X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=TODO;h=da9f5b475b988b4b3fd1d4aabf1be1f382e7340e;hp=e8293586f97de46a757a73345292af5639eae0e4;hb=bf2b08560f649c22152e4138531ad0b46b4ad1b3;hpb=a8d25362435121ada85656c08cd79642f79f9f7b diff --git a/TODO b/TODO index e829358..da9f5b4 100644 --- a/TODO +++ b/TODO @@ -1,7 +1,260 @@ +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 (?) + ln / ln -s + readlink + utime / utimes / futimes / futimens / l.. + more mk*temp calls + some sort of alloc/fallocate/posix_fallocate call to create empty space + realpath + 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) + +Swap space +---------- + +Allow swap space from the guest to be used. Is it a good idea? + +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");' -We badly need to actually implement the FTP server mentioned in the -documentation. +How would editing files work?