[ovirt-users] Understanding Cluster / Datacenter upgrades

[Itamar Heim]

On 10/29/2014 01:00 PM, Daniel Helgenberger wrote:
> Hello,
>
> I seem to have some issues understating what and when something happens
> if I change a cluster or datacenter to a higher version after upgrading
> engine.
> Maybe somebody could help me understand how this works in general and
> when features will get enabled? If possible, pinpoint it to concrete
> features added in 3.5.
>
> My assumptions learned form experience so far, upgrading oVirt 3.4 to
> 3.5; please correct if wrong:
> - New features are enabled if I set the cluster compat version to a
> newer version after upgrade

unless the features don't need a host change, so engine may just support 
them on your previous cluster level as well.
(or some even at host level upgrade)

> - Prior to upgrading a datacenter all cluster need to run the higher
> version (seems logical).

yes.

> - This involves Engine database updates (?) and, more crucial, it will
> change settings and data on the storage domains.

storage domains are only changed on DC upgrade, not cluster upgrade.

> - Because of that, downgrade is not possible any more
> - Also, its usually safer to keep the old cluster version while using a
> newer engine version; because it is more likely to run into regressions
> with an upgraded datacenter (see regression blockers for oVirt 3.5.1).
>
> My questions so far:
> - What happens if I only upgrade the cluster and *not* yet the datacenter?

you can use new features at host/cluster level (if any), but not DC 
level (storage usually, sometimes network) yet.

> - In case of 3.5; exactly when could I have used the new NUMA
> management? I assume after upgrading the cluster?

because its unrelated to storage, so its host or cluster level.

> - In case of 3.5; exactly when could I have used the new QoS settings
> (like disk profiles) - here I assume after upgrading the datacenter?

I think while these are "storage", they only relate to VM behavior, not 
to storage domains, so cluster level sounds like the right level.
doron/allon?

>
> If the the case of NUMA policy is not true but happens only after
> upgrading the datacenter, what is the purpose of the cluster compat
> version setting? I can think of making sure a certain minimum VDSM
> version is running?

simply put:
host level (automatic) - engine may base some features on making sure
host has the right version

cluster level - features which require all hosts to have the new version 
to simplify things (we don't want to not be able to schedule a VM using 
a new feature only on some hosts, so we only allow them after cluster 
level upgrade.

dc level - since storage domains (mostly), and some network definitions, 
span multiple clusters, and for storage, all hosts in the DC may be 
asked to perform the new storage operations, hence DC level makes sure 
all hosts at DC level can do these actions.

and no, I don't have a mapping of which features require which...