Bug 1241149 - [RFE] Provide way to preform in-cluster upgrade of hosts from el6->el7.
Summary: [RFE] Provide way to preform in-cluster upgrade of hosts from el6->el7.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-3.6.6
: 3.6.6
Assignee: Roman Mohr
QA Contact: Artyom
URL: https://www.ovirt.org/feature/inclust...
Whiteboard:
Depends On:
Blocks: 1301447
TreeView+ depends on / blocked
 
Reported: 2015-07-08 14:55 UTC by Yaniv Lavi
Modified: 2016-08-01 03:36 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-13 10:38:00 UTC
oVirt Team: SLA


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2112361 None None None 2016-01-05 10:29:32 UTC
Red Hat Product Errata RHEA-2016:1743 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0 GA Enhancement (ovirt-engine) 2016-09-02 21:54:01 UTC
oVirt gerrit 45851 master MERGED core: Support configurable mixed RHEL 6, 7 check 2016-03-28 08:20:59 UTC
oVirt gerrit 48845 master MERGED scheduler: Add in-cluster upgrade policy units 2016-03-29 03:38:24 UTC
oVirt gerrit 49642 ovirt-engine-3.6 MERGED scheduler: Add in-cluster upgrade policy units 2016-03-30 11:31:58 UTC
oVirt gerrit 49643 ovirt-engine-3.6 MERGED core: Support configurable mixed RHEL 6, 7 check 2016-03-30 09:01:25 UTC
oVirt gerrit 50114 master MERGED core: Check if cluster upgrade can be started or stopped 2016-03-29 04:42:58 UTC
oVirt gerrit 50202 master MERGED core: Improve Host OS detection 2016-03-29 04:42:06 UTC
oVirt gerrit 50203 ovirt-engine-3.6 MERGED core: Improve Host OS detection 2016-03-30 11:32:41 UTC
oVirt gerrit 50250 ovirt-engine-3.6 MERGED core: Check if cluster upgrade can be started or stopped 2016-03-30 11:33:15 UTC
oVirt gerrit 50325 master MERGED core: Add InClusterUpgrade policy 2016-03-29 04:42:18 UTC
oVirt gerrit 50412 master MERGED core: Do not enforce affinity groups while in upgrade mode 2016-03-29 04:43:25 UTC
oVirt gerrit 50418 master ABANDONED core: Use stomp if possible on cluster upgrade 2016-03-29 07:53:26 UTC
oVirt gerrit 50487 ovirt-engine-3.6 MERGED core: Add InClusterUpgrade policy 2016-03-30 11:33:50 UTC
oVirt gerrit 50488 ovirt-engine-3.6 MERGED core: Do not enforce affinity groups while in upgrade mode 2016-03-30 11:34:24 UTC
oVirt gerrit 50489 ovirt-engine-3.6 ABANDONED core: Use stomp if possible on cluster upgrade 2016-03-29 07:51:19 UTC
oVirt gerrit 50660 ovirt-engine-3.6 MERGED core: Forbid suspending VMs while cluster is upgrading 2016-03-30 11:34:59 UTC
oVirt gerrit 50661 ovirt-engine-3.6 MERGED core: Do not allow binding VMs to hosts during cluster upgrade 2016-03-30 11:36:50 UTC
oVirt gerrit 50665 master MERGED core: Forbid suspending VMs while cluster is upgrading 2016-03-29 04:43:41 UTC
oVirt gerrit 50666 master MERGED core: Do not allow binding VMs to hosts during cluster upgrade 2016-03-29 04:43:59 UTC
oVirt gerrit 50704 ovirt-engine-3.6 MERGED core: Treat specific different OS types as equal 2016-03-30 11:37:22 UTC
oVirt gerrit 50707 master MERGED core: Treat different OS types as equal 2016-03-29 04:44:32 UTC
oVirt gerrit 54319 ovirt-engine-3.6 MERGED core: Generate human readable error messages for cluster upgrade 2016-03-30 11:38:05 UTC
oVirt gerrit 54869 ovirt-engine-3.6 MERGED scheduler: Give newest host OS versions the best weight on VM startup 2016-03-30 11:38:37 UTC
oVirt gerrit 55007 master MERGED core: Generate human readable error messages for cluster upgrade 2016-03-29 04:45:05 UTC
oVirt gerrit 55008 master MERGED scheduler: Give newest host OS versions the best weight on VM startup 2016-03-29 05:02:52 UTC
oVirt gerrit 55565 master MERGED scheduler: Store correct OS version in map 2016-04-02 18:15:29 UTC
oVirt gerrit 55566 ovirt-engine-3.6 MERGED scheduler: Store correct OS version in map 2016-04-04 12:14:40 UTC
oVirt gerrit 55590 ovirt-engine-3.6.5 MERGED core: Support configurable mixed RHEL 6, 7 check 2016-04-05 13:33:26 UTC
oVirt gerrit 55591 ovirt-engine-3.6.5 MERGED scheduler: Add in-cluster upgrade policy units 2016-04-05 13:33:36 UTC
oVirt gerrit 55592 ovirt-engine-3.6.5 MERGED core: Improve Host OS detection 2016-04-05 13:33:55 UTC
oVirt gerrit 55593 ovirt-engine-3.6.5 MERGED core: Check if cluster upgrade can be started or stopped 2016-04-05 13:34:00 UTC
oVirt gerrit 55594 ovirt-engine-3.6.5 MERGED core: Add InClusterUpgrade policy 2016-04-05 13:33:51 UTC
oVirt gerrit 55595 ovirt-engine-3.6.5 MERGED core: Do not enforce affinity groups while in upgrade mode 2016-04-05 13:33:46 UTC
oVirt gerrit 55596 ovirt-engine-3.6.5 MERGED core: Forbid suspending VMs while cluster is upgrading 2016-04-05 13:34:19 UTC
oVirt gerrit 55597 ovirt-engine-3.6.5 MERGED core: Do not allow binding VMs to hosts during cluster upgrade 2016-04-05 13:34:10 UTC
oVirt gerrit 55598 ovirt-engine-3.6.5 MERGED core: Treat specific different OS types as equal 2016-04-05 13:34:05 UTC
oVirt gerrit 55599 ovirt-engine-3.6.5 MERGED core: Generate human readable error messages for cluster upgrade 2016-04-05 13:34:14 UTC
oVirt gerrit 55600 ovirt-engine-3.6.5 MERGED scheduler: Give newest host OS versions the best weight on VM startup 2016-04-05 13:33:41 UTC
oVirt gerrit 55601 ovirt-engine-3.6.5 MERGED scheduler: Store correct OS version in map 2016-04-05 13:33:31 UTC
Red Hat Bugzilla 1251722 None None None Never

Internal Links: 1251722

Description Yaniv Lavi 2015-07-08 14:55:14 UTC
Description of problem:
From 3.6 customer will start moving production environment from el6 to el7 either via upgrade or reinstall. We need to enable adding el7 hosts in that situation and only allow VMs to migrate from el6 to el7 and not back. Then customer can start re-provisioning  hosts and not need to create new cluster and move hosts that can be a risk to the VMs.

Comment 4 Yaniv Lavi 2015-08-09 08:16:07 UTC
This is critical to existing customers looking to upgrade to 3.6. Made this request more general to allow engineering to suggest any design that will allow this.

Comment 5 Michal Skrivanek 2015-08-21 14:24:28 UTC
(In reply to Yaniv Dary from comment #4)
> This is critical to existing customers looking to upgrade to 3.6. Made this
> request more general to allow engineering to suggest any design that will
> allow this.

in 3.5 we decided that the way to upgrade is via a new cluster and cross-cluster one way migration.
How could this be critical?

Comment 6 Julio Entrena Perez 2015-08-21 14:32:56 UTC
(In reply to Michal Skrivanek from comment #5)
> How could this be critical?

The current approach implies:
- creating a new additional cluster for each already existing cluster.
- configuring each new cluster with the same settings (memory optimization, cluster policy, etc) as in the corresponding "old" cluster.
- apply the same permissions to the new clusters as in the old clusters.

Some customers have hundreds of clusters.

Comment 7 Michal Skrivanek 2015-08-21 14:41:59 UTC
(In reply to Julio Entrena Perez from comment #6)
> (In reply to Michal Skrivanek from comment #5)
> > How could this be critical?
> 
> The current approach implies:
> - creating a new additional cluster for each already existing cluster.

not for each, it can be only one new cluster for the duration of conversion.
And since you anyway don't want to keep the empty old cluster around once all hosts from that cluster are upgraded, you can move hosts back to the original cluster (once all el6 hosts are gone, the first el7 host added will make it a el7 cluster)

> - configuring each new cluster with the same settings (memory optimization,
> cluster policy, etc) as in the corresponding "old" cluster.

for the conversion, yes, it indeed should be the same....but it depends on the scale. When the upgrade is fast (small environment, few hosts in cluster) you may not need 1:1 functionality, especially when you don't have extra set of hosts you will be running in degraded mode anyway (some hosts old, some new - without a way how to load-balance the load)

> - apply the same permissions to the new clusters as in the old clusters.
> 
> Some customers have hundreds of clusters.

then it really depends on strategy of the upgrade. small cluster would imply just few hosts in each, so you anyway need to upgrade carefully one by one with respect to the load.

Comment 20 Roman Mohr 2015-12-18 10:28:36 UTC
State of development can be followed on the feature page:

http://www.ovirt.org/Features/InClusterUpgrade#InClusterUpgrade

Comment 21 Roman Mohr 2016-02-23 10:27:35 UTC
Wiki page is now at www.ovirt.org/feature/inclusterupgrade

Comment 22 Roy Golan 2016-03-20 08:40:43 UTC
Hi Jullie,

This important process should go into the user-guide I believe. We have this wiki from comment 21 to start from. Let me know of any think you need.

Thanks

Comment 23 Julie 2016-03-20 23:12:30 UTC
Hi Roy,
 We have a docs bug to track this change (BZ#1301447). It should affect the standard upgrade procedure in the Upgrade Guide[1] and the self-hosted engine upgrade procedure in the SHE Guide[2].

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Upgrade_Guide/Upgrading_a_Red_Hat_Enterprise_Linux_6_Cluster_to_Red_Hat_Enterprise_Linux_7.html
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Self-Hosted_Engine_Guide/Upgrading_the_Self-Hosted_Engine_from_6_to_7.html

Kind regards,
Julie

Comment 24 Mike McCune 2016-03-28 23:29:58 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions

Comment 25 Artyom 2016-05-01 08:08:08 UTC
Verified on rhevm-3.6.6-0.1.el6.noarch
See polarion run: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=3%5F6%5FSLA%5FIn%5FCluster%5FUpgrade%5Frun%5F1

Comment 31 Eyal Edri 2016-06-19 12:57:28 UTC
Please clone bug or fix flags.


Note You need to log in before you can comment on or make changes to this bug.