From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyMKT-00054j-LC for qemu-devel@nongnu.org; Fri, 17 Feb 2012 06:50:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RyMKP-0002Ln-8p for qemu-devel@nongnu.org; Fri, 17 Feb 2012 06:50:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RyMKO-0002Lf-Q8 for qemu-devel@nongnu.org; Fri, 17 Feb 2012 06:50:17 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1HBoFDe001257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Feb 2012 06:50:15 -0500 From: Markus Armbruster References: <1329331347-11232-1-git-send-email-lcapitulino@redhat.com> <1329331347-11232-5-git-send-email-lcapitulino@redhat.com> <20120216111447.2160fa63@doriath.home> <4F3D054C.9020603@redhat.com> <4F3E239C.6050402@redhat.com> <4F3E3069.7060109@redhat.com> Date: Fri, 17 Feb 2012 12:50:13 +0100 In-Reply-To: <4F3E3069.7060109@redhat.com> (Paolo Bonzini's message of "Fri, 17 Feb 2012 11:48:09 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 4/4] qmp: add BLOCK_MEDIUM_EJECT event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , eblake@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino Paolo Bonzini writes: > On 02/17/2012 10:53 AM, Kevin Wolf wrote: >> > Note: device models call bdrv_eject() whether the state changed or not. >> > The only use for that I can see is syncing a wayward physical tray to >> > the virtual one. Shouldn't be necessary with Paolo's recent work, >> > should it? >> >> The one case that I'm unsure about is migration. I thought we sync the >> physical tray with the virtual one then (or at least we discussed it), >> but I don't really know what we do today, or even what the right thing >> to do is in some cases. > > Migration with passthrough doesn't make sense. The only way it could > work (untested) is if the destination connected via iSCSI to the > source's CD-ROM. In which case the physical and virtual tray would be > synced already. Maybe we should prevent migration with CD-ROM pass-through just like we do for PCI pass-through.