> On 6 Mar 2018, at 11:41, Nicolas Ecarnot <nico...@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@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@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users