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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list