<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="GENERATOR" content="GtkHTML/4.4.4">
</head>
<body>
mån 2013-07-29 klockan 13:26 +0200 skrev squadra:
<blockquote type="CITE">Hi Karli, </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">i already thought that i am the only one with that combination ;)<br>
</blockquote>
<br>
Well, I happen to be using Fedora as engine/hosts, but when it comes to the NFS-server, why settle for anything less, right?:) I imagine you´re in it for the same reason as me too; "the last word in filesystems"...<br>
<br>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">On Mon, Jul 29, 2013 at 1:11 PM, Karli Sjöberg <<a href="mailto:Karli.Sjoberg@slu.se">Karli.Sjoberg@slu.se</a>> wrote:
</blockquote>
<blockquote type="CITE">
<blockquote>ons 2013-07-24 klockan 23:35 +0200 skrev squadra: </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>
<blockquote type="CITE">Maybe found a workaround on the NFS server side, a option for the mountd service<br>
<br>
<br>
<br>
<br>
-S Tell mountd to suspend/resume execution of the nfsd threads when-<br>
ever the exports list is being reloaded. This avoids intermit-<br>
tent access errors for clients that do NFS RPCs while the exports<br>
are being reloaded, but introduces a delay in RPC response while<br>
the reload is in progress. If mountd crashes while an exports<br>
load is in progress, mountd must be restarted to get the nfsd<br>
threads running again, if this option is used.<br>
<br>
<br>
so far, i was able to reload the exports list twice, without any random suspended vm. lets see if this is a real solution or if i just had luck two times.<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>It would seem as if we are on the same boat:) Actually I hadn´t thought about it before, but you´re right; issuing a "service mountd reload" does pause a large number of VM´s, frickin annoying really. I mean, the NFS server doesn´t care what or
who it´s serving, you could be creating a new export for a completely different system, and not even have oVirt in mind before customers start to call, wondering why their VM´s have stopped responding!?<br>
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">exactly the same i have </blockquote>
<blockquote type="CITE"> </blockquote>
<blockquote type="CITE">
<blockquote>I actually tried that "-S" but it didn´t work for me at all, and looking at the man-page for mountd, there´s no mention of it either, even though we are presumably running the same version:<br>
# uname -r<br>
9.1-RELEASE<br>
<br>
Or are you perhaps tracking "-STABLE", and there´s a minor difference there? </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">i am tracking -STABLE, but the Man Page of "mountd" on a 9.1 Stable (Snapshot Release) also shows -S Parameter
</blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">9.1-STABLE FreeBSD 9.1-STABLE #0: Sun Jul 7 10:53:46 UTC 2013 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64<br>
<br>
</blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #6: Thu Jul 18 02:41:57 CEST 2013
<a href="mailto:root@filer1.intern.">root@filer1.intern.</a><br>
</blockquote>
<br>
OK, so we´re not using the same versions, -STABLE != -RELEASE, and I only use -RELEASE. But that explains it. I guess I can wait for 9.2-RELEASE to get rid of that nuisance. Thanks for the info!<br>
<br>
/Karli<br>
<br>
<blockquote type="CITE"><br>
</blockquote>
<blockquote type="CITE">´ </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">both systems provide -S for the mountd, and so far i didnt have any more problems. lets see if this keeps going good.
</blockquote>
<blockquote type="CITE">
<blockquote>
<blockquote type="CITE"><br>
<br>
but i am still interested in parameters which make the vdsm more tolerant to short interruptions. instant suspend of a vm after such a short "outage" is not very nice.<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote>+1! </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
/Karli </blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote><br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE"><br>
</blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Cheers, </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">Juergen </blockquote>
<blockquote type="CITE"><br>
<br>
</blockquote>
<blockquote type="CITE">--
<pre>
Sent from the Delta quadrant using Borg technology!
</pre>
</blockquote>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody>
<tr>
<td>-- <br>
<br>
Med Vänliga Hälsningar<br>
-------------------------------------------------------------------------------<br>
Karli Sjöberg<br>
Swedish University of Agricultural Sciences<br>
Box 7079 (Visiting Address Kronåsvägen 8)<br>
S-750 07 Uppsala, Sweden<br>
Phone: +46-(0)18-67 15 66<br>
<a href="mailto:karli.sjoberg@adm.slu.se">karli.sjoberg@slu.se</a> </td>
</tr>
</tbody>
</table>
</body>
</html>