summaryrefslogtreecommitdiffstats
path: root/TODO
blob: fc6b3fd804be969c4dfe3c99457eb5542b2ce2a6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
TODO list for libguestfs
======================================================================

This list contains random ideas and musings on features we could add
to libguestfs in future.

   - RWMJ

FUSE API
--------

The API needs more test coverage, particularly lesser-used system
calls.

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).

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
----------------

Complete the Haskell bindings (see discussion on haskell-cafe).

Complete bind tests
-------------------

Complete the bind tests - must test the return values and error cases.

virt-inspector - make libvirt XML
---------------------------------

It should be possible to generate libvirt XML from virt-inspector
data, at least partially.  This would be just another output type so:

 virt-inspector --libvirt guest.img

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.

The architecture in this mode would look like:

     +------------------+
     | main program     |
     |------------------|
     | libguestfs       |
     +--------^---------+
          |   | reply
      cmd |   |
     +----v-------------+
     | guestfsd         |
     +------------------+

Notes:

(1) This only makes sense if we are running as root.

(2) There is no console / kernel messages in this configuration, but
we might consider capturing stderr from the daemon.

(3) guestfs_config and guestfs_add_drive become no-ops.

Obviously in this configuration, commands are run directly on the
local machine's disks.  You could just run the commands themselves
directly, but libguestfs provides a convenient API and language
bindings.  Also deals with tricky stuff like parsing the output of the
LVM commands.  Also we get to leverage other code such as
virt-inspector.

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?

Supermin appliance to febootstrap
---------------------------------

Supermin appliance functionality should be moved into febootstrap.

Ideas for extra commands
------------------------

  General glibc / core programs:
    chgrp
    more mk*temp calls

  ext2 properties:
    chattr
    lsattr
    badblocks
    blkid
    debugfs
    dumpe2fs
    e2image
    e2undo
    filefrag
    findfs
    logsave
    mklost+found
    ext2undelete

  SELinux:
    chcat
    restorecon
    ch???

  Oddball:
    pivot_root
    fts(3) / ftw(3)

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->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->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

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).

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/

-N option should be generated
-----------------------------

'-N' option should be generated code, and should generate
documentation in guestfish(1) manpage.

Fix 'file'
----------

https://www.redhat.com/archives/libguestfs/2010-June/msg00053.html
https://www.redhat.com/archives/libguestfs/2010-June/msg00079.html

Regression test on virt-inspector
---------------------------------

Occasionally we break virt-inspector through some change.  We should
add a regression test for it.  However this is hard because we'd need
to avoid having to carry huge images.

Freeze/thaw filesystems
-----------------------

Access to these ioctls:
http://git.kernel.org/linus/fcccf502540e3d7

Tips for new users in guestfish
-------------------------------

$ guestfish
Tip: You need to 'add disk.img' or 'alloc disk.img nn' to make a new image.
Type 'notips' to disable tips permanently.
><fs> add mydisk
Tip: You need to type 'run' before you can see into the disk image.
><fs> run
Tip: Use 'list-filesystems' to see what filesystems are available.
><fs> list-filesystems
/dev/vda1
Tip: Use 'mount fs /' to mount a filesystem.
><fs> mount /dev/vda1 /
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?
------------------------------------------------------------------------

><fs> sparse
[[Prints man page]]
Image name? disk.img
Size of image? 10M

Common problems
---------------

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.

Progress of long-running operations
-----------------------------------

For example, copying in virt-resize.  How can we display the progress
of these operations?  This is a basic usability requirement, and
frequently requested.