RegisterVM_Task doesn't work properly without the "pool" param

[strongliang]

from the vSphere API doc, only path and asTemplate are required, and vCLI vmware-cmd works properly without specifying resource pool. However, in here, without the pool argument, this is what I get.

(vim.TaskInfo) {
   dynamicType = <unset>,
   dynamicProperty = (vmodl.DynamicProperty) [],
   key = 'haTask-ha-folder-vm-vim.Folder.registerVm-307940434',
   task = 'vim.Task:haTask-ha-folder-vm-vim.Folder.registerVm-307940434',
   description = <unset>,
   name = vim.Folder.RegisterVm,
   descriptionId = 'Folder.registerVm',
   entity = 'vim.Folder:ha-folder-vm',
   entityName = 'vm',
   locked = (vim.ManagedEntity) [],
   state = 'error',
   cancelled = false,
   cancelable = false,
   error = (vmodl.fault.InvalidArgument) {
      dynamicType = <unset>,
      dynamicProperty = (vmodl.DynamicProperty) [],
      msg = 'A specified parameter was not correct. \npool',
      faultCause = <unset>,
      faultMessage = (vmodl.LocalizableMessage) [],
      invalidProperty = u'pool'
   },
   result = <unset>,
   progress = <unset>,
   reason = (vim.TaskReasonUser) {
      dynamicType = <unset>,
      dynamicProperty = (vmodl.DynamicProperty) [],
      userName = 'root'
   },
   queueTime = 2015-02-04T12:40:42.342862Z,
   startTime = 2015-02-04T12:40:42.343253Z,
   completeTime = 2015-02-04T12:40:42.343679Z,
   eventChainId = 307940434,
   changeTag = <unset>,
   parentTaskKey = <unset>,
   rootTaskKey = <unset>
}

[hartsock]

I've seen this before... most notably back when I was working on the OpenStack Nova driver for vSphere. The problem is ambiguity ... the placement task doesn't know where to place the VM. In many situations there's only one obvious location to drop in the new VM and vCenter will just fill in the blank for you. The interesting thing is that even though the API specifies Folder ... I think the concept of resource pool is actually more fundamental and that's because a folder, host, or other containing structure may hold multiple resource pools.

By default, there's a hidden implicit resource pool inside each container-like thing. A host is a resource pool, a folder is sort of a resource pool. Leave out the resource pool and specify a folder/host and as long as there's no ambiguity the vCenter Server will figure out what you mean and place the VM in the implicit resource pool representing the entire Folder or Host (at least that's the behavior we saw).

However, if you have a multi-host or multi resource pool environment underneath the location you specified things can be ambiguous. Which pool did you mean? vCenter can't read your mind so it fails. You didn't post details about your resource pool configuration but I'm guessing you have multiple resource pools and multiple hosts ... and possibly multiple datacenters. This is the situation in which vCenter can't decide for you and at the API level it probably shouldn't.

Now, I've not looked inside vCLI but my guess is that it probably makes the same API call made here but instead of leaving the pool blank, the vCLI probably quietly looks up the best fit resource pool for you so you don't have to figure it out. That's a good end-user tool behavior. It's a behavior pyVmomi just doesn't have.

The pyVmomi library isn't an end-user tool. This is an integration library, API language binding, or client library as you may alternatively call it. As such, (in my opinion), it's not our place to silently do things that may or may not solve problems. In this case the API is functioning as designed. It would make sense to enhance these behaviors in pyvmomi-tools (which is still unreleased... but we have grand plans... grand plans...) or demonstrate an enhancement in pyvmomi community samples.

Given enough prodding I might change my position on this, but this isn't a bug, it's a description of a missing feature. If you want to have ... what should we call it ... implicit resource pool lookup ... then feel free to request it as a feature. It's just not a bug. The pyVmomi library is faithfully rendering the API under it (even if we don't like the behavior).

I hope that helps. And, for the record, I wouldn't mind helping the community roll out a pyCLI or something built on top of pyVmomi that had many of the same behaviors people expect from a CLI tool as long as there was enough support for the project in terms of volunteer developers.

[strongliang]

I just tested this on a single host directly (no vCenter), and there is no explicit resource pool, still the API complains about the same thing. I don't think it's a big deal, though, since I can always assign it to the default "Resources" pool.

if you're looking for people to contribute to a pyCLI kind of project, count me in.

[hartsock]

Hrm... okay so I'm reopening it as a bug just to make me look at it again later.

Things I would like:

• a recording of your HTTP transaction
• version numbers for everything ... Python, vCenter, pyVmomi (to be paranoid)

I'll place this on the back log.

[LoveIsGrief]

Using https://github.com/vmware/pyvmomi-community-samples/blob/f83b993a9ba0fbbc6e4091bef3cbb8524cd82c8d/samples/clone_vm.py one can use

def get_obj(content, vimtype, name):
    """
    Return an object by name, if name is None the
    first found object is returned
    """
    obj = None
    container = content.viewManager.CreateContainerView(
        content.rootFolder, vimtype, True)
    for c in container.view:
        if name:
            if c.name == name:
                obj = c
                break
        else:
            obj = c
            break

    return obj

resource_pool = get_obj(content, [vim.ResourcePool], None)

to get the default resource_pool

[brook330]

esxhost=self._get_obj([vim.HostSystem],hostname)
pool=esxhost.parent.resourcePool