<div dir="ltr">Hi<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 20, 2018 at 8:59 AM, Gerd Hoffmann <span dir="ltr"><<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br>
<span class=""><br>
> spice-server changes were backward-incompatible and were not accepted<br>
<br>
</span>Why they are not backward compatible?<br></blockquote><div><br></div><div>Possible, Marc Andre can answer. He was involved at time</div><div>of presentation of 2 solutions and did not raise any objections.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> usb-storage is just a header processing and holder of units<br>
<br>
</span>Yes, bulk-only transport isn't that difficuilt to handle.<br>
<span class=""><br>
> scsi source is 2K lines, similar to nbd server<br>
<br>
</span>Probably the bare minimum needed to get things going.<br>
Which guests have you tested with this?<br></blockquote><div><br></div><div>Several Windows + several Linuxes. What you recommend to add to the check list?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Be prepared that this will become larger over time,<br>
if you find that guests submit scsi commands which<br>
you do not emulate.<br>
<span class=""><br></span></blockquote><div><br></div><div>Of course, but the MMC spec has mandatory and optional features.</div><div>All the mandatory ones implemented.</div><div>At time of writing scsi processing we tried to find some shared code</div><div>that can be used, but failed to find suitable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> nbd requires also code for nbd channel<br>
<br>
</span>Sure, but should be mostly glue code binding the<br>
existing pieces together.<br>
<span class=""><br>
> > Yes. But why is this a problem? If the user can share one (or maybe<br>
> > two for both installer and driver) iso images, having that many cdrom<br>
> > drives in the guest should not cause much confusion, no?<br>
<br>
> And if the user does not want to share anything? Why he/she must have these<br>
> drives?<br>
<br>
</span>Well, physical computers have cdroms built in too. And they are<br>
likewise there even if not used. I fail to see why this is a problem.<br></blockquote><div><br></div><div>If I'm not mistaken, the boot screen in this case will be like one on attached bitmap.</div><div>This is definitely not a feature, correct? </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> With usb redirection the number of emulated drives on single channel<br>
> is potentially unlimited (using multi-unit device)<br>
<br>
</span>No, the limit is 16 LUNs for bulk-only transport. Should be enough<br>
though, I have a hard time to imagine use cases where you need more<br>
than 2-3 isos.<br>
<br>
Note that you can't hotplug the LUNs individually.<br></blockquote><div><br></div><div>
<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">There are several possible solutions for hot-plug 'removal' scenario,</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">but due to time constrains we </span>still did not select preferred one</div><div>and this is the reason why we do not enable multiple units per device right now.</div><div>Real removal of individual unit can be done only when we stop redirecting it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
cheers,<br>
Gerd<br>
<br>
</blockquote></div>Thanks,</div><div class="gmail_extra">Yuri</div><div class="gmail_extra"><br></div></div>