[ovirt-users] low level Image copy failed

[Nir Soffer]

On Sun, Oct 23, 2016 at 5:34 PM, Jonas Israelsson
<jonas.israelsson at elementary.se> wrote:
> Greetings.
>
> 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.

Can you share the original vm disk metadata before the export?

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.

> * 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.

Please share complete engine and vdsm logs showing the entire flow.

Nir