From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56826 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PcjJn-0001pz-Vh for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:51:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PcjJl-00067P-3k for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:51:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PcjJk-000670-SF for qemu-devel@nongnu.org; Tue, 11 Jan 2011 13:51:41 -0500 Date: Tue, 11 Jan 2011 15:45:49 -0200 From: Luiz Capitulino Message-ID: <20110111154549.4c17c35c@doriath> In-Reply-To: <4D2C5AF7.6040502@redhat.com> References: <20110111111148.1b94b4a4@doriath> <4D2C5AF7.6040502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Kevin Wolf Cc: stefanha@gmail.com, qemu-devel@nongnu.org, Markus Armbruster On Tue, 11 Jan 2011 14:28:23 +0100 Kevin Wolf wrote: > Am 11.01.2011 14:11, schrieb Luiz Capitulino: > > 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 > > Is there a reason why you use the device name instead of the drive > name/blockdev ID here? Good question, this is a copy & paste from Daniel initial request, so he's the best person to answer that question. > > - new file path (to allow distinguishing eject from change) > > How do you distinguish? Would this key be missing for ejects? An empty > string? Something else? Yes, I think it would be optional and thus only part of the change command. > > Example: > > > > { "event": "BLOCK_MEDIA_CHANGE", "data": { "qdev-id": "myid", > > "new-path": "/foo/bar/dir/distro.iso" }, > > ... } > > > > 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" }, ... } > > I think it's called drive name in most other places. Ok, please note that we won't implement both events, we have to choose one or the other.