Lib.pm: Use 'file' as replacement for 'zfile'.
[libguestfs.git] / TODO
diff --git a/TODO b/TODO
index 0aeceb7..291d220 100644 (file)
--- a/TODO
+++ b/TODO
-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
 
 http://sourceforge.net/project/showfiles.php?group_id=121684&package_id=150116
 
-----------------------------------------------------------------------
+BufferIn
+--------
+
+BufferIn should turn into <char *, int> and simple strings in other
+languages that can handle 8 bit clean strings.
 
 
-BufferIn and BufferOut should turn into <char *, int> 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
 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 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"
 
 "Standalone/local mode"
+-----------------------
 
 Instead of running guestfsd (the daemon) inside qemu, there should be
 an option to just run guestfsd directly.
 
 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?
 
 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<ro =E<gt> 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?