Understanding Cluster / Datacenter upgrades
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 - Prior to upgrading a datacenter all cluster need to run the higher version (seems logical). - This involves Engine database updates (?) and, more crucial, it will change settings and data on the storage domains. - 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? - In case of 3.5; exactly when could I have used the new NUMA management? I assume after upgrading the cluster? - 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? 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? Thanks a million, -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767
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...
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Daniel Helgenberger" <daniel.helgenberger@m-box.de>, users@ovirt.org, devel@ovirt.org, "Allon Mureinik" <amureini@redhat.com>, "Doron Fediuck" <dfediuck@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...
participants (3)
-
Daniel Helgenberger -
Doron Fediuck -
Itamar Heim