Hi On Thu, Sep 20, 2018 at 12:37 PM Yuri Benditovich <yuri.benditovich@xxxxxxxxxx> wrote: > > Hi > > On Thu, Sep 20, 2018 at 8:59 AM, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> >> Hi, >> >> > spice-server changes were backward-incompatible and were not accepted >> >> Why they are not backward compatible? > > > Possible, Marc Andre can answer. He was involved at time > of presentation of 2 solutions and did not raise any objections. Actually, I didn't attend a presentation. I replied to a mail with a presentation slide that I quickly looked at. I pointed out: - USB emulation is an interesting alternative - let's try to share existing code if we do that - let's discuss this on mailing list before taking a decision And then, I don't remember being involved until now. Let me quote myself: :) "I agree that doing USB CD emulation on client side is an interesting approach too. 5y ago, I think I prefered the NBD approach more because it allows some interesting flexibility (potentially any qemu block device can be redirected), and doesn't duplicate too much of emulation code. But they were some complications with qemu block layer regarding migrations, and apparently they are still there (I didn't verify). During my talk at KVM forum, I mentionned that an interesting project idea/heack would be to try to reuse emulated USB devices in qemu, and abstract them so they could speech usbredir. I think that would be really neat, because not only we could share USB emulation code from qemu with spice client, but we could also run qemu USB devices out of process. It may not be easy, or it may, in all cases I hope we won't duplicate too much of qemu code in spice client. Perhaps qemu USB devices code could be in a shared library? Just some thoughts. Could the discussion be opened on the spice-devel & qemu-devel mailing list? A summary mail of the 2 approaches could bring interesting point of view to help make a decision. Especially from block devices & usb maintainers." thanks > >> >> >> > usb-storage is just a header processing and holder of units >> >> Yes, bulk-only transport isn't that difficuilt to handle. >> >> > scsi source is 2K lines, similar to nbd server >> >> Probably the bare minimum needed to get things going. >> Which guests have you tested with this? > > > Several Windows + several Linuxes. What you recommend to add to the check list? > >> >> Be prepared that this will become larger over time, >> if you find that guests submit scsi commands which >> you do not emulate. >> > > Of course, but the MMC spec has mandatory and optional features. > All the mandatory ones implemented. > At time of writing scsi processing we tried to find some shared code > that can be used, but failed to find suitable. > >> >> > nbd requires also code for nbd channel >> >> Sure, but should be mostly glue code binding the >> existing pieces together. >> >> > > Yes. But why is this a problem? If the user can share one (or maybe >> > > two for both installer and driver) iso images, having that many cdrom >> > > drives in the guest should not cause much confusion, no? >> >> > And if the user does not want to share anything? Why he/she must have these >> > drives? >> >> Well, physical computers have cdroms built in too. And they are >> likewise there even if not used. I fail to see why this is a problem. > > > If I'm not mistaken, the boot screen in this case will be like one on attached bitmap. > This is definitely not a feature, correct? > >> >> >> > With usb redirection the number of emulated drives on single channel >> > is potentially unlimited (using multi-unit device) >> >> No, the limit is 16 LUNs for bulk-only transport. Should be enough >> though, I have a hard time to imagine use cases where you need more >> than 2-3 isos. >> >> Note that you can't hotplug the LUNs individually. > > > There are several possible solutions for hot-plug 'removal' scenario, > but due to time constrains we still did not select preferred one > and this is the reason why we do not enable multiple units per device right now. > Real removal of individual unit can be done only when we stop redirecting it. > >> >> >> cheers, >> Gerd >> > Thanks, > Yuri > -- Marc-André Lureau _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel