Description of problem: Two clusters, different hardware, one of them with 6.6 hosts, the other uses 7.1. Attempt to change cluster of a VM results with the following error window: ┌---------------------------------------------┐ |X Operation cancelled | | | |Error while executing action: | | | |$(vm_name): | | • ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER | └---------------------------------------------┘ Which is sort of weird, as the cluster gets successfully changed anyway. Version-Release number of selected component (if applicable): vt4 (3.5.0-0.13.beta) How reproducible: 100% Steps to Reproduce: 1. Change VM's cluster, to one with with different specs. Actual results: The message and changed cluster Expected results: No message, changed cluster, or, technically wrong -- but still better, message but same cluster.
I assume the VM has a cpu profile attached which doesn't exist under the target cluster. Scott what do we want to happen, succesful change of Vm cluster with some unknown profile or fail the change as the current Vm properties couldn't be fulfilled? I'm not sure how consistent we are with other VM properties that are missing when switching clusters. like network for example.
(In reply to Roy Golan from comment #1) > I assume the VM has a cpu profile attached which doesn't exist under the > target cluster. > > Scott what do we want to happen, succesful change of Vm cluster with some > unknown profile or fail the change as the current Vm properties couldn't be > fulfilled? > > I'm not sure how consistent we are with other VM properties that are missing > when switching clusters. like network for example. Is it possible to do the successful change of the cluster for the VM, with the following logic? * If the cpu profile exists in the target cluster, move successful, no notification * If the cpu profile does not exist in target cluster, move successful, but message to user that CPU no longer has profile associated since it is missing from the target cluster
(In reply to Scott Herold from comment #2) > (In reply to Roy Golan from comment #1) > > I assume the VM has a cpu profile attached which doesn't exist under the > > target cluster. > > > > Scott what do we want to happen, succesful change of Vm cluster with some > > unknown profile or fail the change as the current Vm properties couldn't be > > fulfilled? > > > > I'm not sure how consistent we are with other VM properties that are missing > > when switching clusters. like network for example. > > Is it possible to do the successful change of the cluster for the VM, with > the following logic? > > * If the cpu profile exists in the target cluster, move successful, no > notification > > * If the cpu profile does not exist in target cluster, move successful, > but message to user that CPU no longer has profile associated since it is > missing from the target cluster we're almost there. the cluster is changed, the rest of the vm update fails. so now, what profile should we choose? we see that in lots of other scenraio with profiles - disk move to another domain, vnics on another cluster as well. we have 2 options I think - 1. to have a "default" attribute on a profile so we can choose it automatically and assign it in case was not specify. 2. to treat null as profile - conceptually its a default profile but unmanageble I prefer option 1
(In reply to Roy Golan from comment #3) > (In reply to Scott Herold from comment #2) > > (In reply to Roy Golan from comment #1) > > > I assume the VM has a cpu profile attached which doesn't exist under the > > > target cluster. > > > > > > Scott what do we want to happen, succesful change of Vm cluster with some > > > unknown profile or fail the change as the current Vm properties couldn't be > > > fulfilled? > > > > > > I'm not sure how consistent we are with other VM properties that are missing > > > when switching clusters. like network for example. > > > > Is it possible to do the successful change of the cluster for the VM, with > > the following logic? > > > > * If the cpu profile exists in the target cluster, move successful, no > > notification > > > > * If the cpu profile does not exist in target cluster, move successful, > > but message to user that CPU no longer has profile associated since it is > > missing from the target cluster > > we're almost there. the cluster is changed, the rest of the vm update fails. > so now, what profile should we choose? we see that in lots of other scenraio > with profiles - disk move to another domain, vnics on another cluster as > well. > > we have 2 options I think - > 1. to have a "default" attribute on a profile so we can choose it > automatically and assign it in case was not specify. Would this also require that whatever we dictate as default also be located across every cluster, which we may not be able to guarantee? > > 2. to treat null as profile - conceptually its a default profile but > unmanageble This seems like it would be the item that would guarantee the VM would properly start. > > > I prefer option 1
> > we have 2 options I think - > > 1. to have a "default" attribute on a profile so we can choose it > > automatically and assign it in case was not specify. > > Would this also require that whatever we dictate as default also be located > across every cluster, which we may not be able to guarantee? I say that we'll give the Admin the option to set a profile as default. instead of managing it has some complexity I guess - a default profile must be publically visible i.e permission of everyone on it. so when deleting it we need to make sure we have an alternative. and make sure when someone configures a profile as default, we grant everyone permission on it.
3.5.1 is already full with bugs (over 80), and since none of these bugs were added as urgent for 3.5.1 release in the tracker bug, moving to 3.5.2
moving to 3.5.4 due to capacity planning for 3.5.3. if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly.
Following Bug 1262293 in 3.6 we always pick the 1st profile in the list. This should have the same behaviour currently. downport the patch to 3.5.6
on QA due to fix from Bug 1262293.
Verified on rhevm-3.6.0.2-0.1.el6.noarch Change cluster also change cpu_profile of vm to one from cluster.