[ovirt-users] Importing VM fails with "No space left on device"

[Michal Skrivanek]

> On 6 Mar 2018, at 11:41, Nicolas Ecarnot <nicolas at ecarnot.net> wrote:
> 
> Hello,
> 
> When importing a VM, I'm facing the know bug :
> https://access.redhat.com/solutions/2770791
> 
> QImgError: ecode=1, stdout=[], stderr=['qemu-img: error while writing sector 93569024: No space left on device'
> 
> The difference between my case and what is described in the RH webpage is that I have no "Failed to flush the refcount block cache".
> 
> Here is what I see :
> 
>> ecfbd1a4-f9d2-463a-ade6-def5bd217b43::DEBUG::2018-03-06 09:57:36,460::utils::718::root::(watchCmd) FAILED: <err> = ['qemu-img: error while writing sector 205517952: No space left on device']; <rc> = 1
>> ecfbd1a4-f9d2-463a-ade6-def5bd217b43::ERROR::2018-03-06 09:57:36,460::image::865::Storage.Image::(copyCollapsed) conversion failure for volume ac08bc8d-1eea-449a-a102-cf763c6726c8 Traceback (most recent call last):
>>  File "/usr/share/vdsm/storage/image.py", line 860, in copyCollapsed
>>    volume.fmt2str(dstVolFormat))
>>  File "/usr/lib/python2.7/site-packages/vdsm/qemuimg.py", line 207, in convert
>>    raise QImgError(rc, out, err)
>> QImgError: ecode=1, stdout=[], stderr=['qemu-img: error while writing sector 205517952: No space left on device'], message=None
>> ecfbd1a4-f9d2-463a-ade6-def5bd217b43::ERROR::2018-03-06 09:57:36,461::image::878::Storage.Image::(copyCollapsed) Unexpected error
>> Traceback (most recent call last):
>>  File "/usr/share/vdsm/storage/image.py", line 866, in copyCollapsed
>>    raise se.CopyImageError(str(e))
>> CopyImageError: low level Image copy failed: ("ecode=1, stdout=[], stderr=['qemu-img: error while writing sector 205517952: No space left on device'], message=None",)
> 
> I followed the advices in the RH webpage (check if the figures are correct between the qemu-img sizes and the meta-data file), and they seem to be correct :
> 
> root at serv-hv-adm30:/etc# qemu-img info /rhev/data-center/mnt/serv-lin-adm1.sdis.isere.fr\:_home_vmexport3/be2878c9-2c46-476b-bfae-8b02a4679022/images/a5d68d88-3b54-488d-a61e-7995a1906994/ac08bc8d-1eea-449a-a102-cf763c6726c8
> image: /rhev/data-center/mnt/serv-lin-adm1.sdis.isere.fr:_home_vmexport3/be2878c9-2c46-476b-bfae-8b02a4679022/images/a5d68d88-3b54-488d-a61e-7995a1906994/ac08bc8d-1eea-449a-a102-cf763c6726c8
> file format: qcow2
> virtual size: 98G (105226698752 bytes)
> disk size: 97G
> cluster_size: 65536
> Format specific information:
>    compat: 0.10
>    refcount bits: 16
> 
> root at serv-hv-adm30:/etc# cat /rhev/data-center/mnt/serv-lin-adm1.sdis.isere.fr\:_home_vmexport3/be2878c9-2c46-476b-bfae-8b02a4679022/images/a5d68d88-3b54-488d-a61e-7995a1906994/ac08bc8d-1eea-449a-a102-cf763c6726c8.meta DOMAIN=be2878c9-2c46-476b-bfae-8b02a4679022
> CTIME=1520318755
> FORMAT=COW
> DISKTYPE=1
> LEGALITY=LEGAL
> SIZE=205520896
> VOLTYPE=LEAF
> DESCRIPTION=
> IMAGE=a5d68d88-3b54-488d-a61e-7995a1906994
> PUUID=00000000-0000-0000-0000-000000000000
> MTIME=0
> POOL_UUID=
> TYPE=SPARSE
> EOF
> 
> 
> So I don't see what's wrong?

worth sharing with libguestfs users list, please attach the v2v logs (and versions used) so they can take a look

> 
> -- 
> Nicolas ECARNOT
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
>