X-Git-Url: http://git.annexia.org/?p=libguestfs.git;a=blobdiff_plain;f=TODO;h=0aeceb7a4a82ab73edaa00f0a29eb6e65115a3ab;hp=04eda6cd816abf7c43db37e13774d43a266ecac4;hb=2df2f2854ed2d1f9857ef3c5aaca29810cf3c506;hpb=f18af71ff43dd87d343b459134a470900f84b833 diff --git a/TODO b/TODO index 04eda6c..0aeceb7 100644 --- a/TODO +++ b/TODO @@ -37,13 +37,109 @@ error cases. For virt-inspector: - - Are PV network drivers enabled (see /etc/modprobe.conf): + - Make a libvirt XML config - alias eth0 xennet - alias scsi_hostadapter xenblk + - Test over available OSes - - ... and can it boot from a PV driver (have to look inside the initrd) + - Add 'reged' / NT registry support. - - Make a libvirt XML config +---------------------------------------------------------------------- - - Test over available OSes +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. + +If we use virtio_blk, devices will have names like /dev/vda. + +What a mess. + +So the idea would be to add a device independent naming scheme, such +as the one used by grub: + + "(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). + +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. + +---------------------------------------------------------------------- + +"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?