[Spice-devel] [spice-gtk v4 00/13] CD sharing feature

[Marc-André Lureau]

Hi

On Thu, Sep 20, 2018 at 12:37 PM Yuri Benditovich
<yuri.benditovich at daynix.com> wrote:
>
> Hi
>
> On Thu, Sep 20, 2018 at 8:59 AM, Gerd Hoffmann <kraxel at redhat.com> 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