[ovirt-users] low level Image copy failed
jonas.israelsson at elementary.se
Sun Oct 23 18:57:14 UTC 2016
On 23/10/16 20:06, Nir Soffer wrote:
> On Sun, Oct 23, 2016 at 5:34 PM, Jonas Israelsson
> <jonas.israelsson at elementary.se> wrote:
>> We are in the process of migrating from oVirt 3.6 to 4.0. To properly test
>> 4.0 we have setup a parallel 4.0 environment.
>> For the non critical vm:s we thought we try the "export vms --> move storage
>> domain to the other DC --> import vms" method.
>> While many imports are successful quite a few fails with 'low level Image
>> copy failed'
>> One of these vm impossible to import have the following disk layout.
>> * Disk 1 - 100GB (Thin)
>> * Disk2 - 32GB (Preallocated)
> According to the volume .meta file bellow, this is COW/SPARSE,
> not preallocated.
It's because I'm an idiot and gave you information about the wrong disk.
$ /usr/bin/qemu-img.org info
file format: raw
virtual size: 35G (37849399296 bytes)
disk size: 35G
[root at patty tmp]# cat
> Can you share the original vm disk metadata before the export?
Could you please instruct me how to ? It's on a FC-LUN so it's then
hiding on a lv somewhere. I could perhaps just move it to an nfs data
domain .. ?
> Looking at the metadata before the export, after the export, and after
> the import, we can understand what is the root cause.
> It will be hard to find the metadata after the failed copy since vdsm try
> hard to clean up after errors, but the information should be available
> in vdsm log.
Yes I noticed, hence the qemu-img wrapper
>> * Disk3 - 32GB (Thin)
>> Where the two thin disk (1 & 3) are successfully imported but disk2, the
>> preallocated always fail.
>> and from vdsm.log
>> CopyImageError: low level Image copy failed: ('ecode=1, stdout=,
>> stderr=qemu-img: error while writing sector 73912303: No space left on
>> device\n, message=None',)
> We need log from the entire flow, starting at "Run and protect: copyImage..."
>> The first checking the size of the image (37849399296) , and the second the
>> size of logical volume (34359738368) just created to hold this image.
>> And as you can see the volume is smaller in size than the image it should
>> hold, whereas we are under the impression something made an incorrect
>> decision when creating that volume.
> The destination image size depend on the destination format. If the destination
> is preallocated, the logical volume size *must* be the virtual size
> (32G). If it is
> sparse, the logical volume should be the file size on the export domain (35G).
> According to your findings, we created a destination image for a preallocated
> disk (32G), and then tried to run "qemu-img convert" with qcow2 format as
> both source and destination. However this is only a guess, since I don't have
> the log showing the actual qemu-img command.
12:37:15 685557156 --- Identifier: 51635 , Arguments: convert -p -t
none -T none -f raw
> Please share complete engine and vdsm logs showing the entire flow.
In vdsm.log search for 12:37:15
More information about the Users