Re: [Qemu-devel] [PATCH 07/12] block: save the associated child in BlockDriverState

[Marc-André Lureau]

Hi

On Fri, Jun 21, 2013 at 1:57 PM, Paolo Bonzini <address@hidden> wrote:

>     What exactly are you trying to do here (I guess I'll understand more
>     when I get to the later patches)?
>
> Getting to the bottom BlockDriverState to be able to eject & change it.
> (it could also be named the "parent", but other parts of the code
> suggest the "child" name)

There is already an interface for eject/change, which is the monitor.
To signal an eject or medium change, the SPICE client should simply ask
libvirt to do so.  It is fine to change "from" spicebd: "to" spicebd:,
the guest would still perceive it as a change.

I'm not sure how libvirt communicates the change back to the SPICE
client, and whether it is asynchronous or synchronous.

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.

Perhaps it's possible for the Spice qemu-side code to have access to the monitor, but the end result would be similar anyway.

 

BTW, note that IDE or virtio-blk do not support removable media, and are
not able to pass eject or media change notifications.  SCSI devices
(such as usb-bot, usb-uas and virtio-scsi) can.

>     Can you draw the relationships between all the BlockDriverStates in a
>     spicebd: drive?
>
>
> Hopefully, but I have only tested with raw images (w/wo snapshot).

Then draw it. :)  But from the above description it looks like it is not
necessary, it should simply be "raw" on top of "spicebd".  Parsing
formats should be done on the client side, perhaps by invoking qemu-nbd
and tunnelling the NBD data on the SPICE channel.

 

Right, "raw" on top of "spicebd" for iso/raw images (and "qcow2" on top for snapshot support - even in readonly).

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.

--
Marc-André Lureau