<div dir="ltr">Hi<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 1:57 PM, Paolo Bonzini <span dir="ltr"><<a href="mailto:pbonzini@redhat.com" target="_blank">pbonzini@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<div><br>
>     What exactly are you trying to do here (I guess I'll understand more<br>
>     when I get to the later patches)?<br>
><br>
> Getting to the bottom BlockDriverState to be able to eject & change it.<br>
> (it could also be named the "parent", but other parts of the code<br>
> suggest the "child" name)<br>
<br>
</div>There is already an interface for eject/change, which is the monitor.<br>
To signal an eject or medium change, the SPICE client should simply ask<br>
libvirt to do so.  It is fine to change "from" spicebd: "to" spicebd:,<br>
the guest would still perceive it as a change.<br>
<br>
I'm not sure how libvirt communicates the change back to the SPICE<br>
client, and whether it is asynchronous or synchronous.<br>
<br></blockquote><div><br></div><div>Spice is not using libvirt, and doesn't have access to monitor. I looked at the monitor code. Basically, the spice block driver I proposed uses a similar code to forcefully eject and change.<br>
<br></div><div>Perhaps it's possible for the Spice qemu-side code to have access to the monitor, but the end result would be similar anyway.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

BTW, note that IDE or virtio-blk do not support removable media, and are<br>
not able to pass eject or media change notifications.  SCSI devices<br>
(such as usb-bot, usb-uas and virtio-scsi) can.<br>
<div><br>
>     Can you draw the relationships between all the BlockDriverStates in a<br>
>     spicebd: drive?<br>
><br>
><br>
> Hopefully, but I have only tested with raw images (w/wo snapshot).<br>
<br>
</div>Then draw it. :)  But from the above description it looks like it is not<br>
necessary, it should simply be "raw" on top of "spicebd".  Parsing<br>
formats should be done on the client side, perhaps by invoking qemu-nbd<br>
and tunnelling the NBD data on the SPICE channel.<br>
<span><font color="#888888"><br></font></span></blockquote><div> </div><div>Right, "raw" on top of "spicebd" for iso/raw images (and "qcow2" on top for snapshot support - even in readonly).<br>
<br></div><div>I wonder what would happen if spicebd image would be something else than raw/iso, I suppose there would be more BlockDriverStates to handle the various format.<br></div></div><br>-- <br>Marc-André Lureau
</div></div></div>