i was suprised by this error. Have anyone seen this as well ? I was doing some affinity rules for cluster. In the beggining when there were no vmgroups,hostgroups,no vm to host rules, this command was running just fine, no errors were generated. After vm-vm antiaffinity rules, i made some vm groups, host groups, and created AA rules for this cluster as well via api. Everything worked well, no errors during creation. But after some days, i wanted to add 1 more rule vm-vm AA. And i received this error , any idea why would this come up ? This error shows up, but the rule is created anyways.
Thanks,
Greg
btw.
Why would he want to cast "VMware.Vim.ClusterVmHostRuleInfo" ?
"A ClusterVmHostRuleInfo object identifies virtual machines and host groups that determine virtual machine placement. The virtual machines and hosts referenced by a VM-Host rule must be in the same cluster."
But this is a VM-VM antiaffinity rule, not a vm-host rule. I still have no clue why the error pops out but i used onyx to see if i will have the same issue when doing this with api:
$spec = New-Object VMware.Vim.ClusterConfigSpecEx
$spec.rulesSpec = New-Object VMware.Vim.ClusterRuleSpec[] (2)
$spec.rulesSpec[0] = New-Object VMware.Vim.ClusterRuleSpec
$spec.rulesSpec[0].operation = "add"
$spec.rulesSpec[0].info = New-Object VMware.Vim.ClusterAffinityRuleSpec
$spec.rulesSpec[0].info.enabled = $true
$spec.rulesSpec[0].info.name = "AA-vm1-vm2"
$spec.rulesSpec[0].info.userCreated = $true
$spec.rulesSpec[0].info.vm = New-Object VMware.Vim.ManagedObjectReference[] (2)
$spec.rulesSpec[0].info.vm[0] = New-Object VMware.Vim.ManagedObjectReference
$spec.rulesSpec[0].info.vm[0].type = "VirtualMachine"
$spec.rulesSpec[0].info.vm[0].value = "vm-xxxxxxx"
$spec.rulesSpec[0].info.vm[1] = New-Object VMware.Vim.ManagedObjectReference
$spec.rulesSpec[0].info.vm[1].type = "VirtualMachine"
$spec.rulesSpec[0].info.vm[1].value = "vm-yyyyyyy"
$_this = Get-View -Id 'ClusterComputeResource-domain-c345645464'
$_this.ReconfigureComputeResource_Task($spec, $true)
This is working without any errors
Hi Greg,
Thanks for reporting this issue. I can also confirm that it's a bug that is caused by vm-to-host rules. We've already fixed it for the next release.
Regards,
Yasen
Are you using the latest PowerCLI version ?
Seems to work perfectly in PowerCLI 5.0.1
Or you could be experiencing the problem I reported in Import and export DRS rules
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hey LucD,
yeah, confirming my version : powercli5.0.1
I know WHEN this error will pop out. I would think that this should be reported as a bug. You can reproduce this situation in following, i did it just few seconds ago to confirm this behaviour:
1) New HA/DRS cluster XYZ
2) create vms : vm1,vm2
3) create a drs rule : VM - VM anti affinity
New-DrsRule -Cluster XYZ -Name AA-vm1-vm2 -KeepTogether:$false -VM vm1,vm2
this will result :
Name Enabled KeepTogether VMIDs
---- ------- ------------ -----
AA-vm1-vm2 True False {VirtualMachine-vm-697, VirtualMachine-vm-...
So it's fine, no errors.
4) Create a hostgroup with some esx
5) Create a vmgroup with vm1 or vm2
---- at this time the new-drsrule cmdlet will still be running fine, without errors
6) create a new rule : vm-to-host affinity rule for vmgroup to hostgroup
--- starting from point 6, new-drsrule will generate this error, but the rule will be created anyway, you will see it via: get-drsrule, or via vc , its there.
New-DrsRule -Cluster xyz -Name AA-vm1-vm2 -KeepTogether:$false -VM vm1,vm2
will generate error that i have mentioned in my first post
7) you can double check this just delete the rule "vm-to-host" that we created in step 6 and notice that the new-drsrule is no longer generating this error
Greg
so is this a bug or what ? 😕
That looks indeed like a bug.
The handling of anti-affinity rules could use some improvement (see also my link above).
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Hi Greg,
Thanks for reporting this issue. I can also confirm that it's a bug that is caused by vm-to-host rules. We've already fixed it for the next release.
Regards,
Yasen
Hi Yasen,
thanks for letting us know !
Regards,
Greg