From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49967 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pcikq-0005R6-Bd for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:15:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pcikk-0006Ig-5p for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:15:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pcikj-0006IR-Tg for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:15:30 -0500 Date: Tue, 11 Jan 2011 15:53:58 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] RFC: QMP event notification for disk media eject Message-ID: <20110111155358.6d0deafb@doriath> In-Reply-To: References: <20110111111148.1b94b4a4@doriath> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org On Tue, 11 Jan 2011 15:13:40 +0100 Markus Armbruster wrote: > Luiz Capitulino 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.