On Tue, 11 Jan 2011 15:13:40 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> writes: > > > 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" }, > > ... } > > What if a host block device that isn't currently connected to a qdev > goes through a media change? > > What if the connected qdev doesn't have an ID? We could add the blockdev id too. > > BLOCK_MEDIA_EJECT > > ----------------- > > > > This event is only emitted when a CDROM or a floppy disk is ejected. > > > > The event contains one info one: > > > > - device name > > > > Example: > > > > { "event": "BLOCK_MEDIA_EJECT", "data": { "device-name": "ide1-cd0" }, > > ... } > > What makes CD-ROM and floppy special? Those are the only devices that support the eject operation (or have a tray status? Sorry for my bad terminology) and are the ones that we have a concrete use case to handle. We might want to be more general, but it does have a complexity cost and its possible user cases are theoretical IMHO.