On Sun, May 9, 2021 at 8:54 AM <j.vela...@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 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/TVTSOH5PT7YF6A6HB5YQZXH5WGJCO76L/
