On Tue, 11 Jan 2011 15:29:12 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Anthony Liguori <anth...@codemonkey.ws> 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? >