Re: [Qemu-devel] Re: RFC: QMP event notification for disk media eject

[Luiz Capitulino]

On Tue, 11 Jan 2011 15:29:12 +0100
Markus Armbruster <address@hidden> wrote:

> Anthony Liguori <address@hidden> writes:
> 
> > On 01/11/2011 07:11 AM, Luiz Capitulino wrote:
> >> Hi there,
> >>
> >> I need feedback on a new QMP event.
> >>
> >> Problem
> >> =======
> >>
> >> There's no way for a management tool to detect that a guest OS has ejected 
> >> the
> >> media in a CDROM or Floppy disk drive (I'm discarding polling, because it's
> >> undesirable at best).
> >>
> >> The end result is that the management tool can get confused, this is 
> >> happening
> >> with libvirt when migration is involved: if the guest is saved/restored or
> >> migrated, then libvirt will start the guest again with media still present.
> >>
> >> NOTE: Most of the analysis here was done by Daniel Berrange.
> >>
> >> Solution
> >> ========
> >>
> >> We need a new QMP event to solve that. There are two possible events, a
> >> general one and a very specific one.
> >>
> >> There are 3 scenarios in which both events should be emitted:
> >>
> >>   1. When guest OS ejects media
> >>   2. When 'eject' monitor command is run
> >>   3. When 'change' monitor command is run
> >>
> >> BLOCK_MEDIA_CHANGE
> >> ------------------
> >>
> >> This is the general event, it's emitted when any removable block device
> >> is changed.
> >>
> >> Ideally, the event should contain two pieces of info:
> >>
> >>   - qdev device name
> >>   - new file path (to allow distinguishing eject from change)
> >>
> >> Example:
> >>
> >>    { "event": "BLOCK_MEDIA_CHANGE", "data": { "qdev-id": "myid",
> >>                                               "new-path": 
> >> "/foo/bar/dir/distro.iso" },
> >>                                               ... }
> >>    
> >
> > I think this is short sighted as block devices are not simply
> > expressed in terms of new-path.  You would need to do something like:
> >
> > { 'blockdev': {'file': '/foo/bar/dir/distro.iso', 'cache', 'off', ...}}
> >
> > And that adds a lot of complexity that I'm not sure is really
> > justified.  Tray status is really what you're interested in.
> 
> I figure the important bit is the notification that tray status changed.
> If management software wants to know more, it can query when it gets the
> event.

Which means you're in favor of the BLOCK_MEDIA_EJECT event, right?

> 
> >                                                               The user
> > cannot directly change the media, only the management tools can so why
> > would the management tools need to be notified about something that
> > they did?
>