Re: [libguestfs] Options for hotplugging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/08/12 22:07, Richard W.M. Jones wrote:
(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

As far as I know, the kernel assigns /dev/sdX names on a first-free
basis, so there's no way to permanently put the appliance at
/dev/sdzzz (if there is, please let me know!)

There are numerous reasons not to like this. If there were any reason to want to expose the underlying libvirt api directly I'd suggest it only be a debug option.

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

Echo Dan's general dislike of this.

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

Presumably you would specify then serial number when adding the drive? I'm not opposed to this, but it's not the simplest.

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

I don't think this rewriting is required. Having a hole in the drive letters isn't a big deal. In fact, I suspect it would be simpler in most code to use returned rather than calculated device names.

I'd suggest a very simple api:

char * guestfs_hotplug_drive(g, path, <opts>)

This does the same as add_drive, except that it works after launch and returns the api name of the newly added drive. list_devices will return a list with a hole in it. If it isn't already there, we can add some generic code to methods taking a Device parameter to guard against passing in the root device.

Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team

GPG ID:  D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]