<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">btw, this happened on an aborted hosted-engine install. So, the ha-agents hadn't even started up.. just the VM running. </div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Jul 19, 2014 at 11:24 PM, Andrew Lau <span dir="ltr"><<a href="mailto:andrew@andrewklau.com" target="_blank">andrew@andrewklau.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div style="font-family:tahoma,sans-serif">Hi,</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">
Did anyone find much luck tracking this down? I rebooted one of our servers and hit this issue again, conveniently, the dell remote access card has borked as well.. so a 50 minute trip to the DC..</div><div><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 10:10 AM, Bob Doolittle <span dir="ltr"><<a href="mailto:bobddroid@gmail.com" target="_blank">bobddroid@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Specifically, if do the following:<br>
<ul>
<li>Enter global maintenance (hosted-engine --set-maintenance-mode
--mode=global)</li>
<li>init 0 the engine</li>
<li>systemctl stop ovirt-ha-agent ovirt-ha-broker libvirtd vdmsd</li>
</ul>
<br>
and then run "sanlock client status" I see:<br>
<br>
<pre># sanlock client status
daemon c715b5de-fd98-4146-a0b1-e9801179c768.xion2.smar
p -1 helper
p -1 listener
p -1 status
s 003510e8-966a-47e6-a5eb-3b5c8a6070a9:1:/rhev/data-center/mnt/<a href="http://xion2.smartcity.net" target="_blank">xion2.smartcity.net</a>\:_export_VM__NewDataDomain/003510e8-966a-47e6-a5eb-3b5c8a6070a9/dom_md/ids:0
s 18eeab54-e482-497f-b096-11f8a43f94f4:1:/rhev/data-center/mnt/xion2\:_export_vm_he1/18eeab54-e482-497f-b096-11f8a43f94f4/dom_md/ids:0
s hosted-engine:1:/rhev/data-center/mnt/xion2\:_export_vm_he1/18eeab54-e482-497f-b096-11f8a43f94f4/ha_agent/hosted-engine.lockspace:0
</pre>
<br>
Waiting a few minutes does not change this state.<br>
<br>
The earlier data I shared which showed HostedEngine was with a
different test scenario.<span><font color="#888888"><br>
<br>
-Bob</font></span><div><div><br>
<br>
<div>On 06/18/2014 07:53 AM, Bob Doolittle
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">I see I have a very unfortunate typo in my previous
mail. As supported by the vm-status output I attached, I had set
--mode=global (not none) in step 1.</p>
<p dir="ltr">I am not the only one experiencing this. I can
reproduce it easily. It appears that shutting down vdsm causes
the HA services to incorrectly think the system has come out of
Global Maintenance and restart the engine.</p>
<p dir="ltr">-Bob</p>
<div class="gmail_quote">On Jun 18, 2014 5:06 AM, "Federico
Simoncelli" <<a href="mailto:fsimonce@redhat.com" target="_blank">fsimonce@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----- Original Message -----<br>
> From: "Bob Doolittle" <<a href="mailto:bob@doolittle.us.com" target="_blank">bob@doolittle.us.com</a>><br>
> To: "Doron Fediuck" <<a href="mailto:dfediuck@redhat.com" target="_blank">dfediuck@redhat.com</a>>,
"Andrew Lau" <<a href="mailto:andrew@andrewklau.com" target="_blank">andrew@andrewklau.com</a>><br>
> Cc: "users" <<a href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>>,
"Federico Simoncelli" <<a href="mailto:fsimonce@redhat.com" target="_blank">fsimonce@redhat.com</a>><br>
> Sent: Saturday, June 14, 2014 1:29:54 AM<br>
> Subject: Re: [ovirt-users] Can HA Agent control NFS
Mount?<br>
><br>
><br>
> But there may be more going on. Even if I stop vdsmd, the
HA services,<br>
> and libvirtd, and sleep 60 seconds, I still see a lock
held on the<br>
> Engine VM storage:<br>
><br>
> daemon 6f3af037-d05e-4ad8-a53c-61627e0c2464.xion2.smar<br>
> p -1 helper<br>
> p -1 listener<br>
> p -1 status<br>
> s
003510e8-966a-47e6-a5eb-3b5c8a6070a9:1:/rhev/data-center/mnt/<a href="http://xion2.smartcity.net" target="_blank">xion2.smartcity.net</a>\:_export_VM__NewDataDomain/003510e8-966a-47e6-a5eb-3b5c8a6070a9/dom_md/ids:0<br>
> s
hosted-engine:1:/rhev/data-center/mnt/xion2\:_export_vm_he1/18eeab54-e482-497f-b096-11f8a43f94f4/ha_agent/hosted-engine.lockspace:0<br>
<br>
This output shows that the lockspaces are still acquired. When
you put hosted-engine<br>
in maintenance they must be released.<br>
One by directly using rem_lockspace (since it's the
hosted-engine one) and the other<br>
one by stopMonitoringDomain.<br>
<br>
I quickly looked at the ovirt-hosted-engine* projects and I
haven't found anything<br>
related to that.<br>
<br>
--<br>
Federico<br>
</blockquote>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>