If you have paid close attention to the SOAP messages recorded by Oynx, you may have noticed that there is an extra attribute called “serverGuid” in a ManagedObjectReference. The following is copied from my previous posting “Moving Virtual Machine to Distributed Virtual Switch”.
<_this xsi:type=”ManagedObjectReference” type=”VirtualMachine” serverGuid=”BA9CE658-75F7-4A99-ACE6-99EB1376B94A”>vm-134</_this>
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
Note that this SOAP request message is from a vSphere Client. In VIJava API or other language binding, there is no such an attribute. You may wonder, “will it make any difference while interacting with the vCenter or ESX/ESXi? Why is “serverGuid” there in vSphere Client?” Similar concern was raised in VI Java API forum yesterday. So I think it is worth an article on this topic.
For the first question, the answer is no. If you take a close look at the ManagedObjectReference data object in vSphere API reference, you will find only two properties defined: type and value. There is no additional property called “serverGuid.” Further looking into the core-types.xsd in vSphere Web Service SDK, you will find the following definition. It does not define “serverGuid.”
<complexType name="ManagedObjectReference"> <simpleContent> <extension base="xsd:string"> <attribute name="type" type="xsd:string"/> </extension> </simpleContent> </complexType>
Because the WSDL is the ultimate interface definition, we can be fairly sure that the “serverGuid” attribute is not needed or expected by the server. Of course, the extra attribute doesn’t hurt much other than slightly extra bandwidth wasted. The servers just ignore it.
It doesn’t explain why serverGuid is in vSphere Client’s SOAP request. Let’s take a look at what value is serverGuid. It’s the UUID for a vCenter server the vSphere client connects to. If a vSphere Client manages only one vCenter at a time, it does not need this UUID. What about multiple vCenter servers at the same time? It does need extra information to tell which MOR is for which server. For that, the serverGuid is a good choice for representing vCenter server. And this happens to be vSphere Client’s choice.
Arguably, vSphere Client should remove the serverGuid attribute while generating the SOAP request message. As mentioned, it doesn’t hurt much, therefore no bother to do that. For folks who dig into the SOAP messages, it may be a little confusing.
BTW, I am sure you know in which case your vSphere Client talks to multiple vCenter. If not, check out this article.