Bug 1006209 - Support lowering cluster CPU level.
Support lowering cluster CPU level.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.3.0
Unspecified Unspecified
high Severity high
: ---
: 3.3.0
Assigned To: Oved Ourfali
Artyom
sla
: Triaged
Depends On:
Blocks: 3.3snap2
  Show dependency treegraph
 
Reported: 2013-09-10 04:48 EDT by Leonid Natapov
Modified: 2016-02-10 15:16 EST (History)
9 users (show)

See Also:
Fixed In Version: is22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-21 17:12:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 19442 None None None Never
oVirt gerrit 20231 None None None Never
oVirt gerrit 20232 None None None Never
oVirt gerrit 20233 None None None Never

  None (edit)
Description Leonid Natapov 2013-09-10 04:48:39 EDT
Description of problem:

This requirement was raised while testing hosted engine feature.
If we have two hosts with different CPU level user must be able to lower Cluster CPU level without stooping running virtual machine. We must provide an appropriate message that warns the user about consequences of lowering cluster's CPU level such as  VMs that were started on host with higher CPU level won't be able to live migrate to host with lower CPU level.
Comment 1 Oved Ourfali 2013-09-10 09:25:43 EDT
We can do the following in order to fix that:
1. Warn the user when he tries to lower the cluster CPU level, that for running VMs migration might not be possible to all the hosts in the cluster.
2. Add a filter to the scheduling that will filter out hosts that have a CPU level which is lower than the one of the VM we wish to migrate.

Doron and Michal - thoughts about that?
Comment 2 Michal Skrivanek 2013-09-13 05:19:04 EDT
(In reply to Leonid Natapov from comment #0)
> Description of problem:
> 
> This requirement was raised while testing hosted engine feature.
> If we have two hosts with different CPU level user must be able to lower
> Cluster CPU level without stooping running virtual machine. 

why?
I'd prefer to require to stop them.
Comment 3 Oved Ourfali 2013-09-15 01:03:21 EDT
(In reply to Michal Skrivanek from comment #2)
> (In reply to Leonid Natapov from comment #0)
> > Description of problem:
> > 
> > This requirement was raised while testing hosted engine feature.
> > If we have two hosts with different CPU level user must be able to lower
> > Cluster CPU level without stooping running virtual machine. 
> 
> why?
> I'd prefer to require to stop them.

We suggest a proper warning here, and in addition prevent trying to run a VM that was run with a higher CPU level on lower level hosts. From my point of view it adds flexibility, but without encouraging you to do so unless you know what you're doing. Why would we want to block that? 

That is useful even regardless of the hosted engine feature, but specifically for the hosted engine feature it allows you to change it without stopping the hosted engine VM.

Another alternative is to give a special treatment here to this VM. It will even be easier... but seems like a more general solution should be applied here.
Comment 4 Itamar Heim 2013-09-15 15:15:10 EDT
+1 to allow being more dynamic here on changing cpu level.
now that the scheduler is more methodological and transparent, we should start lifting the legacy arbitrary scheduling limitations we have (with proper warning and handling of course).

michal - btw, how do you deal with preview of a snapshot with ram in this case?
Comment 5 Michal Skrivanek 2013-09-19 09:42:43 EDT
you mean in case you try to resume on lower CPU level?
It's the same flow as run VM, so if there is nothing compatible you won't be able to resume

though I can agree with comment #4, I'm still missing why do we need that for hosted engine (i.e. urgency to have this in 3.3)
Comment 6 Oved Ourfali 2013-09-22 03:37:31 EDT
(In reply to Michal Skrivanek from comment #5)
> you mean in case you try to resume on lower CPU level?
> It's the same flow as run VM, so if there is nothing compatible you won't be
> able to resume
> 
> though I can agree with comment #4, I'm still missing why do we need that
> for hosted engine (i.e. urgency to have this in 3.3)

When installing the hosted engine on some host, it sets the cluster to have the CPU level reported by this host.
Now, imagine you want to add other hosts to this cluster, but other hosts are of lower CPU level. In a normal use-case you would juts stop running VMs (if any), change it, and re-run the VMs. However, in the hosted-engine case you can't really stop the hosted engine VM, so you can't really change the CPU level.

So either we give the limitation that you can only add hosts with the same CPU level as the first one, or we fix this.

Regardless of that, I did some further tests, and I saw that we also don't allow setting the CPU level to a higher level when there are running VMs. Can we eliminate this validation as well? Just warn the user that by changing the CPU level some VMs might not be able to migrate properly?

Thoughts about that?
Comment 7 Oved Ourfali 2013-09-22 09:23:45 EDT
> Regardless of that, I did some further tests, and I saw that we also don't
> allow setting the CPU level to a higher level when there are running VMs.
> Can we eliminate this validation as well? Just warn the user that by
> changing the CPU level some VMs might not be able to migrate properly?
> 
> Thoughts about that?

My mistake here.
It is blocking setting the CPU level to a higher level, when there are active *hosts* that doesn't support that... which makes sense.
Comment 8 Oved Ourfali 2013-09-22 10:28:48 EDT
Posted the patch that removes the validation (see attachment).
Comment 9 Oved Ourfali 2013-09-23 08:59:40 EDT
(In reply to Oved Ourfali from comment #1)
> We can do the following in order to fix that:
> 1. Warn the user when he tries to lower the cluster CPU level, that for
> running VMs migration might not be possible to all the hosts in the cluster.
> 2. Add a filter to the scheduling that will filter out hosts that have a CPU
> level which is lower than the one of the VM we wish to migrate.

Seems like in order to do that we need to keep the CPU level the VM was run with in some table, probably vm_dynamic. I discussed it with Omer and it made sense to him.

Michal - Any objections?
Comment 10 Michal Skrivanek 2013-09-23 10:33:07 EDT
yeah, for troubleshooting this would be sufficient. Preferably show that in VM subtab
And I suppose Doron to follow up with SLA policy to migrate only to compatible hosts based on this new field
Comment 11 Artyom 2013-11-08 00:36:05 EST
Verified on is22
I can change cluster level and also receive warning messages
Comment 12 Itamar Heim 2014-01-21 17:12:47 EST
Closing - RHEV 3.3 Released
Comment 13 Itamar Heim 2014-01-21 17:20:53 EST
Closing - RHEV 3.3 Released

Note You need to log in before you can comment on or make changes to this bug.