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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list