From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52441 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pcez1-0008R7-Rl
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:14:00 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1Pceyx-0002Qg-R7
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:13:59 -0500
Received: from mx1.redhat.com ([209.132.183.28]:18285)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1Pceyx-0002QJ-Jx
	for qemu-devel@nongnu.org; Tue, 11 Jan 2011 09:13:55 -0500
From: Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] RFC: QMP event notification for disk media eject
References: <20110111111148.1b94b4a4@doriath>
Date: Tue, 11 Jan 2011 15:13:40 +0100
In-Reply-To: <20110111111148.1b94b4a4@doriath> (Luiz Capitulino's message of
	"Tue, 11 Jan 2011 11:11:48 -0200")
Message-ID: <m3wrmbh6jv.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org

Luiz Capitulino <lcapitulino@redhat.com> writes:

> 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" },
>                                              ... }

What if a host block device that isn't currently connected to a qdev
goes through a media change?

What if the connected qdev doesn't have an ID?

> 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" }, ... }

What makes CD-ROM and floppy special?