On Mon, Sep 07, 2020 at 12:48:21 +0100, Daniel Berrange wrote: > On Mon, Sep 07, 2020 at 01:45:09PM +0200, Gerd Hoffmann wrote: > > Hi, [...] > > > 1. doing this transparently with a controller per device, just like the > > > usb-storage controller does internally (ok - it's just a scsi-cd there), > > > even if the usb-bot supports multiple LUNs. Guess multiple LUNs would > > > act like an USB hub? > > > > usb-storage simply doesn't support multiple LUNs, so when going that > > route you can completely ignore the multiple LUN case. > > > > > 2. invalidating the cdrom with USB addresses configurations and exposing > > > the controller in the XML. This seems easier from the libvirt code POV, > > > like: > > > > > > <controller type='scsi' model='usb-bot'> > > > <address type='usb' port='1'/> > > > </controller> > > > > Yep, that is the other obvious approach. > > > > > So I still would like to see my much simpler solution merged. > > > > See above, but I'm not a libvirt maintainer so that's not for me to > > judge. I'm just pointing out that this can be fixed without switching > > back to the old -drive syntax. > > Switching back to -drive is out of the question. We've worked very hard > to eliminate its usage and get to an exclusively -blockdev based solution > because supporting both approaches in parallel complicates too much. Yes, indeed. We theoretically can emulate a complex device consisting of a USB-bot device including the cdrom for this including the hotplug operations in a single step. I will need to investigate this, but I'm backed up on my email as I was on vacation.
