From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpyMh-0004UG-EO for qemu-devel@nongnu.org; Wed, 25 Jan 2012 03:38:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpyMg-0002rK-Dt for qemu-devel@nongnu.org; Wed, 25 Jan 2012 03:37:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpyMg-0002rF-1M for qemu-devel@nongnu.org; Wed, 25 Jan 2012 03:37:58 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0P8bv8W022924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2012 03:37:57 -0500 Message-ID: <4F1FC030.2030705@redhat.com> Date: Wed, 25 Jan 2012 09:41:20 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <20120124161628.4bf2592c@doriath.home> <4F1F0E9F.8080302@redhat.com> In-Reply-To: <4F1F0E9F.8080302@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qmp: add BLOCK_MEDIUM_EJECT event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Markus Armbruster , qemu-devel , Luiz Capitulino Am 24.01.2012 21:03, schrieb Eric Blake: > On 01/24/2012 11:16 AM, Luiz Capitulino wrote: >> Libvirt wants to be notified when the guest ejects a medium, so that >> it can update its view of the guest. >> >> This code has been originally written by Daniel Berrange. It adds >> the event to IDE and SCSI emulation. >> >> Please, note that this only covers guest initiated ejects, that's, >> the QMP/HMP commands 'eject' and 'change' are not covered. What's the reason for this behaviour? It feels inconsistent. Also, I seem to remember that once we had discussed some kind of a "tray status (open/closed) changed" event, which would be more generic. >> Signed-off-by: Luiz Capitulino > > Reviewed-by: Eric Blake > >> >> +BLOCK_MEDIUM_EJECT >> +------------------ >> + >> +Emitted when the guest succeeds ejecting a medium. If the device has a tray, > > s/succeeds ejecting/succeeds at ejecting/ > > Since libvirt is also tracking whether it makes 'eject' and 'change' > monitor commands, and can also do a query when reconnecting to the > monitor after a libvirtd restart to see if state changed in the meantime > (when an event was lost), this should be sufficient for libvirt to have > an accurate picture of the device state. > > I do have to wonder, however, if we also need an event for when the > guest initiates a tray lock or tray unlock event, in order to track > whether plain eject will work or whether a forced eject to override the > tray lock would be required. The tray is usually locked for a reason, so I would vote against libvirt automagically overriding it. Note that you don't really need a lock/unlock event for implementing it, you could just always pass force=true (or do it after you got QERR_DEVICE_LOCKED). The only reasonable thing for a management tool to do with a lock/unlock event would be updating some icon in a GUI or something like that. Kevin