- Original Message -
From: Itamar Heim ih...@redhat.com
To: Daniel Helgenberger daniel.helgenber...@m-box.de, users@ovirt.org,
de...@ovirt.org, Allon Mureinik
amure...@redhat.com, Doron Fediuck dfedi...@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...
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
