Propogate Cluster Resource Pools to ESX servers?

[bennid]

Hello,

We recently clustered two of our ESX servers (one is running 4.1, the other 4.0).  We enabled DRS for them, so we can create resource pools and most everything is working fine from the VCenter interface.  However, we need to test our product accessing VCenter, as well as directly to our ESX.  Right now, our VCenter Cluster has 9-10 Resource pools in use, whereas the 4.1 esx, has only 4 showing.  When I try to create them either via the gui directly on the esx, or the cli, the vpxuser simply undoes anything I try (including moving vms into a resource pool that exist in that pool in vcenter!).  Is there a way to tell vcenter to propogate the pools down to the individual ESX's (this is semi-used for resource management, as well as grouping vms on the ESX), or at least be able to create pools / move vms directly on the ESX?

Thanks,

Ben

[beyondvm]

When ESX servers are in vCenter, and especially when they are clustered, you should not make any configuration changes directly on the host unless absolutely necessary.  If you do, it can cause ESX and VC to become out of sync and then things go down hill. vCenter is what is undoing any changes that you make, the VC copy of the configuration will always override what is on the host when it comes to things like this (vpxuser is the user that vCenter uses to interact with the host).

I would believe that VC only creates the resource pools on the host when they contain VMs because resource pools use up overhead on the host but I would have to verify this in my lab.

If you need to do testing directly connecting to the host, I would create an isolated host or a host that is outside of a cluster.

[piaroa]

I had a similar issue with a cluster where Resource Pools were not being created in some of our ESXi hosts.

In the end, and after opening an SR, we had to do services.sh restart to fix the issue.

[depping]

that is my understanding as well. i would also avoid direct access to esx and use the vCenter api only, from a security perspective definitely a better practice!

Duncan (VCDX)

Available now on Amazon: vSphere 4.1 HA and DRS technical deepdive

[bennid]

The issue we have is that we want to use the cluster for HA and the sake of our running vms.  But our product interacts with VCenter and the ESX alike, and we need to get coverage with both APIs.  It *would* be nice to have an esx dedicated only to direct connections, but we're a startup, and don't have the cash to have a dedicated esx just for the sake of testing with it.  I'll see if we have some downtime to test out the services.sh test.

[piaroa]

Services.sh restart will not cause virtual machine downtime. You'll see the host disconnected from vCenter when you do the restart, and it will come back online in 1-2 minutes.

Also, if your host has enough resources, you could virtualize a ESXi host to try out stuff without impacting your live environment.

[bennid]

Also -- I actually have "vms" in the resource pool in the cluster, and the child esx has those vms on it, but not in a resource pool (and I can't recreate them):

example:

   vCenter Cluster

      L Automation (ResourcePool)

         L Automation-1

         L Automation-2

             etc...

   ESX1 in vcenterCluster (No resource pools)

      L Automation-1

      L Automation-2

          etc...

[beyondvm]

That is odd, try the services.sh restart then, that would be my next step.  If you want to just test against the API, why not create a virtual ESX server (with no VMs on it obviously) to run scripts against.  Out of curiosity, what startup do you work for?

[bennid]

We actually do need "some" vms on the ESX, but they're mostly blank servers that we're just verifying we can access. 

I work for CloudSwitch.

[beyondvm]

Ah, if you dont care about performance you can put VMs on Virtual ESX servers, this is not supported of course but I have used it for testing scripts in a lab.  It requires a few tweaks but it works.  Did the services restart help?

[bennid]

I didn't try the services.sh script... figured having the ESX running in a VM would be the "cooler" option, and I can tweak it specifically to what automation / qa needs.