On Tue, Feb 28, 2017 at 10:06 PM, Chris Adams <cma@cmadams.net> 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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users