From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56208 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PceFZ-0006iD-Gg
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 08:27:02 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PceFY-00081D-2e
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 08:27:01 -0500
Received: from mx1.redhat.com ([209.132.183.28]:1027)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PceFX-000818-RO
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 08:27:00 -0500
Message-ID: <4D2C5AF7.6040502@redhat.com>
Date: Tue, 11 Jan 2011 14:28:23 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <20110111111148.1b94b4a4@doriath>
In-Reply-To: <20110111111148.1b94b4a4@doriath>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: RFC: QMP event notification for disk media eject
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: stefanha@gmail.com, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>

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?

>  - 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?

> 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.

Kevin