Bug 1364266

Roman, can you please clarify #3?

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

(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/

(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

This content has been published to:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Upgrade_Guide/Upgrading_Hosts_in_a_Red_Hat_Enterprise_Linux_6_Cluster_to_Red_Hat_Enterprise_Linux_7.html