From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:51728)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pl@dlhnet.de>) id 1TDhoJ-000892-VO
	for qemu-devel@nongnu.org; Mon, 17 Sep 2012 16:20:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@dlhnet.de>) id 1TDhoI-0003v5-L4
	for qemu-devel@nongnu.org; Mon, 17 Sep 2012 16:20:51 -0400
Received: from ssl.dlhnet.de ([91.198.192.8]:37732 helo=ssl.dlh.net)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@dlhnet.de>)
	id 1TDhoI-0003v1-E3
	for qemu-devel@nongnu.org; Mon, 17 Sep 2012 16:20:50 -0400
Message-ID: <50578621.8060700@dlhnet.de>
Date: Mon, 17 Sep 2012 22:20:49 +0200
From: Peter Lieven <pl@dlhnet.de>
MIME-Version: 1.0
References: <5055A643.8060505@dlhnet.de> <5056E221.8020106@redhat.com>
In-Reply-To: <5056E221.8020106@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Block Migration Assertion in qemu-kvm 1.2.0
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>

On 09/17/12 10:41, Kevin Wolf wrote:
> Am 16.09.2012 12:13, schrieb Peter Lieven:
>> Hi,
>>
>> when trying to block migrate a VM from one node to another, the source
>> VM crashed with the following assertion:
>> block.c:3829: bdrv_set_in_use: Assertion `bs->in_use != in_use' failed.
>>
>> Is this sth already addresses/known?
> Not that I'm aware of, at least.
>
> Block migration doesn't seem to check whether the device is already in
> use, maybe this is the problem. Not sure why it would be in use, though,
> and in my quick test it didn't crash.
>
> So we need some more information: What's you command line, did you do
> anything specific in the monitor with block devices, what does the
> stacktrace look like, etc.?
i was also able to reproduce a "flush_blks: Assertion 
`block_mig_state.read_done >= 0' failed." by
cancelling a block migration and restarting it afterwards.
however, how can I grep a stack trace after an assert?

thanks,
peter

> Kevin