From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44127 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q5FNJ-0007WV-QJ
	for qemu-devel@nongnu.org; Thu, 31 Mar 2011 06:45:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Q5FNI-0001iy-14
	for qemu-devel@nongnu.org; Thu, 31 Mar 2011 06:45:13 -0400
Received: from mx1.redhat.com ([209.132.183.28]:6470)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Q5FNH-0001iq-My
	for qemu-devel@nongnu.org; Thu, 31 Mar 2011 06:45:11 -0400
Message-ID: <4D945BBC.4060104@redhat.com>
Date: Thu, 31 Mar 2011 12:47:24 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <1301488265-22028-1-git-send-email-mjt@msgid.tls.msk.ru>
In-Reply-To: <1301488265-22028-1-git-send-email-mjt@msgid.tls.msk.ru>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH] exit if -drive specified is invalid
 instead of ignoring the "wrong" -drive
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: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org, Justin Forbes <jforbes@redhat.com>

Am 30.03.2011 14:31, schrieb Michael Tokarev:
> This fixes the problem when qemu continues even if -drive specification
> is somehow invalid, resulting in a mess.  Applicable for both current
> master and for stable-0.14 (and the same issue exist 0.13 and 0.12 too).
> 
> The prob can actually be seriuos: when you start guest with two drives
> and make an error in the specification of one of them, and the guest
> has something like a raid array on the two drives, guest may start failing
> that array or kick "missing" drives which may result in a mess - this is
> what actually happened to me, I did't want a resync at all, and a resync
> resulted in re-writing (and allocating) a 4TB virtual drive I used for
> testing, which in turn resulted in my filesystem filling up and whole
> thing failing badly.  Yes it was just testing VM, I experimented with
> larger raid arrays, but the end result was quite, well, unexpected.
> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Thanks, applied to the block branch. CCed Justin for stable.

Kevin