«

»

Jan 21 2010

New VMware View parameters in your .vmx files

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:

machine.id =
vdi.broker.itemDn=cn=ef0b39dc5ffe420c845fdf18ce1e49f,ou=servers,dc=vdi,dc=vmware,dc=int; vdi.broker.disconnecttimeout=0;
vdi.broker.msMode=OFF;
vdi.broker.brokerPublicKey=MIIBuDCCASwGByqGSM44BAEwggEfAoGBAP1/…..
vdi.broker.agentPrivateKey=MIIBTAIBADCCASwGByqGSM44BAEwggEfAoGBAP1/…..
vdi.broker.poolDn=cn=vexec01,ou=server groups,dc=vdi,dc=vmware,dc=int;
vdi.broker.useSvi=0;
vdi.broker.brokers=meltvcs01.classroom.local vmview4rep.classroom.local vmview4rep01.classroom.local;
vdi.broker.singleuse=0;
vdi.broker.agentIdentity=agent/ef0b39dc-5ffe-420c-845f-fdf18ce1e49f"

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.

3 comments

  1. Andre Leibovici

    The response from @vmwareview twitter user was:

    “Talked to one of the PMs & the VMX is not meant to be user configurable.
    also w/out official DR support what you’re trying to do will be difficult. Look for SRM integration in the future to help.
    Let me know if you have more questions”

    My response:

    “DR works fine, and there also a paper from EMC w/ scripts to change linkedclone database. Unfortunately answer is unsatisfactory.
    BTW – it was also presented atVMworld.”

  2. Chris Westphal

    Following up on our Twitter discussion I’ve received the following details from the PM team:

    There is a program running on each desktop VM called the agent. The agent program is
    responsible for finding the correct Connection Broker as its manager. Communication
    between agent and Connection Broker is authenticated via an asymmetric key based
    mechanism. The agent also needs to know the Connection Broker’s DNS name in order to
    establish a connection.

    The Connection Broker provisions VMs using vCenter. After a VM is provisioned, before
    its agent runs, the Connection Broker must generate a set of configuration for the VM.
    The mechanism to bootstrap the agentConnection Broker communication is through
    machine.id, what you have seen in .vmx file. The name is self-evident. For example,
    vdi.broker.agent.PrivateKey is your agent’s private key. And the vdi.broker.brokers= parameter
    is used to set one or more broker for the agent to connect to.

    This explains why your Connection Broker would be able to find the agent. In fact,
    the Connection Broker didn’t find the agent, the agent finds it.

  3. Andre Leibovici

    @Chris Westphal
    Chris, thanks for the feedback.

    That explains why the virtual machines are able to update themselves with the connection brokers even if the host, datacenter and cluster were changed. Good for a DR scenario if no Linked Cloning is used.

Leave a Reply