[ovirt-users] Snapshot remove bug (this time from the GUI)

Soeren Malchow soeren.malchow at mcon.net
Mon Jun 1 07:51:03 UTC 2015


Dear all,

The problem i already sent a few mails about now came up while removing a snapshot from the GUI, the otput in the log files was exactly the same.

In vdsm.log

Thread-189739::DEBUG::2015-06-01 09:39:10,001::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 68 edom: 10 level: 2 message: Timed out during operation: cannot acquire state change lock
Thread-189739::ERROR::2015-06-01 09:39:10,002::vm::5761::vm.Vm::(queryBlockJobs) vmId=`e640e9ef-1862-425a-8bdb-9cdfb0583f04`::Error getting block job info
Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs
    liveInfo = self._dom.blockJobInfo(drive.name, 0)
  File "/usr/share/vdsm/virt/vm.py", line 697, in f
    raise toe
TimeoutError: Timed out during operation: cannot acquire state change lock



——

journalctl

This

un 01 09:33:30 mc-dc3ham-compute-03-live.mc.mcon.net libvirtd[1801]: Cannot start job (modify, none) for domain fab-cms-app-01-qa-fab-mcon-net; current job is (modify, none) owned by (1829, 0)
Jun 01 09:33:30 mc-dc3ham-compute-03-live.mc.mcon.net libvirtd[1801]: Timed out during operation: cannot acquire state change lock
Jun 01 09:33:30 mc-dc3ham-compute-03-live.mc.mcon.net vdsm[7003]: vdsm root ERROR Unhandled exception
                                                                  Traceback (most recent call last):
                                                                    File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 809, in wrapper
                                                                      return f(*a, **kw)
                                                                    File "/usr/share/vdsm/virt/vm.py", line 6107, in run
                                                                      self.tryPivot()
                                                                    File "/usr/share/vdsm/virt/vm.py", line 6092, in tryPivot
                                                                      ret = self.vm._dom.blockJobAbort(self.drive.name, flags)
                                                                    File "/usr/share/vdsm/virt/vm.py", line 697, in f
                                                                      raise toe
                                                                  TimeoutError: Timed out during operation: cannot acquire state change lock

An this


Jun 01 09:33:45 mc-dc3ham-compute-03-live.mc.mcon.net libvirtd[1801]: Cannot start job (modify, none) for domain fab-cms-app-01-qa-fab-mcon-net; current job is (modify, none) owned by (1829, 0)
Jun 01 09:33:45 mc-dc3ham-compute-03-live.mc.mcon.net libvirtd[1801]: Timed out during operation: cannot acquire state change lock
Jun 01 09:33:45 mc-dc3ham-compute-03-live.mc.mcon.net vdsm[7003]: vdsm vm.Vm ERROR vmId=`e640e9ef-1862-425a-8bdb-9cdfb0583f04`::Error getting block job info
                                                                  Traceback (most recent call last):
                                                                    File "/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs
                                                                      liveInfo = self._dom.blockJobInfo(drive.name, 0)
                                                                    File "/usr/share/vdsm/virt/vm.py", line 697, in f
                                                                      raise toe
                                                                  TimeoutError: Timed out during operation: cannot acquire state change lock


—

And again the only solution to get the virtual machine back was to set the hypervisor host into maintenance, which does not completely work because the VM will stay on the host for ovirt and then reboot the host, after the reboot the virtual machine will be ok again (or restarted of configured to be highly acvailable)

This is a huge problem, using a GUI command that causes the need to reboot a complete hypervisor really worries me.

Regards
Soeren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150601/9fe17117/attachment-0001.html>


More information about the Users mailing list