X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=TODO;h=981d67b4fed0019b879a9de3f50854147399367a;hp=3241b3674e11c4a57c390b9f7c124f9241ac2e52;hb=3d05963f9e0fd2229e04e0add391a4cbcdf8d86c;hpb=d296feb05fbbd331a4ae3ed3e18bb822acdc13c8 diff --git a/TODO b/TODO index 3241b36..981d67b 100644 --- a/TODO +++ b/TODO @@ -12,33 +12,16 @@ Python bindings Ideas for the Python bindings: https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html -FTP server or FUSE? -------------------- +FUSE API +-------- + +The API needs more test coverage, particularly lesser-used system +calls. -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 -------- @@ -144,15 +127,8 @@ Ideas for extra commands General glibc / core programs: chgrp - grep (do it locally using pipe?) 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 @@ -177,27 +153,6 @@ Ideas for extra commands pivot_root fts(3) / ftw(3) -Swap space ----------- - -Allow swap space from the guest to be used. Is it a good idea? - -Query guest architecture ------------------------- - -Need a way to query a binary or library file for its architecture. -Using objdump or readelf? -What about non-ELF files (eg. Windows, BSD). - -To do this properly requires some serious logic, eg. to cover Linux -and Windows we'd need objdump and i686-pc-mingw32-objdump, and more to -cover a.out, COFF and 64 bit Windows. Therefore this cannot be done -inside the daemon, and should be done by a separate, external program -similar to virt-inspector. - -Probably we should go all the way and have virt-inspector able to -determine kernel and userspace architectures of guests. - Other initrd-* commands ----------------------- @@ -240,7 +195,90 @@ 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. + +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 + +Standard images +--------------- + +Equip guestfish with some standard images that it can load +quickly, eg: + + load ext2 + +Maybe it's better to create these on the fly? + +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). + +virt-rescue TERM +---------------- + +Pass TERM from the library, through the kernel command line, to the +init script. + +Windows-based daemon/appliance +------------------------------ + +See discussion on list: +https://www.redhat.com/archives/libguestfs/2009-November/msg00165.html + +virt-grow, virt-shrink +---------------------- + +Grow and shrink existing guests. The main problem comes with +MBR-style partitions where you have to actually copy data around the +disk (unless you only want to change the final partition). + +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. \ No newline at end of file