Hi, > > Can you summarize the reasons to discard the approach? > > > > I will try. > > The POC of nbd-based cd sharing was on the table. It needed some > unclear rework to avoid breaking ABI with mainstream spice-server. --verbose please. > The solution requires updates in qemu and spice on server side and > spice and spice-gtk on client side. Sure. > Then it is functional with command-line qemu. > In order to make it available to regular user need to update at least also > libvirt and virt-manager > (to add new nbd chanels), remote viewer (to select what to share). Yes, but for compensation you can drop code emulating usb-storage and scsi spice-gtk. > The user experience is also changed - any user (whether it plans to > share cd in this session or not) have on guest machine several > additional unloaded drives (to be loaded when the sharing triggered on > client side). 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? > Current solution is client only (even spice-gtk only), works on any setup > even with old server side. So you trade short-term simplification (only spice client update needed) over long-term maintainance requirements (all the additional usb/scsi emulation code in spice-gtk). I don't think this is a good idea. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel