On Tue, Feb 28, 2017 at 10:06 PM, Chris Adams <cma(a)cmadams.net&gt; wrote: > Hello again, still working on my upgrade from 3.5... > > I'm trying to understand the cluster compatibility version setting and > how that applies to major upgrades. Do I have to always raise the > compatibility version when I do a major upgrade? Not immediately.

Doing this will let you use the new features. > In other words, when I > upgrade from 3.5 to 3.6, do I need to raise it to 3.6 before I upgrade > to 4.0 (and then again raise it 4.0 before upgrading to 4.1)? Each engine version has a set of supported compatibility levels. If you run engine-setup and have a cluster/DC with a too-old level, it will refuse to upgrade. > > It looks like the 3.6->4.0 EL6->EL7 migration requires the cluster > compatibility level to be at 3.6 (if I'm reading things right). Indeed. > > It appears that when I upgrade to 3.6, I will have to stop all running > VMs to raise the compatibility version (and I found an open bug about > whether that's possible with the hosted engine). It sounds like with > 4.0, the VMs can be flagged for compatibility and I can reboot them > individually. I have over 80 VMs, many behind a load balancer (for HA > and load sharing), but taking them all down will obviously still > interrupt service for a while. > > Is there a safe way around that? > > I saw someone mention they partitioned their servers and made a new > cluster (with the new version), and migrated VMs from cluster to > cluster. Can I do live migrations in that case? How do I get the > hosted engine from one cluster to another (especially with starting at > 3.5)? You'll definitely need hosted-engine downtime, but that's usually not an issue. For your other VMs, not sure - I think that if you get a mark saying they should be rebooted, they should. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1336527 Best, -- Didi _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users