Re: [libvirt] [RFC] Interface for disk hotadd/remove

On Thu, Aug 13, 2009 at 12:54:00PM +0200, Wolfgang Mauerer wrote: > I'm currently interested in implementing hard disk hot-add and -remove support > for qemu (as opposed to controller-based hotplugging), and this brings up the > question how to best support this feature in libvirt. Many SCSI-Controllers in > real machines, for instance, allow to add and remove disks (without adding or > removing the controller itself) while the system is up and running, so it > would be nice to emulate this in a virtual machine. I'm focusing on > qemu on the backend side, but the problem is not related to this > particular backend. Rather, the question is how to integrate such > a feature best into libvirt. > > Before implementing the functionality, it would be great to hear the > community's opinion which route to take wrt. the interface. Essentially, I can > see two options: > > - Naturally, there are virDomain{At,De}tachDevice, but the pair implements >  drive-hotadding via adding a new controller with an attached hard disk to >  the system. By extending the XML description of the drive with a parameter >  that specifies whether controller- or disk-based hotplugging is to be >  performed, it would be possible to implement the desired functionality, >  whilst preserving compatibility with existing semantics. Removing the drive >  would then require another new parameter in the XML description to identify >  the drive on the controller, which does not really prettify the thing. > > - Extend the API with a new method (for instance virDomainDiskAttach) that >  takes a hard disk description, a controller identifier, and a parameter that >  identifies the disk on the controller. I don't think its desirable to extend the API. The virDomainAttachDevice API's XML parameter is intended to take any XML element that is valid inside the domain <devices> XML section.

So the key to deciding how to deal with hotplug, is to first decide how to represent disk controllers in the domain XML. At boot time, if you list multiple  SCSI disks in the XML, you get a single controller with multiple disks attached. As such the current semantics of the hotplug implementation for SCSI are divergant from the semantics at boot time. This has the consequence that if you boot a guest with 2 SCSI drives, then hot-attach one more you get 2 controllers, 3 disk. If you then shutdown & boot the guest again, you'll have 1 controller, 1 disks. This says to me that the hotplug implementation for QEMU SCSI should be fixed so that if you supply <disk> it adds a disk to the existing SCSI controller. Obviously it requires some QEMU support for this first.

Thus my feeling would be todo something like adding a new <controller> element to represent a disk controller. Support hotplugging <controller> instances directly with obvious semantics. Then extend the <disk> schema to allow a controller name/identifier to be provided. If no controller is listed then plug the disk into the first available controller slot, otherwise use the explicitly requested controller. Never implicitily add new controllers, unless dealing with a legacy QEMU without the disk hotplug support that you're writing.