Correctly find the resource pool even if it is a cluster.

[rylarson]

This is a more robust way to search for the resource pool. We interrogate the type and search a little but differently depending on what type of resource we are.

This is very similar to how knife-vsphere searches for resource pools. This was tested on a vmware infrastructure deployment using vCenter/vSphere 4.1

[mathieulegrand]

Thanks. Your patch worked for me on vCenter/vSphere 5.5. It would be great if this could be merged into the official plugin.

[flamingbear]

This doesn't work under our original conditions. (Merged, or unmerged)

Here's the not-particularly-useful error output.

savoie@savoie-laptop ~/projects/brightness-temperature-vm (master *=)$ vagrant --verbose up --provision --provider vsphere development
vagrant --verbose up --provision --provider vsphere development
Bringing machine 'development' up with 'vsphere' provider...
No error message
/Users/savoie/.vagrant.d/gems/gems/vagrant-vsphere-0.7.2/lib/vSphere/action/clone.rb:41:in `rescue in call'
/Users/savoie/.vagrant.d/gems/gems/vagrant-vsphere-0.7.2/lib/vSphere/action/clone.rb:27:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builder.rb:116:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `block in run'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/util/busy.rb:19:in `busy'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `run'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/call.rb:51:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Users/savoie/.vagrant.d/gems/gems/vagrant-vsphere-0.7.2/lib/vSphere/action/connect_vsphere.rb:16:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/warden.rb:34:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/builder.rb:116:in `call'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `block in run'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/util/busy.rb:19:in `busy'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/action/runner.rb:69:in `run'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/machine.rb:157:in `action'
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.2/lib/vagrant/batch_action.rb:72:in `block (2 levels) in run'
No error message

Any more information I can provide?

Matt

[flamingbear]

There's a branch of my merge if you wanted to look at it.
https://github.com/nsidc/vagrant-vsphere/tree/rlarson-add-cluster-support

[rylarson]

Interesting. Are you saying that you get the same error before and after my patch?

[rylarson]

Also,

It seems like your error is occurring in connect_vsphere. It is possible that it is just failing to connect. There is something wrong with the error messaging because it seems like we always just get "No error message"

Can you verify with a super simple Vagrantfile that you can at least connect to your vsphere endpoint?

[flamingbear]

Ryan,

I was saying I only get the error after your patch. I have no problems connecting with the previous software/gem.

Matt

[flamingbear]

Can you see if the latest version fixes your problems?

[GregDomjan]

Would something similar to this also be required for get_datastore working with a cluster and resolving DRS?

[rylarson]

Hey, sorry I dropped off the map on this one. I got pulled in to some other stuff. We have upgraded to vSphere 5.5, I will test the latest version against our environment and let you know.

[rylarson]

Sorry it took so long, I had no time to check this out. The latest version using the root resource pool works great and I don't have a problem hitting our vSphere 5.5 deployment and spinning up VM's.

[flamingbear]

Nice, thanks.

On Fri, Sep 12, 2014 at 1:18 PM, rylarson notifications@github.com wrote:

Closed #45 #45.

—
Reply to this email directly or view it on GitHub
#45 (comment).

[GregDomjan]

I was sad to see this work discarded, as unfortunately the root resource pool doesn't work in configurations where a named resource pool must be selected.

Folder.find fails when getting a named item that matches a ClusterComputeResource.

Backtrace:
        C:/HashiCorp/Vagrant/embedded/lib/ruby/gems/2.0.0/gems/rbvmomi-1.6.0/lib/rbvmomi/connection.rb:61:in `parse_resp
onse'
        C:/HashiCorp/Vagrant/embedded/lib/ruby/gems/2.0.0/gems/rbvmomi-1.6.0/lib/rbvmomi/connection.rb:90:in `call'
        C:/HashiCorp/Vagrant/embedded/lib/ruby/gems/2.0.0/gems/rbvmomi-1.6.0/lib/rbvmomi/basic_types.rb:203:in `_call'
        C:/HashiCorp/Vagrant/embedded/lib/ruby/gems/2.0.0/gems/rbvmomi-1.6.0/lib/rbvmomi/basic_types.rb:74:in `block (2
levels) in init'
        C:/HashiCorp/Vagrant/embedded/lib/ruby/gems/2.0.0/gems/rbvmomi-1.6.0/lib/rbvmomi/vim/Folder.rb:7:in `find'
...
ERROR warden: Error occurred: NoPermission: Permission to perform this operation was denied.

The workaround identified here is to navigate the folders and look for the ClusterComputeResource using childEntity.find.

I guess I'll raise a pull request when I get it working.