<div dir="ltr">Hello!<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 7:02 PM, Joe DiTommasso <span dir="ltr">&lt;<a href="mailto:jdito@domeyard.com" target="_blank">jdito@domeyard.com</a>&gt;</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>Hi, I&#39;m currently running an out-of-date (3.6) 3-node oVirt cluster, using NFS storage. I&#39;d like to upgrade to the latest release and move to a hyperconverged setup, but I&#39;ve only got the three hosts to play with. I&#39;m currently thinking of pulling one node from my current cluster, rebuilding it to start a new cluster, and then migrating VMs/physical hosts over to the new cluster. Is that something that would seem feasible? I&#39;ve read the documentation on setting up a hyperconverged cluster, but didn&#39;t see anything about adding new hosts after cluster deployment.Thanks!<span class="HOEnZb"><font color="#888888"><br><br></font></span></div></div></blockquote><div><br></div><div><br></div><div>Well, first of all - it is very tricky and risky. We have a good reason to require 3 hosts in HC cluster - data redundancy and service reliability. If you have luxury of turning everything down and upgrading using backup/restore or something similar - please, go this way.</div><div><br></div><div><br></div><div>But in case you really really really need to upgrade your deployment in your way, you can try following:</div><div><br></div><div>* Backup first :-)</div><div>* Upgrade your OS to the maximum version supported by 3.6 and any of the next ovirt releases. You can also try to upgrade ovirt first.</div><div>* Remove one of the nodes from your cluster</div><div>* Manually install gluster servers on all 3 nodes and create a replicated volumes for your future engine and vms</div><div>* Deploy HE on the free node, using existing gluster volumes</div><div>* Migrate VMs to that engine.</div><div>* One by one remove hosts from your old cluster and add them to your new cluster</div><div>* When you will finish that, backup again :) and try to continue your upgrade.</div><div><br></div><div>The whole idea of the process, described above, is to provide you with gluster replica 3 volume from the very beginning. Technically you can use a single brick distributed volume to install new engine and migrate VMs to your new cluster, but problems with that single brick distributed volume will affect all your VMs.</div><div><br></div><div><br></div><div>Another one option for you is to make replicated volume in a single host. If you have enough space for keeping data thee times, you can:</div><div><br></div><div>* Backup (!)</div><div>* Remove one of the hosts from service, upgrade it</div><div>* And after that create replica 3 volumes for the engine and VMs, using 6 _local_ bricks</div><div>* Migrate VMs from one of your hosts</div><div>* Upgrade that second hosts, add it to your new cluster and manually migrate two bricks (one brick per volume) from the first host to the second host. </div><div>* Repeat for remaining host</div><div><br></div><div>Both approaches are VERY risky and highly THEORETICAL. I don&#39;t think anyone ever did that, so think twice before doing that. Following any of those scenario requires you to deeply understand, what are you doing and involves a lot of work in console. Seriously, thnk one more time before following them.</div></div></div></div>