----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Sander Grendelman" <sander(a)grendelman.com>
Cc: users(a)ovirt.org, fsimonce(a)redhat.com, ykaplan(a)redhat.com
Sent: Friday, November 8, 2013 4:06:53 PM
Subject: Re: [Users] Live storage migration snapshot removal (fails)
On Fri, Nov 08, 2013 at 02:20:39PM +0100, Sander Grendelman wrote:
<snip>
> 9d4e8a43-4851-42ff-a684-f3d802527cf7/c512267d-ebba-4907-a782-fec9b6c95116
> 52178458-1764-4317-b85b-71843054aae9::WARNING::2013-11-08
> 14:02:53,772::image::1164::Storage.Image::(merge) Auto shrink after
> merge failed
> Traceback (most recent call last):
> File "/usr/share/vdsm/storage/image.py", line 1162, in merge
> srcVol.shrinkToOptimalSize()
> File "/usr/share/vdsm/storage/blockVolume.py", line 320, in
> shrinkToOptimalSize
> qemuImg.FORMAT.QCOW2)
> File "/usr/lib64/python2.6/site-packages/vdsm/qemuImg.py", line 109, in
> check
> raise QImgError(rc, out, err, "unable to parse qemu-img check
output")
> QImgError: ecode=0, stdout=['No errors were found on the image.'],
> stderr=[], message=unable to parse qemu-img check output
I'm not sure that it's the only problem in this flow, but there's a
clear bug in lib/vdsm/qemuImg.py's check() function: it fails to parse
the output of qemu-img.
Would you open a bug on that? I found no open one.
I remember that this was discussed and the agreement was that if the offset
is not reported by qemu-img we should have used the old method to calculate
the new volume size.
We'll probably need to verify it. Sander can you open a bug on this?
Thanks,
--
Federico