What is the most effcient way to find VM by vm-mor?

[zukeru]

I've been looking into how search for VMs. I looked through the documentation and the community samples, but found nothing.

I want to find VMs by thier MOR, I believe in pyvmomi its called _moId. I could get all the vms and save them into a dictonary but I believe that would be slower. I'm not entirely sure its possible, but if anyone could help me find a vm by is _moId or mor according to pysphere that would be awesome.

[michaelrice]

Hello @zukeru While I think this is a terrible terrible idea to do I have written a blog about how to do it. Please check this out: http://www.errr-online.com/index.php/2014/10/12/using-the-managed-object-id-to-create-objects-with-pyvmomi/ and let me know if this is what youre after or not.

[zukeru]

yes the managed object id so for instance a vm will be vm-43 a datastore will.be datastore-1 etc. On Nov 4, 2014 5:53 PM, "Michael Rice" notifications@github.com wrote:

Hello @zukeru https://github.com/zukeru While I think this is a terrible terrible idea to do I have written a blog about how to do it. Please check this out: http://www.errr-online.com/index.php/2014/10/12/using-the-managed-object-id-to-create-objects-with-pyvmomi/ and let me know if this is what youre after or not.

— Reply to this email directly or view it on GitHub https://github.com/vmware/pyvmomi/issues/183#issuecomment-61742824.

[michaelrice]

@zukeru so then it sounds like the blog post got your issue resolved. Is that correct?

[zukeru]

i need to look through it some more when i get home. im driving thanks for the quick reply. On Nov 4, 2014 6:12 PM, "Michael Rice" notifications@github.com wrote:

@zukeru https://github.com/zukeru so then it sounds like the blog post got your issue resolved. Is that correct?

— Reply to this email directly or view it on GitHub https://github.com/vmware/pyvmomi/issues/183#issuecomment-61744564.

[hartsock]

@zukeru while I understand the problem, I would like to officially discourage the use of MOR as a between-systems identifier. The Managed Object Reference ID should be viewed as a vCenter internal identifier and not as a durable identifier like a UUID. Virtual Machines have two UUID in vSphere. We have the UUID for the instance and a UUID for the Guest OS's BIOS. So, I'll just finish that little sermon with: If you've designed around a MOR being saved for longer than 5 minutes you should seriously consider a redesign.

I'll close with affirming that @michaelrice's post post is dead on for how to get pyVmomi to jump into a managed object. If it feels a bit hacky, that's because it should feel a bit hacky. We don't want that ID to get spread around too much and when you do use it, we want you to really think about it.

Consider all the ways that the API deliberately exposes for you to find things. Try and keep your designs focused on that. If there's a VMware product that doesn't use these, then IMHO we've got a bit of an impedance mismatch that needs to be fixed.

FindAllByDnsName (in SearchIndex )
FindAllByIp (in SearchIndex )
FindAllByUuid (in SearchIndex )
FindAssociatedProfile (in ProfileManager )
FindByDatastorePath (in SearchIndex )
FindByDnsName (in SearchIndex )
FindByInventoryPath (in SearchIndex )
FindByIp (in SearchIndex )
FindByUuid (in SearchIndex )
FindChild (in SearchIndex )

Other ways to look up by Managed Object Reference ID would involve the use of property collectors but this would require you to build your managed object reference just as @michaelrice has shown.

[zukeru]

Thank you so much for the responses, I have decided to just continuously loop through the VMs and update my db.

[hartsock]

NOTE: Just because it's come up and someone else might want to read this,

The bit about exposing the MOR ID is bad thing is my opinion. I personally think that the MOR ID is like a table row identifier of 15 where virtual machine number 15 is not all that meaningful beyond the local context. So it's not a good place to do integration work from. There are going to be situations where we're so deep inside what's going on with vCenter that you'll be forced to use that MOR ID. I consider that unfortunate and I don't want to necessarily paper over that issue because it's something I feel you need to be mindful of. Whenever you use a MOR ID ... I personally want you to have to access a hidden method name because I want you to say to yourself ... do I really need to do that?

I tell a story to illustrate this:

Let's say I live in NYC and I buy a parking spot. My neighbor Steve Smith keeps parking in my special paid parking spot. I want the cops to issue him a ticket. Steve Smith is person number 15 in my personal rolodex. If I call up the cops and say, "Person 15 keeps parking in my parking spot." They have no idea who I'm talking about because they don't own a copy of my Rolodex... nor should they.

If I refer to Steve Smith by his NYC drivers license number or by his SSN number there's a reasonable chance that a third party can decipher what I'm talking about because these are shared unique details about the individual we're talking about.

With Virtual Machines on vSphere we talk about the instanceUUID and the biosUUID which would be analogous to the driver's license ID and the SSN number depending on which context we're using. One context is a State-wide identifier the other is Nation-wide. There will be use-cases where no other practical identifier can be found and I consider those ragged edges of our API that need to be fixed someday.

This is my personal opinion and official VMware guidance may vary.

[ralgozino]

Hello there,

I'm trying to determine what identifiers to sue when trying to link a VM y my system to one on an ESXi server. First I used the UUID, an then both the uuid and the InstanceUUID, but I found that the UUID can be duplicated in two different VMs. Then I added the vm-mor to the check.

What is the recommended value used to identify the VM? What are you using?

Thanks in advance.

[hartsock]

It depends on what you want to identify. InstanceUUID means the VM. Then there's the BIOS UUID which identifies the Guest OS at the BIOS level. Hypothetically a guest OS Bios can be lifted out of a VM instance then moved to another VM instance which has a new UUID. This kind of identity swapping can happen during some VM copy, clone, or movement operations.

In other situations, a name value or a MOR ID (aka moref) is only valid within the context of a single vCenter and for many practical situations this is unique enough. In others, it's woefully inadequate to identify a virtual machine by because there are a very large number of vCenters and virtual machines ... and there's no guarantee that moref number 5 is the same conceptual machine on vCenter A and vCenter B ... in fact its almost universally not the same.

My opinion is that exposing the MOR ID and the name as identifiers on the API was a mistake. Many people have good reasons to disagree with that opinion. I have no problem with them being understood as descriptions ... you can use the name or moref id as a field to find a managed object in a pile of managed objects just as you could use a bit of description text to find a web page in a search engine. But the value "phil's home page" describes the page living at the canonical URL that identifies Phil's homepage on the internet.

Does that make sense? You can find a page by its title, but you can't navigate to a page by putting its title in the navigation bar of your browser except by special circumstance or coincidence. A VM name is like a page title, a morefid is like a path under a URL.

[ralgozino]

Hello @hartsock !

It makes sense. Actually, we create the VMs using packer, and it removes automatically the VM from the inventory when finishes. Then, we have to add it later again and the MOR ID changes (increments by 1). This is a "problem" because our system scans the ESXi server (not vCenter) every 5 minutes and finds a "new" VM because of this change.

We added the MOR ID check, because we find that 2 or more VMs share the same UUID, and several have the InstanceUUID empty (blank).

To summarize, do you consider the InstanceUUID unique enough to refer to the VM? What do you do in the cases that it is blank? do you use the UUID as InstanceUUID?

Thanks!

[hartsock]

So the reason I can't just say "Do X" is because it's highly situationally dependent on things I don't know about in your system. But, I think this KB will help you understand the problem in higher detail if that helps and this KB covers custom ways to manipulate UUID as you move things around.

It sounds like InstanceUUID tells you about the instance and when the VM moves to a new location and gets a new InstanceUUID that you might not care and might consider that a "new" VM even though logically it's the same VM. So, when is the "thing" not the same "thing" any more? That depends on what you care about and identify as "the" thing.

Well... that depends on what's salient to what you care about in the VM. Is it the file system? Then the virtual disk UUID probably helps... but what if that UUID is used in multiple compute contexts? What about the BIOS UUID? What if we copy that? Maybe we care about the IPv6 address?

In one case, I think we determined that Inventory path as used by vim.SearchIndex was the right thing. You might be served by using a coordinate system where you associate "the thing" with the ESXi host FQDN and the VM name... but that would be pretty unique and have its own special problems.

[michaelrice]

The instance UUID can be blank but in an environment with over 50k VMs Ive personally not seen that happen. VMs that make up a vApp can and do share the same bios UUID which makes it less useful to use. The MORef and the InstanceUUID are the only properties that will be unique. If you see the docs on instanceUUID they say: "VirtualCenter-specific 128-bit UUID of a virtual machine, represented as a hexademical string. This identifier is used by VirtualCenter to uniquely identify all virtual machine instances, including those that may share the same SMBIOS UUID." So instanceUUID is what I use, but if you are worried about it being blank since the docs do say it could be blank the MORef is the only other thing that is guaranteed to be unique. Also if you are working with vCloud director and having to do stuff between vSphere API and vCloud API to a vm in a vApp you will need to use the MORef because the VCD API will give you that info and not the UUID info..

-mike

On Wed, Mar 2, 2016 at 1:06 PM, Ramiro Algozino notifications@github.com wrote:

Hello @hartsock https://github.com/hartsock !

It makes sense. Actually, we create the VMs using packer, and it removes automatically the VM from the inventory when finishes. Then, we have to add it later again and the MOR ID changes (increments by 1). This is a "problem" because our system scans the ESXi server (not vCenter) every 5 minutes and finds a "new" VM because of this change.

We added the MOR ID check, because we find that 2 or more VMs share the same UUID, and several have the InstanceUUID empty (blank).

To summarize, do you consider the InstanceUUID unique enough to refer to the VM? What do you do in the cases that it is blank? do you use the UUID as InstanceUUID?

Thanks!

— Reply to this email directly or view it on GitHub https://github.com/vmware/pyvmomi/issues/183#issuecomment-191375603.

[hartsock]

Thanks @michaelrice that's a very important perspective and I've complained about that actually. I hope the InstanceUUID becomes more universally used.

EDIT: In these cases you may be forced to fabricate a composite identifier of vCenter + MorefID to handle any special cases where you might be moving between multiple Virtual Center instances. But, like I said... that's not always a problem for people and I've probably seen the multiple vCenter thing much more than most other developers so I think it's a bigger deal to me than it might be in more practical environments that normal people work in.

[alexcampos09]

I'm trying to list all VMs attached to a tag and the only information that I'm getting is the MoID, if I'm not supposed to use it, why is that the only information I'm getting out of it?

[Zer0x00]

Since the original blog post is down here's the code:

>>> from pyVim.connect import SmartConnect
>>> from pyVmomi import vim
>>> si = SmartConnect(host='10.12.254.137', user='administrator@vsphere.local', pwd='password')
>>> content = si.RetrieveContent()
>>> children = content.rootFolder.childEntity
>>> for child in children:
...   print child
... 
'vim.Datacenter:datacenter-33'
'vim.Datacenter:datacenter-2'
>>> children[0].name
'1000110'
>>> dc = vim.Datacenter('datacenter-33')
>>> dc._stub = si._stub
>>> dc.name
'1000110'

Source: https://web.archive.org/web/20190709110304/http://www.errr-online.com/index.php/2014/10/12/using-the-managed-object-id-to-create-objects-with-pyvmomi/