19/03/13 12:59, Daniel P. Berrange wrote: > On Tue, Mar 19, 2013 at 09:40:54AM +0100, anonym wrote: > > Can you use a real name instead of an anonymous psuedonym for patches.
Sure. Will do in my next patch proposal. >> This adds an attribute named 'removable' to the 'target' element of >> disks, which controls the removable flag. For instance, on a Linux >> guest it controls the value of /sys/block/$dev/removable. This option >> is only valid for USB disks (i.e. bus='usb'), and its default value is >> 'off', which is the same behaviour as before. >> >> To achieve this, 'removable=on' is appended to the '-device >> usb-storage' parameter sent to qemu when adding a USB disk via >> '-disk'. For versions of qemu only supporting '-usbdevice disk:' for >> adding USB disks this feature always remains 'off' since there's no >> support for passing such an option. >> >> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=922495 >> --- >> docs/formatdomain.html.in | 8 +++-- >> docs/schemas/domaincommon.rng | 8 +++++ >> src/conf/domain_conf.c | 35 >> ++++++++++++++++++-- >> src/conf/domain_conf.h | 9 +++++ >> src/libvirt_private.syms | 1 + >> src/qemu/qemu_command.c | 6 ++++ >> .../qemuxml2argv-disk-usb-device-removable.args | 8 +++++ >> .../qemuxml2argv-disk-usb-device-removable.xml | 27 +++++++++++++++ >> tests/qemuxml2argvtest.c | 2 ++ >> 9 files changed, 99 insertions(+), 5 deletions(-) >> create mode 100644 >> tests/qemuxml2argvdata/qemuxml2argv-disk-usb-device-removable.args >> create mode 100644 >> tests/qemuxml2argvdata/qemuxml2argv-disk-usb-device-removable.xml >> >> @@ -12915,10 +12940,14 @@ virDomainDiskDefFormat(virBufferPtr buf, >> if ((def->device == VIR_DOMAIN_DISK_DEVICE_FLOPPY || >> def->device == VIR_DOMAIN_DISK_DEVICE_CDROM) && >> def->tray_status != VIR_DOMAIN_DISK_TRAY_CLOSED) >> - virBufferAsprintf(buf, " tray='%s'/>\n", >> + virBufferAsprintf(buf, " tray='%s'", >> virDomainDiskTrayTypeToString(def->tray_status)); >> - else >> - virBufferAddLit(buf, "/>\n"); >> + if (def->bus == VIR_DOMAIN_DISK_BUS_USB && >> + def->removable != VIR_DOMAIN_DISK_REMOVABLE_OFF) { > > This means that if the user explicitly added removeable='off' to their > XML, we'll be dropping it. Being rather new to this, I modeled the 'removable' attribute after the 'tray' attribute, which has that behaviour. Hence you may want to reconsider if that's what you want for 'tray' too. >> + virBufferAsprintf(buf, " removable='%s'", >> + >> virDomainDiskRemovableTypeToString(def->removable)); >> + } >> + virBufferAddLit(buf, "/>\n"); >> >> /*disk I/O throttling*/ >> if (def->blkdeviotune.total_bytes_sec || >> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h >> index 96f11ba..0f4f0d7 100644 >> --- a/src/conf/domain_conf.h >> +++ b/src/conf/domain_conf.h >> @@ -518,6 +518,13 @@ enum virDomainDiskTray { >> VIR_DOMAIN_DISK_TRAY_LAST >> }; >> >> +enum virDomainDiskRemovable { > > If you add in > > VIR_DOMAIN_DISK_REMOVABLE_DEFAULT > > then you can distinguish explicit on/off settings from the > default setting to address my earlier comment. Ok. To reduce bloat I'll use VIR_DOMAIN_FEATURE_STATE_* as suggested by Peter Krempa. >> + VIR_DOMAIN_DISK_REMOVABLE_ON, >> + VIR_DOMAIN_DISK_REMOVABLE_OFF, >> + >> + VIR_DOMAIN_DISK_REMOVABLE_LAST >> +}; >> + > > >> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms >> index 5cad990..0d1a9d6 100644 >> --- a/src/libvirt_private.syms >> +++ b/src/libvirt_private.syms >> @@ -156,6 +156,7 @@ virDomainDiskIoTypeToString; >> virDomainDiskPathByName; >> virDomainDiskProtocolTransportTypeFromString; >> virDomainDiskProtocolTransportTypeToString; >> +virDomainDiskRemovableTypeToString; > > The VIR_ENUM macro generates 2 methods, so also add in > > virDomainDiskRemovableTypeFromString; Not an issue once I move to VIR_DOMAIN_FEATURE_STATE_*. >> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c >> index 4891b65..c04cecf 100644 >> --- a/src/qemu/qemu_command.c >> +++ b/src/qemu/qemu_command.c >> @@ -3219,6 +3219,11 @@ qemuBuildDriveDevStr(virDomainDefPtr def, >> if (disk->product) >> virBufferAsprintf(&opt, ",product=%s", disk->product); >> >> + if (disk->bus == VIR_DOMAIN_DISK_BUS_USB && >> + disk->removable != VIR_DOMAIN_DISK_REMOVABLE_OFF) { >> + virBufferAsprintf(&opt, ",removable=%s", >> + >> virDomainDiskRemovableTypeToString(disk->removable)); >> + } > > We should should not on the QEMU default setting - so make sure > you explicitly set both removeable=on or removeable=off. Ack. I guess it may be a good idea to not use any *TypeToString() functions like that either since that implies that the qemu value names have to be the same as those in libvirt's domain XML, both which could change in the future. I'll explicitly write "=on" or "=off" instead. Ok? > Also, not all versions of QEMU support this property, so you'll > need to add a new capability flag in qemu_capabilities.h and > then update qemu_capabilities.c to detect whether it exists or > not. > > Then in this code, if you find a QEMU which does not support the > flag, you should do a virRaiseError(VIR_ERR_CONFIG_UNSUPPORTED, ....) > to tell the user we can't do what they asked As I understand it we want QEMU_CAPS_USB_STORAGE_REMOVABLE for usb-storage.removable, but does that make sense without a capability QEMU_CAPS_DEVICE_USB_STORAGE for the actual device, i.e. `-device usb-storage`? OTOH: * there currently is no separate capability for usb-storage (i.e. QEMU_CAPS_DEVICE_USB_STORAGE), and * the current code assumes that if we have QEMU_CAPS_DEVICE, then we can use `-device usb-storage`, so I get the impression that `-device` and `-device usb-storage` were introduced into qemu in tandem, so a separate capability is perhaps not needed. Or am I missing something? Also, if you have any remarks about how the capability (or capabilities) you want me to add should be named, please do tell. Another issue this introduces for me is with the libvirt test suite. To test QEMU_CAPS_USB_STORAGE_REMOVABLE in qemuhelptest.c, the respective outputs of `-device usb-storage,?` of the various qemu/qemu-kvm versions must be in the corresponding tests/qemuhelpdata/*-device files. They currently are not and I certainly don't have all those versions (easily) available to extract them from. How do you developers deal with this? I assume you'd want those help outputs present in a patch in order to accept it (?). Otherwise I could just skip testing the QEMU_CAPS_USB_STORAGE_REMOVABLE capability by not adding it to the corresponding tests in qemuhelptest.c (that's how I got my current WIP patch to pass). Thanks for the feedback, Daniel and Peter! Cheers! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
