[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] API Proposal: Block device streaming (V3)



On Fri, May 20, 2011 at 07:42:26AM -0500, Adam Litke wrote:
> > In the VIR_DOMAIN_BLOCK_STREAM_CONTINUOUS case, I think it is desirable
> > to have an async event emitted when the streaming is completed, so we
> > don't force apps to poll on the GetBlockStreamInfo if they only care
> > about completion. The event would also allow apps to determine if the
> > background stream job failed, which isn't something that's exposed in
> > any of these APis.
> > 
> > eg, in virDomainEventID enum, add
> > 
> >    VIR_DOMAIN_EVENT_ID_BLOCK_STREAM = 7,
> > 
> >    typedef enum {
> >       VIR_DOMAIN_BLOCK_STREAM_COMPLETED,
> >       VIR_DOMAIN_BLOCK_STREAM_FAILED,
> >    } virConnectDomainEventlockStreamStatus;
> > 
> >   typedef void (*virConnectDomainEventBlockStreamCallback(virConnectPtr conn,
> >                                                           virDomainPtr dom,
> >                                                           const char *path,
> >                                                           int status);
> > 
> > Internally this would have to be wired upto an event QEMU emits. If
> > completion automatically removes the backing store from the block device,
> > then we need the async event from QEMU regardless, since we'll need to
> > perform SELinux relabelling to deny the VM future access to the now
> > unused backing store.
> 
> This seems like a good idea to me.  Stefan and Anthony:  What do you
> guys think about adding these events to Qemu?  Is this something we
> could easily incorporate into the Qemu API?

We already raise events for error conditions like ENOSPC.  I think it
makes sense to signal asynchronous command completion using an event.
Although my knowledge of QMP is limited this sounds like a good idea.

Stefan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]