On Wed, Aug 21, 2024 at 14:02:50 +0200, Martin Kletzander wrote:
> On Fri, Aug 16, 2024 at 04:42:33PM +0200, Peter Krempa wrote:
> > Attempting to start qemu with or hotplug an empty 'usb-storage' based
> > disk results in the following error:
> >
> > qemu-system-x86_64: -device {"driver":"usb-storage","bus":"usb.0","port":"2","id":"usb-disk1","removable":true}: drive property not set
> >
> > Reject such config at validation step and adjust tests.
> >
>
> It's weird that we even support usb cdrom as qemu cannot even emulate
> that, at least to my knowledge. Other than that the patch looks fine,
> but I cannot shake off the feeling of fishiness with this one. Could
> you bring me up to speed how this even happened to be "supported"?
IIRC the change in behaviour of USB cdroms might be an oversight/fallout
of conversion from '-drive' to '-blockdev' which wasn't originally
caught for a rather long time. (Might even have been pre-existing but I
don't care digging that far back).
Now as this config "mostly works" for most media/situations we shouldn't
really just forbid it completely so that we don't break the working
situations.
AFAIK the fix for this is to switch the USB device handling to use 'uas'
instead of 'usb-storage' which becomes basically a SCSI controller and
you can then connect a proper SCSI-cdrom device to it.
That obviously requires a complete rewrite of the USB disk handling and
might not even be ABI compatible (I didn't check because I don't really
care).
As of this situation, qemu simply fails to start with taht config so
there's no harm in forbidding it for now.
