The idea for this article started from a research that I was doing for creating a disaster recovery solution for critical virtual desktops in VMware View 4, without the use of Site Recovery manager (SRM) and also trying not to touch the ADAM database. I have published this article last week here.
Anyway, I soon noticed that when powering-on virtual desktops in the DR site, the Connection Broker Replica would automatically have updated itself with the latest information about the virtual desktop, even though virtual machines now had different IP address and were hosted in a new cluster, new datacenter, new resource pool and new virtual machine folder.
Initially I thought it was the Connection Broker pooling virtual desktops via FQDN but later on I found out that VMware View actually add a key called “machine.id” into the .vmx file during the provisioning process and every time the View configuration is changed the .vmx file is also updated.
This information is passed from the Host Operating System to the Guest Operating System and then used by VMware View agent. So, as an example, if we update vdi.broker.singleuse to 1 the virtual machine will be deleted after first use.
I tried to find more information from VMware on those parameters but could not find anything. So if anybody from VMware wants to give us a hand to better understand how we can use and customize these parameters we would appreciate. The closest information I was able to find is, believe it or not, related to VMware GSX Server 3.2 (http://www.vmware.com/support/gsx3/doc/tools_guestd_string_gsx.html)
machine.id is a long and concatenated string containing several parameters related to the virtual desktop behaviour and if broken out will present the following:
vdi.broker.brokers=meltvcs01.classroom.local vmview4rep.classroom.local vmview4rep01.classroom.local;
I am not sure if these parameters were present in VMware View 3 but would be good to know what each parameter is responsible for without having to guess ourselves.