4:32 a.m.
On Mon, Aug 20, 2012 at 10:07:43PM +0100, Richard W.M. Jones wrote:
In the first case (using "/dev/sdX" names), some magic
already happens
translating these to the real names underneath, but currently that
magic is just "/dev/sdX" -> "/dev/vdX" for the virtio case.
Ah I didn't realize that you already do device name remapping
between what the kernel shows & what the API shows.
This hidden drive doesn't appear in the API -- for example it is
suppressed when we generate the result of guestfs_list_devices.
Makes sense.
(1) The "raw libvirt" option
In this one we'd simply provide thin wrappers around
virDomainAttachDevice and virDomainDetactDevice, and leave it up to
the user to know what they're doing.
The problem with this is the hidden appliance disk. We certainly
don't want the user to accidentally detach that(!) It's also
undesirable for there to be a "hole" in the naming scheme so that
you'd have:
/dev/sda <- your normal drives
/dev/sdb <-
[/dev/sdc # sorry, you can't use this, we won't tell you why]
/dev/sdd <- your first hotplugged device
I think this scheme is flawed, because it exposes the user to
the raw kernel device names (/dev/vda), which are not guaranteed
to match the device names you expose in the API (/dev/sda).
(2) The "slots" option
In this option you'd have to use null devices to reserve the maximum
number of drive slots that you're going to use in the libguestfs
handle before launch. Then after launching you'd be allowed to
hotplug only those slots.
So for example:
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sda
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdb
guestfs_add_drive (g, "/dev/null"); # reserves /dev/sdc
guestfs_launch (g);
guestfs_hotplug (g, 1, "/tmp/foo"); # replaces index 1 == /dev/sdb
guestfs_hotplug (g, 3, "/tmp/foo"); # error!
Although ugly, in some ways this is quite attractive. It maps easily
into guestfish scripts. You have contiguous device naming. You often
know how many drives you'll need in advance, and if you don't then you
can reserve up to max_disks-1.
This feels rather unpleasant to me - I don't really consider it
to be true hotplug if you have to plan it all in advance.
(3) The "serial numbers" option
This was Dan's suggestion. Hotplugged drives are known only by their
serial number. ie. We hotplug them via libvirt using the <serial/>
field, and then they are accessed using /dev/disk/by-id/serial.
This is tempting, but unfortunately it doesn't quite work in stock
udev, because the actual name used is:
/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_SERIAL
We could add a custom udev rule to get the path we wanted.
Yep, you wouldn't even need to use any of the /dev/disk/by-XXX
dirs at all - you could easily add /dev/guestfs/$SERIAL as a
naming scheme if you wanted.
(4) The "rewriting device names" option
Since we already have the infrastructure to rewrite device names, we
could do some complicated and hairy device name rewriting to make
names appear continguous, even though there's an hidden appliance
drive.
This is my least favourite option, mainly because of the complexity,
and complexity is bound to lead to bugs.
Heh, based on the fact that you already have todo device name
translation as described above, this feels like the best option
to me.
(5) Your idea here ...
I think I'd do both (3) and (4), since I think (3) could be
useful even outside the realm of hotplug.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|