<div dir="ltr">sanlock is at the latest version (this solved another problem we had a few days ago):<div><br></div><div><div>$ rpm -q sanlock</div><div>sanlock-2.6-7.fc18.x86_64</div><div><br></div><div>the storage is on the same machine as the engine and vdsm.</div>

<div>iptables is up but there is a rule to allow all localhost traffic.</div><div><br></div><br><div class="gmail_quote">On Sun, Mar 24, 2013 at 11:34 AM, Maor Lipchuk <span dir="ltr">&lt;<a href="mailto:mlipchuk@redhat.com" target="_blank">mlipchuk@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From the VDSM log, it seems that the master storage domain was not<br>
responding.<br>
<br>
Thread-23::DEBUG::2013-03-22<br>
18:50:20,263::domainMonitor::216::Storage.DomainMonitorThread::(_monitorDomain)<br>
Domain 1083422e-a5db-41b6-b667-b9ef1ef244f0 changed its status to Invalid<br>
....<br>
Traceback (most recent call last):<br>
  File &quot;/usr/share/vdsm/storage/domainMonitor.py&quot;, line 186, in<br>
_monitorDomain<br>
    self.domain.selftest()<br>
  File &quot;/usr/share/vdsm/storage/nfsSD.py&quot;, line 108, in selftest<br>
    fileSD.FileStorageDomain.selftest(self)<br>
  File &quot;/usr/share/vdsm/storage/fileSD.py&quot;, line 480, in selftest<br>
    self.oop.os.statvfs(self.domaindir)<br>
  File &quot;/usr/share/vdsm/storage/remoteFileHandler.py&quot;, line 280, in<br>
callCrabRPCFunction<br>
    *args, **kwargs)<br>
  File &quot;/usr/share/vdsm/storage/remoteFileHandler.py&quot;, line 180, in<br>
callCrabRPCFunction<br>
    rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)<br>
  File &quot;/usr/share/vdsm/storage/remoteFileHandler.py&quot;, line 146, in _recvAll<br>
    raise Timeout()<br>
Timeout<br>
.....<br>
<br>
I&#39;m also see a san lock issue, but I think that is because the storage<br>
could not be reached:<br>
ReleaseHostIdFailure: Cannot release host id:<br>
(&#39;1083422e-a5db-41b6-b667-b9ef1ef244f0&#39;, SanlockException(16, &#39;Sanlock<br>
lockspace remove failure&#39;, &#39;Device or resource busy&#39;))<br>
<br>
Can you try to see if the ip tables are running on your host, and if so,<br>
please check if it is blocking the storage server by any chance?<br>
Can you try to manually mount this NFS and see if it works?<br>
Is it possible the storage server got connectivity issues?<br>
<br>
<br>
Regards,<br>
Maor<br>
<div><div class="h5"><br>
On 03/22/2013 08:24 PM, Limor Gavish wrote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; I am using Ovirt 3.2 on Fedora 18:<br>
&gt; [wil@bufferoverflow ~]$ rpm -q vdsm<br>
&gt; vdsm-4.10.3-7.fc18.x86_64<br>
&gt;<br>
&gt; (the engine is built from sources).<br>
&gt;<br>
&gt; I seem to have hit this bug:<br>
&gt; <a href="https://bugzilla.redhat.com/show_bug.cgi?id=922515" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=922515</a><br>
&gt;<br>
&gt; in the following configuration:<br>
&gt; Single host (no migrations)<br>
&gt; Created a VM, installed an OS inside (Fedora18)<br>
&gt; stopped the VM.<br>
&gt; created template from it.<br>
&gt; Created an additional VM from the template using thin provision.<br>
&gt; Started the second VM.<br>
&gt;<br>
&gt; in addition to the errors in the logs the storage domains (both data and<br>
&gt; ISO) crashed, i.e went to &quot;unknown&quot; and &quot;inactive&quot; states respectively.<br>
&gt; (see the attached engine.log)<br>
&gt;<br>
&gt; I attached the VDSM and engine logs.<br>
&gt;<br>
&gt; is there a way to work around this problem?<br>
&gt; It happens repeatedly.<br>
&gt;<br>
&gt; Yuval Meir<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; <a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
&gt;<br>
<br>
<br>
</blockquote></div><br></div></div>