From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40031 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PciLG-0006Pm-Qq for qemu-devel@nongnu.org; Tue, 11 Jan 2011 12:50:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PciJc-0007oz-3M for qemu-devel@nongnu.org; Tue, 11 Jan 2011 12:49:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PciJb-0007oo-RO for qemu-devel@nongnu.org; Tue, 11 Jan 2011 12:47:28 -0500 Date: Tue, 11 Jan 2011 15:47:20 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: RFC: QMP event notification for disk media eject Message-ID: <20110111154720.699df286@doriath> In-Reply-To: References: <20110111111148.1b94b4a4@doriath> <4D2C63DB.4050201@codemonkey.ws> 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:29:12 +0100 Markus Armbruster wrote: > 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. Which means you're in favor of the BLOCK_MEDIA_EJECT event, right? > > > 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? >