<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Shankhadeep,<br>
      <br>
        Thanks for the reply. I'm just wondering about the second part
      of step 4. I can see why it would make sense as it would avoid NFS
      errors but will that not beak the hypervisor KVM processes?<br>
      <br>
              Regards,<br>
                Gerry<br>
      <br>
      <br>
      On 02/05/2014 03:41, Shankhadeep Shome wrote:<br>
    </div>
    <blockquote
cite="mid:CAOK6JGZqOZF3RgaUoHsJT=LvVCP4xRktOH=niXEMZOGCRNXjrA@mail.gmail.com"
      type="cite">
      <pre wrap="">I think suspend resume would work fine, I would do the following..

1. Disable network connectivity to the system thought some firewall rule so
you don't have active users on the system.
2. Pause all the VMs, this should keep your VMs safe.
3. Safely shut down your open nebula controller and database
4. Reconfigure your NFS server and restart it. You may also want to
dismount the nfs mounts on your hypervisors
5. Start up the vms in such a way that the virtual infrastructure comes up
before your application vms. Start iSCSI target vms before your initiators
try to connect to them, etc

I would take a close look at HA nfs services, glusterfs is another option
you might like to try. You don't need anything special for glusterfs.fuse
support in open nebula.




On Tue, Apr 29, 2014 at 2:53 PM, Michael <a class="moz-txt-link-rfc2396E" href="mailto:michael@onlinefusion.co.uk"><michael@onlinefusion.co.uk></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">Hi Gerry,

While I don't have any recommendations on the reboot process, if you're
using KVM I'd certainly recommend Ceph as a solution for high availability
storage. We've gone as far as rolling linux distribution upgrades to our
storage cluster with no loss of VM connectivity.

-Michael


On 29/04/2014 16:50, Gerry O'Brien wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">Hi,

    Our OpenNebula Debian Wheezy storage server has been running for 466
days and needs to be rebooted as there have been many kernel patches during
this time. It exports the datastores to the hosts using NFS.

    What is the best way to reboot the server in order to cause the least
amount of disruption to running VMs? I've thought about suspending all
running VMs, rebooting the storage server and resuming the VMs after the
storages serveris back. Would this work? Obviously, any VMs that have to
maintain real time connections would be in trouble, e.g. iSCSI mounts, but
would an ordinary machines resume successfully after the storage server
reboots. The host NFS mounts are as here: /datastores
nfs vers=4,bg,rw,_netdev,fsc,rsize=32768,wsize=32768,intr,noatime

    In general, is there a recommended way of providing HA storage to
hosts?

            Regards,
                Gerry


</pre>
        </blockquote>
        <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a>

</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Gerry O'Brien

Systems Manager
School of Computer Science and Statistics
Trinity College Dublin
Dublin 2
IRELAND

00 353 1 896 1341
</pre>
  </body>
</html>