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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/