Cluster compatibility version and major upgrades
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? 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)? 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). 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)? -- Chris Adams <cma@cmadams.net>
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
On Thu, Mar 2, 2017 at 4:44 PM Yedidyah Bar David <didi@redhat.com> wrote:
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.
Right, but then people forget to do it later ;-) Y.
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
participants (3)
-
Chris Adams -
Yaniv Kaul -
Yedidyah Bar David