From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNj5j-0003W7-83 for qemu-devel@nongnu.org; Mon, 15 Oct 2012 07:44:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TNj5h-00036v-TP for qemu-devel@nongnu.org; Mon, 15 Oct 2012 07:44:15 -0400 Received: from mail.stepping-stone.ch ([194.176.109.206]:41245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TNj5h-00036j-N1 for qemu-devel@nongnu.org; Mon, 15 Oct 2012 07:44:13 -0400 Message-ID: <1350301169.4696.169.camel@storm> From: Tiziano =?ISO-8859-1?Q?M=FCller?= Date: Mon, 15 Oct 2012 13:39:29 +0200 In-Reply-To: <507BEF57.1010505@redhat.com> References: <1349962403.4696.51.camel@storm> <20121012083315.GB14822@stefanha-thinkpad.redhat.com> <1350032009.4696.84.camel@storm> <507BEF57.1010505@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Silent filesystem/qcow2 corruptions with qemu-kvm-1.0 and 1.1.1 Reply-To: tiziano.mueller@stepping-stone.ch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel Am Montag, den 15.10.2012, 13:11 +0200 schrieb Kevin Wolf: > Am 12.10.2012 10:53, schrieb Tiziano M=C3=BCller: > > Am Freitag, den 12.10.2012, 10:33 +0200 schrieb Stefan Hajnoczi: > >> On Thu, Oct 11, 2012 at 03:33:23PM +0200, Tiziano M=C3=BCller wrote: > >>> Checking the image using `qemu-img check` then gives something like > >>> this: > >>> > >>> ERROR OFLAG_COPIED: offset=3D3bc30000 refcount=3D1 > >>> ERROR offset=3Dc7e331: Cluster is not properly aligned; L2 entry > >>> corrupted. > >> > >> Is any other program accessing the qcow2 image on the host while the= VM > >> is running? > >=20 > >> For example, are you running qemu-img on the image while the VM is > >> running? > >=20 > > On some VMs we tried to extract filesystem snapshots at runtime: > >=20 > > qemu-img convert -s snapshot-id original.qcow2 snapshot.qcow2 > >=20 > > (yes, that's not consistent, we're switching to external snapshots). > > But that should open the image read-only, right? >=20 > Yes, in theory that should be harmless and even produce a correct copy > of the snapshot. Good to know, thanks. >=20 > > Other operations where the qemu-monitor-commands "savevm" and "delvm"= .=20 > >=20 > > Although: we created a new qcow2 and even in that the filesystem got > > corrupted without any of the above actions. So we're pretty confident > > that those operations are not the sole cause. >=20 > So no internal snapshots are involved at all with this new image? No. I just checked again: no internal snapshot are currently present nor have been added/removed in the past. > I'm > asking because in the past non-reproducible failures were reported with > snapshots, but I'm not aware of any case that didn't use snapshots. >=20 > Any other non-default feature that you used, like compression? No, we either create the qcows by hand using: qemu-img create -f qcow2 kvm-0XY_01.qcow2 30G or (usually) using libvirt: virsh vol-create $pool $diskfile where $diskfile points to a xml like this: ${diskfilename} 0 ${kvmsize}.qcow2 0 3000 0660 and $pool references a directory-based storage pool. --=20 stepping stone GmbH Neufeldstrasse 9 CH-3012 Bern Telefon: +41 31 332 53 63 www.stepping-stone.ch tiziano.mueller@stepping-stone.ch