On Mon, Mar 14, 2016 at 5:05 PM, Marcelo Leandro <marcelol...@gmail.com> wrote: > > > Is it cold (the VM is down) or live (the VM is up) merge (snapshot > deletion)? > > VM is up > > What version are you running? > > oVirt Engine Version: 3.6.3.4-1.el7.centos > > > Can you please share engine and vdsm logs? > > yes.
Looking in your vdsm log, I see this error (454 times in 6 hours), which looks like a bug: periodic/5::ERROR::2016-03-12 09:28:02,847::executor::188::Executor::(_execute_task) Unhandled exception in <NumaInfoMonitor vm=8d41b39a-5995-41a0-9807-7d9a6af308a5 at 0x7f898836f090> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 186, in _execute_task callable() File "/usr/share/vdsm/virt/periodic.py", line 279, in __call__ self._execute() File "/usr/share/vdsm/virt/periodic.py", line 324, in _execute self._vm.updateNumaInfo() File "/usr/share/vdsm/virt/vm.py", line 5071, in updateNumaInfo self._numaInfo = numaUtils.getVmNumaNodeRuntimeInfo(self) File "/usr/share/vdsm/numaUtils.py", line 116, in getVmNumaNodeRuntimeInfo vnode_index = str(vcpu_to_vnode[vcpu_id]) KeyError: 1 Adding Francesco and Martin to look at this. > > Please note that at some point we try to verify that image was removed by > running getVolumeInfo hence, the volume not found is expected. The thing is, > that you say that volume does exist. > Can you run following command on the host: > > vdsClient -s 0 getVolumeInfo <sd> <sp> <img> <vol> > > return the command: > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# vdsClient -s 0 > getVolumeInfo c2dc0101-748e-4a7b-9913-47993eaa52bd > 77e24b20-9d21-4952-a089-3c5c592b4e6d 93633835-d709-4ebb-9317-903e62064c43 > 948d0453-1992-4a3c-81db-21248853a88a > Volume does not exist: ('948d0453-1992-4a3c-81db-21248853a88a',) > > after restarting the host where vm was on, the link discs in image_group_id > was broken but was not removed. > > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 10:04 215a902a-1b99-403b-a648-21977dd0fa78 > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/215a902a-1b99-403b-a648-21977dd0fa78 > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:28 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:31 3fba372c-4c39-4843-be9e-b358b196331d > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/3fba372c-4c39-4843-be9e-b358b196331d > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 08:44 5097df27-c676-4ee7-af89-ecdaed2c77be > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5097df27-c676-4ee7-af89-ecdaed2c77be > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:23 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:12 7d9b6ed0-1125-4215-ab76-37bcda3f6c2d > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/7d9b6ed0-1125-4215-ab76-37bcda3f6c2d > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 10:13 948d0453-1992-4a3c-81db-21248853a88a > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/948d0453-1992-4a3c-81db-21248853a88a > lrwxrwxrwx. 1 vdsm kvm 78 Nov 27 22:30 b47f58e0-d576-49be-b8aa-f30581a0373a > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/b47f58e0-d576-49be-b8aa-f30581a0373a > lrwxrwxrwx. 1 vdsm kvm 78 Mar 11 22:01 c598bb22-a386-4908-bfa1-7c44bd764c96 > -> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/c598bb22-a386-4908-bfa1-7c44bd764c96 > > > You question is not clear. Can you explain what is the unexpected behavior? > > the link to the lvm should not be deleted after deleting the snapshot? > > > Thanks > > 2016-03-14 10:14 GMT-03:00 Nir Soffer <nsof...@redhat.com>: >> >> On Sat, Mar 12, 2016 at 3:10 PM, Marcelo Leandro <marcelol...@gmail.com> >> wrote: >> > Good morning >> > >> > I have a doubt, when i do a snapshot, a new lvm is generated, however >> > when I delete this snapshot the lvm not off, that's right? >> >> You question is not clear. Can you explain what is the unexpected >> behavior? >> >> To check if an lv created or removed by ovirt, you can do: >> >> pvscan --cache >> lvs vg-uuid >> >> Nir >> >> > >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# ls >> > 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 >> > 7d9b6ed0-1125-4215-ab76-37bcda3f6c2d >> > 3fba372c-4c39-4843-be9e-b358b196331d >> > b47f58e0-d576-49be-b8aa-f30581a0373a >> > 5097df27-c676-4ee7-af89-ecdaed2c77be >> > c598bb22-a386-4908-bfa1-7c44bd764c96 >> > 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# ls -l >> > total 0 >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:28 >> > 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:31 >> > 3fba372c-4c39-4843-be9e-b358b196331d -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/3fba372c-4c39-4843-be9e-b358b196331d >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 08:44 >> > 5097df27-c676-4ee7-af89-ecdaed2c77be -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5097df27-c676-4ee7-af89-ecdaed2c77be >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:23 >> > 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:12 >> > 7d9b6ed0-1125-4215-ab76-37bcda3f6c2d -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/7d9b6ed0-1125-4215-ab76-37bcda3f6c2d >> > lrwxrwxrwx. 1 vdsm kvm 78 Nov 27 22:30 >> > b47f58e0-d576-49be-b8aa-f30581a0373a -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/b47f58e0-d576-49be-b8aa-f30581a0373a >> > lrwxrwxrwx. 1 vdsm kvm 78 Mar 11 22:01 >> > c598bb22-a386-4908-bfa1-7c44bd764c96 -> >> > >> > /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/c598bb22-a386-4908-bfa1-7c44bd764c96 >> > >> > >> > >> > disks snapshot: >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info >> > 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 >> > image: 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 >> > file format: qcow2 >> > virtual size: 112G (120259084288 bytes) >> > disk size: 0 >> > cluster_size: 65536 >> > backing file: >> > ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a >> > backing file format: raw >> > Format specific information: >> > compat: 0.10 >> > refcount bits: 16 >> > >> > >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info >> > 3fba372c-4c39-4843-be9e-b358b196331d >> > image: 3fba372c-4c39-4843-be9e-b358b196331d >> > file format: qcow2 >> > virtual size: 112G (120259084288 bytes) >> > disk size: 0 >> > cluster_size: 65536 >> > backing file: >> > ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a >> > backing file format: raw >> > Format specific information: >> > compat: 0.10 >> > refcount bits: 16 >> > >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info >> > 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 >> > image: 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 >> > file format: qcow2 >> > virtual size: 112G (120259084288 bytes) >> > disk size: 0 >> > cluster_size: 65536 >> > backing file: >> > ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a >> > backing file format: raw >> > Format specific information: >> > compat: 0.10 >> > refcount bits: 16 >> > >> > >> > disk base: >> > [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info >> > b47f58e0-d576-49be-b8aa-f30581a0373a >> > image: b47f58e0-d576-49be-b8aa-f30581a0373a >> > file format: raw >> > virtual size: 112G (120259084288 bytes) >> > disk size: 0 >> > >> > >> > Thanks. >> > _______________________________________________ >> > 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