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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 21/06/2013 15:30, Marc-André Lureau ha scritto:
>     > 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.

Similar, but it also violates encapsulation by adding bs->child. :)

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

That would work better.  Spice qemu-side would keep an association
between Spice channels and block device names, and use that to convert
Spice commands to monitor commands (the API is
qmp_change_blockdev/qmp_eject).

Paolo

> 
>     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