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

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


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.

- (Theoretically, it would also be possible to implement media exchange for
 hard disks in qemu  and re-use the media exchange infrastructure already
 present in libvirt for CD-ROMs, but since this possibility comes to use on
 real hardware only very occasionally, guest operating systems are typically
 not really prepared to handle this well)

My preference would be to go for option 2, that is, implement a new API
method. Would there be any obstacles against adding such a patch to
mainline? Or is anyone already working on similar functionality?  Or can this
be done in a much simpler way I've missed?  If not, then I'd send patches
for more detailed review before long.



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