X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=TODO;h=291d220ae03fc57cdb05816e1193effec76334ef;hp=0aeceb7a4a82ab73edaa00f0a29eb6e65115a3ab;hb=a82bfb88e553c6626c99757779f9b500664409ba;hpb=fe491524cefd1ede281debbc128dab4ce26d7ab6 diff --git a/TODO b/TODO index 0aeceb7..291d220 100644 --- a/TODO +++ b/TODO @@ -1,111 +1,84 @@ -Ideas for the Python bindings: -https://www.redhat.com/archives/fedora-virt/2009-April/msg00114.html +TODO list for libguestfs +====================================================================== + +This list contains random ideas and musings on features we could add +to libguestfs in future. ----------------------------------------------------------------------- + - RWMJ -We badly need to actually implement the FTP server mentioned in the -documentation. +Python bindings +--------------- -Or: Implement a FUSE-based filesystem. See the FUSE mountlo -project which does something similar, albeit only to single -filesystems: +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. -BufferIn and BufferOut 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 - - and implement read-file ----------------------------------------------------------------------- +febootstrap / debootstrap inside appliance +------------------------------------------ -Implement febootstrap command. +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 the bindings tests - must test the return values and -error cases. - ----------------------------------------------------------------------- - -For virt-inspector: - - - Make a libvirt XML config - - - Test over available OSes - - - Add 'reged' / NT registry support. - ----------------------------------------------------------------------- - -Use virtio_blk by default. It's faster and more natural. -Unfortunately it seems like this will rename all devices - see next -item. - -Note: virtio_blk *IS* supported by all our minimum platforms, -ie. CentOS 5.3, Fedora 11, Debian. - ----------------------------------------------------------------------- - -"Device independent" naming for devices. - -With a Fedora-based appliance, using libata driver, devices have -"SCSI" names like /dev/sda. - -With an EPEL-based appliance, using old ide driver, devices have names -like /dev/hda. +Complete bind tests +------------------- -If we use virtio_blk, devices will have names like /dev/vda. +Complete the bind tests - must test the return values and error cases. -What a mess. +virt-inspector - make libvirt XML +--------------------------------- -So the idea would be to add a device independent naming scheme, such -as the one used by grub: +It should be possible to generate libvirt XML from virt-inspector +data, at least partially. This would be just another output type so: - "(hdX)" X = 0 means 'a', X = 1 means 'b' and so on. - "(hdX,Y)" Device X, partition Y (in grub, this counts from 0 which is - deeply confusing). + virt-inspector --libvirt guest.img -There would have to be a very simple rule. If guestfsd was expecting -a /dev block device or partition name, then the alternate form can be -used, and we would just look it up using the normal output of -guestfs_list_devices. - -Maybe best is to use /dev/sda as the "standard" naming. That -shouldn't cause conflicts in the appliance because we tightly control -what drivers are available. - -Note there's a lot of hackery that currently exists in tests.c which -could be *removed* if we made this change. - -Open: Should the substitution be done in the library layer or in the -daemon? - ----------------------------------------------------------------------- - -Qemu options -- After discussion with the KVM developers, they have -recommended some flags which will improve the safety and reliability -of KVM. Need to test that these also work under qemu (or at least, do -no harm): - --no-hpet HPET support is broken and should be disabled. - --rtc-td-hack Keeps the rtc clock source track time correctly. - --drive file=...,if=[ide|virtio],cache=off - cache=off is necessary to improve reliability in the - event of a system crash when writing. - ----------------------------------------------------------------------- +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. @@ -143,3 +116,162 @@ 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 + 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 + 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? + +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 +----------------------- + +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?