Bug 1364266 - [Docs] Upgrading el6 to el7 hosts cluster should explain VMs migration
Summary: [Docs] Upgrading el6 to el7 hosts cluster should explain VMs migration
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation   
(Show other bugs)
Version: 3.6.7
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-3.6.10
: ---
Assignee: Byron Gravenorst
QA Contact: Megan Lewis
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-04 21:47 UTC by Marina Kalinin
Modified: 2016-12-07 22:47 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-07 22:47:18 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1487183 None None None 2016-08-04 22:37 UTC

Description Marina Kalinin 2016-08-04 21:47:48 UTC
The official documentation on upgrading el6 to el7 hosts cluster[1] doesn't make sense in my eyes. It talks about cluster and hosts upgrade, but does not mention/explain, what is happening with VMs at all.
Also, it is not clear what compat mode cluster should be when we are performing this operation and it is confusing when we suggest modifying engine-config value for 3.5 version.

I believe, it was created based on ovirt wiki page [2]. And that makes things more clear.

Suggestions to update the documentation, based on the wiki page:
1. 
Add step 4 from wiki to the docs as step 4 before current step4:
- Move a host X to maintenance (If this is the 2nd+ host some VMs will move to el7 machines) 
  -- If needed, pre-migrate VMs manually as a precaution

2. 
I see there is a statement, that VMs would migrate to hosts with an equal, or greater operating system version. But it is not really obvious. Since this is a new feature I'd put in some frame/note, to raise awareness.

3. As for compat mode and CheckMixedRhelVersions value for 3.5, I am not sure myself. If we are setting this value for 3.5, does it imply that the cluster level should be 3.5 as well? Or it can be 3.4, for example? (also, why is it 3.5 and not 3.6 for the config value?)


[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] http://www.ovirt.org/feature/inclusterupgrade/

Comment 1 Marina Kalinin 2016-08-04 21:48:57 UTC
Roman, can you please clarify #3?

Comment 2 Michal Skrivanek 2016-08-05 12:41:13 UTC
the current state of document would benefit from some more clarification
- title and first sentence might be confusing. There are clusters, there is a "cluster level compatibility", and there are clusters with RHEL6 or RHEL7 hosts. These terms are not interchangeable and they mean different things

- need to make clear that the whole procedure is required only for clusters where they can't shut down VMs during the upgrade. Every single VM which can be shut down can trivially be moved to a different RHEL7-only cluster, or even directly into a cluster at 3.6 cluster level (hence getting all the new functionality)

- the prerequisite of "No virtual machines with the migration option Do not allow migration or Allow manual migration only selected." - IIUC there was a bug which didn't allow you to do that while VM is running, worth mentioning. Also, supposing that CPU pinning can be changed in UI while VM is running, it doesn't actually take any effect so the VM is mistakenly considered unpinned. Please doublecheck it doesn't fail on migration (it should when ranges differ)

- "No PCI passthrough on any virtual machine in the cluster." - this is a 3.6 feature so it can't be present in RHEL 6 based 3.5 cluster

- step to enable the policy assumes your cluster level is 3.5 ("engine-config -s CheckMixedRhelVersions=false --cver=3.5"), please clarify if it is supported or not (I don't really see a reason why not)

- between the step 1 and 3 the mixed RHEL scenario is allowed but the policy is not set yet. Even though we assume that time window is small and "nothing happens at that time", we should make it clear so no one leaves it in this state where migrations are not restricted correctly. This would happen if someone starts the procedure by upgrading one host to RHEL 7 and only then realizing that there is this special procedure. 

- unrelated to this procedure, but since the chapter is talking about upgrading while running VMs, the next chapter[1] needs a clear warning about upgrading a cluster level with running/suspended/paused VMs.

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Upgrade_Guide/chap-Post-Upgrade_Tasks.html

Comment 3 Roman Mohr 2016-08-08 09:53:59 UTC
(In reply to Marina from comment #0)
> The official documentation on upgrading el6 to el7 hosts cluster[1] doesn't
> make sense in my eyes. It talks about cluster and hosts upgrade, but does
> not mention/explain, what is happening with VMs at all.
> Also, it is not clear what compat mode cluster should be when we are
> performing this operation and it is confusing when we suggest modifying
> engine-config value for 3.5 version.
> 
> I believe, it was created based on ovirt wiki page [2]. And that makes
> things more clear.
> 
> Suggestions to update the documentation, based on the wiki page:
> 1. 
> Add step 4 from wiki to the docs as step 4 before current step4:
> - Move a host X to maintenance (If this is the 2nd+ host some VMs will move
> to el7 machines) 

Just to clarify this a sentenc a little bit more: Since one host is then already on el7, this host will be prefered when the VMs are migrated. If not all VMs running on the second hosts fit on the el7 host, some of them might still go to el6 since they are coming from an el6 host. So 

1) el6 -> el7 and el7 -> el7 are preferred
2) el6 -> el6 is possible when necessary
3) el7 -> el6 migrations are not possible

>   -- If needed, pre-migrate VMs manually as a precaution
> 
>
> 2. 
> I see there is a statement, that VMs would migrate to hosts with an equal,
> or greater operating system version. But it is not really obvious. Since
> this is a new feature I'd put in some frame/note, to raise awareness.
> 

That is correct they will only migrate to newer or equal OS versions. The "Upgrade Policy" section on the wiki page describes the exact migration rules very detailed too.

> 3. As for compat mode and CheckMixedRhelVersions value for 3.5, I am not
> sure myself. If we are setting this value for 3.5, does it imply that the
> cluster level should be 3.5 as well? Or it can be 3.4, for example? (also,
> why is it 3.5 and not 3.6 for the config value?)

The wiki page describes an upgrade from 3.5 cluster level to 3.6 cluster level.
This is the last step before you can move on to 4.0. But you can also run

"engine-config -s CheckMixedRhelVersions=false --cver=3.4" or
"engine-config -s CheckMixedRhelVersions=false --cver=3.6"

depending on your cluster level. Then you can start upgrading the hosts from el6 to el7.

> 
> 
> [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] http://www.ovirt.org/feature/inclusterupgrade/

Comment 4 Roman Mohr 2016-08-08 10:03:39 UTC
(In reply to Michal Skrivanek from comment #2)
> the current state of document would benefit from some more clarification
> - title and first sentence might be confusing. There are clusters, there is
> a "cluster level compatibility", and there are clusters with RHEL6 or RHEL7
> hosts. These terms are not interchangeable and they mean different things
> 
> - need to make clear that the whole procedure is required only for clusters
> where they can't shut down VMs during the upgrade. Every single VM which can
> be shut down can trivially be moved to a different RHEL7-only cluster, or
> even directly into a cluster at 3.6 cluster level (hence getting all the new
> functionality)
>
> 
> - the prerequisite of "No virtual machines with the migration option Do not
> allow migration or Allow manual migration only selected." - IIUC there was a
> bug which didn't allow you to do that while VM is running, worth mentioning.
> Also, supposing that CPU pinning can be changed in UI while VM is running,
> it doesn't actually take any effect so the VM is mistakenly considered
> unpinned. Please doublecheck it doesn't fail on migration (it should when
> ranges differ)
> 
> - "No PCI passthrough on any virtual machine in the cluster." - this is a
> 3.6 feature so it can't be present in RHEL 6 based 3.5 cluster
> 

I tested 3.6 too when developing the feature, it worked for me too and there I needed the check.

> - step to enable the policy assumes your cluster level is 3.5
> ("engine-config -s CheckMixedRhelVersions=false --cver=3.5"), please clarify
> if it is supported or not (I don't really see a reason why not)
> 

3.5 to 3.6 cluster level upgrade was the main focus on the feature and also what QE tested. I don't think anyone ever tested 3.4 as start level.

> - between the step 1 and 3 the mixed RHEL scenario is allowed but the policy
> is not set yet. Even though we assume that time window is small and "nothing
> happens at that time", we should make it clear so no one leaves it in this
> state where migrations are not restricted correctly. This would happen if
> someone starts the procedure by upgrading one host to RHEL 7 and only then
> realizing that there is this special procedure. 

Agreed.

> 
> - unrelated to this procedure, but since the chapter is talking about
> upgrading while running VMs, the next chapter[1] needs a clear warning about
> upgrading a cluster level with running/suspended/paused VMs.
> 
> [1]
> https://access.redhat.com/documentation/en-US/
> Red_Hat_Enterprise_Virtualization/3.6/html/Upgrade_Guide/chap-Post-
> Upgrade_Tasks.html


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