I think this is a bad idea to do for several reasons, but I do understand the needs for doing it. Other pyVmomi developers think having to expose the Managed Object ID is bad and that having to expose it shouldn’t ever have to be done, but sometimes you just cant get away from needing it. One such instance would be if you are interacting with a vCloud Director and need to do something with a VirtualMachine, then you find you need to go to the vCenter where that VirtualMachine lives to do something else to it that is not supported from vCloud Director. vCloud Director will give you the ManagedObject Reference ID so how do you take that ID and start working with the actual object using pyVmomi? That question came up the other day in IRC but for another use case. The person who asked the question solved their own problem and left the solution. Ill show you the steps required to go from a ManagedObject Reference ID to the actual object you can work with. Please keep in mind accessing variables in python that begin with an underscore is bad, and anything bad that happens to your code because you decided to do this is your own fault. With that out of the way lets get to the code.
>>> from pyVim.connect import SmartConnect >>> from pyVmomi import vim >>> si = SmartConnect(host='10.12.254.137', firstname.lastname@example.org', pwd='password') >>> content = si.RetrieveContent() >>> children = content.rootFolder.childEntity >>> for child in children: ... print child ... 'vim.Datacenter:datacenter-33' 'vim.Datacenter:datacenter-2' >>> children.name '1000110' >>> dc = vim.Datacenter('datacenter-33') >>> dc._stub = si._stub >>> dc.name '1000110'
Lets talk about what just happened here. First I import some requirements and then I connect to the vCenter setting up a ServiceInstance (si). Next to show you what Datacenter objects I currently have in my inventory I get the content, then grab the rootFolder and the childEntity of the rootFolder which by default is the Datacenters. Next I simply loop through them printing the object it self so I can see the ManagedObject Reference ID which shows up as the ‘vim.Datacenter:datacenter-33’ where what I need is the ‘datacener-33’. The way its printed is ‘vmwareObjectType: managedObjectRefId’. Next I show you the value of children.name which will print the datacenter name for datacenter-33. As we see it has a value of 1000110. Now we are at the stage where I manually create a datacenter object using vim.Datacenter(‘datacecnter-33’) and assign it to dc. Next I do bad things by taking the _stub which is an instance of SoapStubAdapter from the ServiceInstance and assign it to the dc._stub This allows me to call the .name on the new object and prints its name. Thats all there is to it. Again I think doing this is really bad, and your code can break in all kinds of ways if _stub is ever changed on the back end, and it can with out notice which is why the syntax of _stub is used. Just because you can do something doesnt mean you should. Yay python and its slogan “We’re all consenting adults here”.