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.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list