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!