<div dir="ltr"><div>Hello!<br><br></div>From my experience, updating my setup - 3 nodes + 1 engine ESXi VM; all F19 ovirt 3.2 -> 3.3 -.3.4 and now 3.4.1 with all 3 nodes acting also as gluster replicated nodes - you may also run into gluster issues - compatibility between different gluster version, slit-brain etc. - client&server when you apply gluster updates<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 12, 2014 at 9:47 AM, Itamar Heim <span dir="ltr"><<a href="mailto:iheim@redhat.com" target="_blank">iheim@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 05/12/2014 12:43 AM, Paul Heinlein wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, 11 May 2014, Itamar Heim wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just inherited an oVirt cluster at work that's running 3.2 on<br>
Fedora 18 and would dearly love some direction about updating<br>
things without a system-wide downtime.<br>
</blockquote>
<br>
1. no downtime should happen, as you can upgrade hosts by moving<br>
them to maintenance, which will live migrate VMs running on them.<br>
<br>
2. fedora 18 is EOL, so 'yum update' isn't going to help here.<br>
<br>
3. re-install host should refresh vdsm and its dependent packages if<br>
the repo's configured have newer versions. when the host is in<br>
maint, you can simply run 'yum update' on the host, then<br>
re-activate it (of course reboot if kernel got updated, etc.)<br>
</blockquote>
<br>
I've followed those steps, and I can get VMs migrated *to* the updated<br>
nodes. I have two worries:<br>
<br>
1. VMs migrated to the updated nodes cannot be migrated back to the<br>
old nodes. So once I start, it's all-in or nothing. Is that to be<br>
expected?<br>
</blockquote>
<br></div>
on fedora hosts this can happen, since there is no live migration compatibility between fedora versions.<br>
on .el6 hosts this shouldn't happen[1]<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Once all the nodes are backed up, is there a fairly sure-fire way<br>
to update the master engine? Is that documented somewhere?<br>
</blockquote>
<br></div>
a. you should be able to upgrade engine or hosts regardless of each<br>
other.<br>
b. the setup (upgrade) script takes a db backup just in case. if you<br>
happen to run it in a VM, snapshot/backing it up doesn't hurt as<br>
well.<br>
c. if upgrading to a new minor version, note to change in the upgraded<br>
engine the cluster and DC level to benefit from new features.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks!<br>
<br>
</blockquote>
<br>
[1] there is a known caveat is you have selinux disabled on some machines and enabled on others.<br>
</blockquote></div><br></div>