From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37808 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PcesS-0004KM-HX for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:07:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PcesR-0000ss-Bo for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:07:12 -0500 Received: from mail-iw0-f173.google.com ([209.85.214.173]:62152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PcesR-0000sd-8O for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:07:11 -0500 Received: by iwn40 with SMTP id 40so21952484iwn.4 for ; Tue, 11 Jan 2011 06:07:10 -0800 (PST) Message-ID: <4D2C63DB.4050201@codemonkey.ws> Date: Tue, 11 Jan 2011 08:06:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20110111111148.1b94b4a4@doriath> In-Reply-To: <20110111111148.1b94b4a4@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: RFC: QMP event notification for disk media eject List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, Markus Armbruster 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. 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? Regards, Anthony Liguori > 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" }, ... } >