From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38529 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PcfE2-0008KB-37 for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:29:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PcfE0-0007Bx-0F for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:29:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PcfDz-0007BM-PG for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:29:27 -0500 From: Markus Armbruster Subject: Re: [Qemu-devel] Re: RFC: QMP event notification for disk media eject References: <20110111111148.1b94b4a4@doriath> <4D2C63DB.4050201@codemonkey.ws> Date: Tue, 11 Jan 2011 15:29:12 +0100 In-Reply-To: <4D2C63DB.4050201@codemonkey.ws> (Anthony Liguori's message of "Tue, 11 Jan 2011 08:06:19 -0600") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org, Luiz Capitulino Anthony Liguori 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. > 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?