On Wed, Mar 24, 2010 at 11:46:24AM +0000, Daniel P. Berrange wrote:
To allow the new virDomainUpdateDeviceFlags() API to be universally
used with all drivers, this patch adds an impl to all the current
drivers which support CDROM or Floppy disk media change via the
current virDomainAttachDeviceFlags API
* src/qemu/qemu_driver.c, src/vbox/vbox_tmpl.c,
src/xen/proxy_internal.c, src/xen/xen_driver.c,
src/xen/xend_internal.c: Implement media change via the
virDomainUpdateDeviceFlags API
* src/xen/xen_driver.h, src/xen/xen_hypervisor.c,
src/xen/xen_inotify.c, src/xen/xm_internal.c,
src/xen/xs_internal.c: Stubs for Xen driver entry points
[...]
+static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
+ const char *xml,
+ unsigned int flags)
+{
[...]
+ switch (dev->data.disk->device) {
+ case VIR_DOMAIN_DISK_DEVICE_CDROM:
+ case VIR_DOMAIN_DISK_DEVICE_FLOPPY:
+ ret = qemudDomainChangeEjectableMedia(driver, vm, dev->data.disk);
+ if (ret == 0)
+ dev->data.disk = NULL;
+ break;
+
+
+ default:
+ qemuReportError(VIR_ERR_NO_SUPPORT,
+ _("disk bus '%s' cannot be updated."),
+ virDomainDiskBusTypeToString(dev->data.disk->bus));
+ break;
+ }
+
+ if (ret != 0 && cgroup) {
+ virCgroupDenyDevicePath(cgroup,
+ dev->data.disk->src);
+ }
Hum ... I got a bit lost there, qemudDomainChangeEjectableMedia only
returns -1 on error or 0 on success. But failure to change may mean that
the previous data is still being used, shouldn't we check that the
old and new data.disk->src are different before denying access ?
But it's a minor question,
ACK,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/