X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=TODO;h=b06ae7120e2a39ddfebd93836613e72b4c2aae93;hp=bfcc477d37a983f124cadf58dd182c6018b78cfb;hb=7c285ea84f63e511f95a3c8bfbb98cbf99b9466b;hpb=7eda9e6fb2b1f6504167ab650886f5a336fc6919 diff --git a/TODO b/TODO index bfcc477..b06ae71 100644 --- a/TODO +++ b/TODO @@ -6,39 +6,16 @@ to libguestfs in future. - RWMJ -Python bindings ---------------- +FUSE API +-------- -Ideas for the Python bindings: -https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html +The API needs more test coverage, particularly lesser-used system +calls. -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 +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). BufferIn -------- @@ -117,23 +94,6 @@ 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 --------------------------------- @@ -144,10 +104,7 @@ Ideas for extra commands General glibc / core programs: chgrp - dd (?) - utime / utimes / futimes / futimens / l.. more mk*temp calls - trunc[ate??] ext2 properties: chattr @@ -214,7 +171,7 @@ 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", "/"); ....' + 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. @@ -235,7 +192,6 @@ which is equivalent to the following sequence of calls: $h->set_autosync (1); $h->add_drive_ro ($filename); $h->launch (); - $h->wait_ready (); $h->mount_ro (\"/dev/sda1\", \"/\"); Command-line form would be: @@ -256,12 +212,91 @@ ntfsclone Useful imaging tool: http://man.linux-ntfs.org/ntfsclone.8.html -Standard images +virt-rescue pty --------------- -Equip guestfish with some standard images that it can load -quickly, eg: +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/ + +Resizing, shrinking, specifying sizes in guestfish +-------------------------------------------------- + +Owing to an oversight we don't really supporting shrinking +filesystems. See: - load ext2 +https://bugzilla.redhat.com/show_bug.cgi?id=585221 +https://bugzilla.redhat.com/show_bug.cgi?id=585222 +https://bugzilla.redhat.com/show_bug.cgi?id=585223 -Maybe it's better to create these on the fly? +But a related problem is how to specify sizes to guestfish, ie. "100M" +or "1G". Currently the specific alloc and sparse functions contain +code to parse these size strings, but that cannot be used anywhere +else that would take a byte count. This is awkward because some +commands take units of megabytes (lvresize, sfdiskM) or sectors +(part-add), with no unifying theme.