[ovirt-users] question mark in oVirt - "cannot acquire state change lock"

[paf1 at email.cz]

Hello,
some requested outputs

Vdsm generate a huge count of records in time, so I'm not shure if 
"hang" time is still included .
Problems occured 17-feb-2016 17:00-18:00 when VM shutdown was requested.
But some performance problems occured a day before ( I'm not shure about 
application problem = JAVA = running EBS )

In mail before  I attached pointers to bugs with any workaround

killall -9 libvirtd
rm /var/run/libvirtd.pid
/etc/init.d/libvirt-bin restart

which would solve current situation.
Is this  workaround safe enought?? Will stay VMs running ???

THX for any help, because I can't reboot hypervizor due huge DB traffic 
and no VM migration possibility via oVirt engine. ( mem synchro 
overloaded ?? )

Pa.
PS: logs sent directly to RH.


On 17.2.2016 08:22, Nir Soffer wrote:
> On Tue, Feb 16, 2016 at 9:58 PM, paf1 at email.cz <paf1 at email.cz> wrote:
>> Hello all,
>> how can I eliminate question mark from "hanged" VM? ( it happened in
>> shutdown process via oVirt  env. )
>> Best solution without hypervizor reboot, meaning "power off" , "kill" or
>> another workaround for that VM .
>> Will help removing task DB record from oVirt mgmt server - if exists ,
>> ofcourse ??
>> Running  gluster 3.7.5 / oVirt 3.5.2 /
>> libvirt-daemon-kvm-1.2.8-16.el7_1.5.x86_64  on centos 7.1.1503 .
>>
>> thx a lot.
>> Pa.
>>
>> PS: I found similar problem in libvirt library a many years ago ( redhat 5.6
>> )
>>     https://bugzilla.redhat.com/show_bug.cgi?id=676205
>>     https://bugzilla.redhat.com/show_bug.cgi?id=668438
>> problem explanation:
>> http://linux.india365.org/2012/01/libvirt-virsh-cannot-acquire-state-change-lock-error-explained/
> This is very interesting, I have seen this error in testing
> environment on rhel 7.1 or 7.2.
>
> Can you provide vdsm logs showing the time of the error?
>
> Nir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20160217/e28c8a02/attachment.html>