I take it back. send out that email after waiting for a while but now the client came back with an ERROR and all the processes got cleaned up. But it did take a while before failing.<br><br>Ranga<br><br><div class="gmail_quote">
On Tue, May 3, 2011 at 4:40 PM, Rangababu Chakravarthula <span dir="ltr"><<a href="mailto:rbabu@hexagrid.com">rbabu@hexagrid.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Lars<br><br>Thanks for the quick response. I tried to mount with soft option & without "retrans" option. Still its the same behaviour. The man page says without "retrans" option, it would try 3 times and fail. However, in my case it didn't.<br>

 <br>Also there is a note with regard to "soft" option <br><br><br><b>NB: A so-called "soft" timeout  can  cause  silent  data corruption  in  certain  cases.  As  such,  use the soft option only when client responsiveness is more important<br>

than  data  integrity.  Using NFS over TCP or increasing the value of the retrans option may mitigate some of the risks of using the soft option</b>.<br><br>Still trying to find a solution.<br><br><br>Ranga<div><div></div>
<div class="h5"><br><br><div class="gmail_quote">
On Tue, May 3, 2011 at 2:52 PM, Lars Kellogg-Stedman <span dir="ltr"><<a href="mailto:lars@seas.harvard.edu" target="_blank">lars@seas.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>> between all the hosts to allow live migration.  If for any reason NFS<br>
> connection is lost and user tries to create a new VM the following<br>
> opennebula commands hangs and sits there for over.<br>
<br>
</div>What mount options are you using for the storage?  In theory if you<br>
mount with '-o soft', processes blocked on access to the storage will<br>
eventually get an error.  This is from the nfs(5) man page:<br>
<br>
  If the soft option is  specified,  then  the  NFS  client fails an<br>
  NFS request after retrans retransmissions have been sent, causing the<br>
  NFS client to return an error to the calling application.<br>
<br>
In the sort of situation you describe, there's not really any way for<br>
OpenNebula to "check the storage connectivity", because any commands<br>
that attempt to access the storage will get stuck in exactly the same<br>
way.<br>
<font color="#888888"><br>
--<br>
Lars Kellogg-Stedman <<a href="mailto:lars@seas.harvard.edu" target="_blank">lars@seas.harvard.edu</a>><br>
Senior Technologist<br>
Harvard University SEAS<br>
Academic and Research Computing (ARC)<br>
</font></blockquote></div><br></div></div></blockquote></div><br>