[ovirt-users] Understanding Cluster / Datacenter upgrades

[Doron Fediuck]

----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Daniel Helgenberger" <daniel.helgenberger at m-box.de>, users at ovirt.org, devel at ovirt.org, "Allon Mureinik"
> <amureini at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
> Sent: Thursday, October 30, 2014 8:00:52 PM
> Subject: Re: [ovirt-users] Understanding Cluster / Datacenter upgrades
> 
> 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?
> 

Well, QoS is per disk. And storage domain is where storage 'meets' the
VM for a specific disk. So from the VM point of view 3.5 cluster level
is required to support the various profiles functionalities.

> >
> > 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...
>