On Mon, Jun 30, 2014 at 05:40:16PM -0600, Eric Blake wrote: > On 06/30/2014 05:16 PM, Eric Blake wrote: > > I'm trying to track down a core dump with the QMP drive-mirror command. > > Looks like the bug is related to a base image that is not a multiple of > a cluster size. > > > > > # in one terminal: > > cd /tmp > > rm -f base.img snap1.img snap2.img copy.img > > > > # base.img <- snap1.img <- snap2.img; intentionally populating base.img > > # with a qcow2 header, but treating it as raw data > > qemu-img create -f qcow2 base.img 10M > > If, right here, I inject: > > truncate --size 262144 base.img > > > qemu-img create -f qcow2 -b base.img -o backing_fmt=raw snap1.img > > qemu-img create -f qcow2 -b snap1.img -o backing_fmt=qcow2 snap2.img > > cp base.img copy.img > > # Yes, this command line is derived from libvirt... > > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ > > QEMU_AUDIO_DRV=none gdb --args /usr/bin/qemu-system-x86_64 \ > > ...then everything else succeeds. So it seems the problem is that qemu > is doing a lousy job of handling a backing file and/or destination file > that is not fully rounded out to a proper size.
Thanks for reporting this. It's something we need to fix during the QEMU 2.1 hard freeze that is starting today. Stefan
pgpiWh241inHL.pgp
Description: PGP signature
