extra details about the guest itself in order to get to its
UID->username map (eg. /etc/passwd from the guest).
-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
----------------
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\", \"/\");
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
------------------------------
Is it even possible?
+See also contribs/visualize-alignment/
+
Integration with host intrusion systems
---------------------------------------
http://osiris.shmoo.com/
http://sourceforge.net/projects/tripwire/
--N option should be generated
------------------------------
-
-'-N' option should generate documentation in guestfish(1) manpage.
-
Fix 'file'
----------
Tip: Use 'll /' to view the filesystem or ...
><fs> ll /
-New guestfish commands
-----------------------
-
-'list-filesystems' => list mountable filesystems
-
-We could implement this as a new API call, replacing a number of areas
-of the current code where this is done already (in virt-inspector and
-elsewhere). What we normally do to find out if a partition contains a
-mountable filesystem is to just blindly mount it, and see if that
-succeeds. However the kernel won't let us do this if the filesystem
-is already mounted somewhere, so a naive implementation of this in the
-daemon won't work. We would have to check if the partition was
-already mounted.
-
Could we make guestfish interactive if commands are used without params?
------------------------------------------------------------------------
How can we solve these common user problems?
-- http://lists.fedoraproject.org/pipermail/users/2010-June/374931.html
- In guestfish, specified -m non-existent filesystem. We could suggest
- a list of filesystems, or suggest they run the virt-list-filesystems
- command.
+[space for common problems here]
Better support for encrypted devices
------------------------------------
- Direct access to the /dev/mapper device (eg. if it contains
anything apart from VGs).
-Recursive upload / download of multiple files
----------------------------------------------
+Display image as PS
+-------------------
-virt-tar is really clumsy to use, and upload/download in guestfish can
-only do single files. tar-in in guestfish can upload multiple files,
-but only if you have prepared a tarball in advance.
+Display the structure of an image file as a PS.
-What we really need is a method which is as easy to use as 'scp' and
-'scp -r'.
+Greater use of blkid / libblkid
+-------------------------------
+
+guestfs_zero should use wipefs. See wipefs(8).
+
+There are various useful functions in libblkid for listing partitions,
+devices etc which we are essentially duplicating in the daemon. It
+would make more sense to just use libblkid for this.
+
+There are some places where we call out to the 'blkid' program. This
+might be replaced by direct use of the library (if this is easier).
+
+Visualization
+-------------
+
+Eric Sandeen pointed out the blktrace tool which is a better way of
+capturing traces than using patched qemu (see
+contrib/visualize-alignment). We would still use the same
+visualization tools in conjunction with blktrace traces.
-Can we add this as a command in guestfish? This will be more useful
-since users will already need to be in guestfish in order to create
-target directories, review what they've done etc. It could be a meta-
-command such as:
+guestfish parsing
+-----------------
+
+At the moment guestfish uses an ad hoc parser which has many
+shortcomings. We should change to using a lex/yacc-based scanner and
+parser (there are better parsers out there, but yacc is sufficient and
+very widely available).
+
+The scanner must deal with the case of parsing a whole command string,
+eg. for a command that the user types in:
- copy-in-recursive localdir remotedir
- copy-out-recursive remotedir localdir
+ ><fs> add-drive-opts "/tmp/foo" readonly:true
-which would hide use of tgz-in etc.
+and also with parsing single words from the command line:
-Other thoughts on this:
+ guestfish add-drive-opts /tmp/foo readonly:true
-virt-cp or virt-rcp or virt-copy or virt-scp or ...?
+Note the quotes are for scanning and don't indicate types.
-virt-copy *.c *.h GuestName:/tmp/
+We should also allow variables and expressions as part of this new
+parsing code, eg:
-virt-copy -r dir/ GuestName:/tmp/
+ set roots inspect-os
+ set product inspect-get-product-name %{roots[0]}
+
+% is better than $ because of shell escaping and confusion with shell
+variables.
+
+live CD inspection
+------------------
-virt-copy GuestName:/tmp/foo* .
+guestfish -i livecd.iso
-virt-copy disk.img:/tmp/bar* otherdisk.img:/tmp
-( probably not because it requires multiple libguestfs connections)
+Could this be done through the core API and existing calls?