11:03 p.m.
On Sun, May 9, 2021 at 8:54 AM <j.velasco(a)outlook.com> wrote:
Hello List,
I am facing the following issue when I try to import a VM from a KVM host to my oVirt
(4.4.5.11-1.el8).
The importing I done throuth GUI using the option of KVM provider.
-- Log1:
# cat /var/log/vdsm/import-57f84423-56cb-4187-86e2-f4208348e1f5-20210507T124121.log
[ 0.0] preparing for copy
[ 0.0] Copying disk 1/1 to
/rhev/data-center/mnt/blockSD/cc9fae8e-b714-44cf-9dac-3a83a15b0455/images/cb63ffc9-07ee-4323-9e8a-378be31ae3f7/e7e69cbc-47bf-4557-ae02-ca1c53c8423f
Traceback (most recent call last):
...
File
"/usr/lib64/python3.6/site-packages/ovirt_imageio/_internal/util.py", line 20,
in uninterruptible
return func(*args)
OSError: [Errno 28] No space left on device
Looks like the disk:
/rhev/data-center/mnt/blockSD/cc9fae8e-b714-44cf-9dac-3a83a15b0455/images/cb63ffc9-07ee-4323-9e8a-378be31ae3f7/e7e69cbc-47bf-4557-ae02-ca1c53c8423f
Was created with the wrong initial size.
When importing vms from libvirt I don't think we have a way to get the
required allocation
of the disk, so the disk must be created with
initial_size=virtual_size, and this was probably
not done in this case.
Please file a bug and include full vdsm from the SPM host and from the
host running the
import, and full engine logs. The log should show the creation of the
target disk
cb63ffc9-07ee-4323-9e8a-378be31ae3f7.
You can grep this uuid in vdsm logs (/var/log/vdsm/vdsm.log*) on the
spm host, the host
running the import, and engine host (/var/log/ovirt-engine/engine.log).
-- Details of the enviroment:
# df -Ph
Filesystem Size Used Avail Use%
Mounted on
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 4.0K 32G 1%
/dev/shm
tmpfs 32G 26M 32G 1% /run
tmpfs 32G 0 32G 0%
/sys/fs/cgroup
/dev/mapper/onn-ovirt--node--ng--4.4.5.1--0.20210323.0+1 584G 11G 573G 2% /
/dev/mapper/onn-home 1014M 40M 975M 4% /home
/dev/mapper/onn-tmp 1014M 40M 975M 4% /tmp
/dev/sda2 1014M 479M 536M 48% /boot
/dev/mapper/onn-var 30G 3.2G 27G 11% /var
/dev/sda1 599M 6.9M 592M 2%
/boot/efi
/dev/mapper/onn-var_log 8.0G 498M 7.6G 7%
/var/log
/dev/mapper/onn-var_crash 10G 105M 9.9G 2%
/var/crash
/dev/mapper/onn-var_log_audit 2.0G 84M 2.0G 5%
/var/log/audit
tmpfs 6.3G 0 6.3G 0%
/run/user/0
/dev/mapper/da3e3aff--0bfc--42cd--944f--f6145c50134a-master 976M 1.3M 924M 1%
/rhev/data-center/mnt/blockSD/da3e3aff-0bfc-42cd-944f-f6145c50134a/master
/dev/mapper/onn-lv_iso 12G 11G 1.6G 88%
/rhev/data-center/mnt/_dev_mapper_onn-lv__iso
172.19.1.80:/exportdomain 584G 11G 573G 2%
/rhev/data-center/mnt/172.19.1.80:_exportdomain
* Inodes available = 99%.
The available space on the host is not related, the issue is creating a big
enough disk when creating sparse volume on block storage.
# qemu-img info /var/lib/libvirt/images/vm_powervp-si.qcow2
image: /var/lib/libvirt/images/vm_powervp-si.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 4.2G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
Since you have access to the disk you want to import, you can upload
it to oVirt and create a new vm with the disk, instead of importing via
libvirt.
Nir