Bug 1006209

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?

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

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

+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?

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)

(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?

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

Posted the patch that removes the validation (see attachment).

(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?

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

Verified on is22
I can change cluster level and also receive warning messages

Closing - RHEV 3.3 Released

Closing - RHEV 3.3 Released