27 Jun 2013 by rayheffer
Following on from my previous video blog where I described how VMware View Linked Clones are created, I have decided to make this available as a more detailed written article. VMware View Composer is a service that can run on either the vCenter server or on a standalone dedicated machine. In this technical deep dive I describe what makes a linked clone, the role of View Composer and exactly what it does.
View Composer consists of a web service (SIM), the Universal File Access (UFA) service and other components it relies on such as ADutil and the vCenter API. View Composer receives instructions from View Manager as XML messages, and initiates the linked clone creation using vCenter API calls and the SIM service (Scalable Image Management, a.k.a Composer). In essence it’s a workflow engine.
View will communicate with Composer (SIM) web service using SOAP (Simple Object Access Protocol) over TCP port 18443 which uses XML as the message format to View Composer. For a more detailed look at the network ports used, refer to my View Network Communication and Port diagram that I created back in April 2012.
If you have ever had to troubleshoot issues with View Composer before then you may well have run into issues like the one described here: https://kb.vmware.com/s/article/1031425. You can learn an awful lot from analysing the View Composer log files, and I don’t mean solely for troubleshooting when things go wrong. Take a look at the View Composer log (C:\ProgramData\VMware\View Composer\Logs) in a running environment and you can see the workflow engine, requests to create clones, SOAP, SSL certificate validation, creation of AD computer objects and much more. This is where I’ve spent much of my time in putting together these notes.
If you want to understand vCenter API’s and the methods used by View Composer, the vCenter SDK and API documentation (https://www.vmware.com/support/pubs/sdk_pubs.html) contains a reference of the methods available. Take CloneVM_Task for example, as View Composer will use this with the VirtualMachineCloneSpec specification, where the snapshot can be specified of which to originate the clone. Other methods used by View Composer are RegisterVM_Task, and ReconfigVM_Task are good examples of this.
The first step taken before the pool is created is to prepare our master desktop image, and take a snapshot. In reality, multiple snapshots may exist as the master desktop image is patched and updated. Each snapshot could even contain different virtual machine configuration such as the network port group as the VirtualMachineCloneSpec snapshot parameter will base the clone on the snapshot and configuration of the VM when the snapshot was taken.
When you create a desktop pool using linked clones, you are required to configure the pool settings including virtual machine naming, number of desktops, how many desktops to provision upfront, and whether a disposable disk is required. In addition, you can select whether separate datastores for the replica and linked clones are to be used. One of the final steps before guest customisation settings is to select the snapshot you want to base the linked clones on. This is what will be cloned to the replica disk.
To make this easier to understand, lets use an example of a desktop pool containing 10 desktops. Once the pool is created and provisioning is enabled for that pool, View will request that View Composer creates 10 linked clones.
In our scenario, View Composer will create 10 clone creation tasks and it will run these clone creation tasks in parallel depending on the ‘Max concurrent View Composer provisioning tasks’, which is set to 20 by default (VMware View 5). A single linked clone creation task will perform the following:
View Composer isn’t going to request a new replica if one already exists. For example, you may be provisioning more desktops to an existing pool, or simply a new desktop pool where a replica already exists (i.e. used by another pool). (If replica exists then skip to step 3)
This references the snapshot of the master desktop VM specified during the View Pool creation. View Manager enters the ‘provisioning’ state at this stage.
This only occurs if you have VSA (View Storage Accelerator) enabled.
View Composer creates the linked clone virtual machine and registers it in vCenter using RegisterVM_Task (vCenter API).
You’ll see this action in the View Composer logs by searching for: ServiceCore.ActiveDirectory.AdUtil.
This includes the 20MB internal disk, and if specified during the desktop pool creation, a persistent disk and disposable disk. View Composer used the vCenter API ReconfigVM_Task method here.
These steps can be seen in the View Composer logs under ‘UFA Thread’ and used the VcSubsystem and UfaSubsystem. I’ve broken this down into the following steps:
View Manager will now place the virtual desktop into the ‘Customizing’ state. The desktop will reboot and enter customisation with Sysprep or Quickprep, depending on how you configured the pool.
The desktop is joined to the domain using NetJoinDomain, and the generated computer account password stored on the internal disk.
The virtual machine is powered off and a snapshot is taken. Depending on how the desktop pool is configured, the virtual machine will either remain powered off and enter the ‘provisioned state’ or it will power on and once the View Agent communicates with View Manager it will enter ‘Available’ state.
It’s important to note that I’ve just described a single linked clone creation task, but you’ll see by monitoring vCenter that multiple tasks actually run in parallel. View Composer is a mature and reliable technology providing it has been implemented correctly.
If it’s single desktop image management you want, then Composer is a fantastic feature of VMware VIew, and hopefully now you see exactly how it works you can appreciate the technical brilliance of linked clones. Of course, View Composer on it’s own couldn’t deliver linked clones without vCenter.
I recently read a blog post by Andre Leibovici, which actually makes some very good points. But I guess you could say I’m one of those ‘non-persistent fanboys’ having designed some very large non-persistent VDI implementations such as Jaguar Land Rover and Colt. But I’m a fan of the tech, and Andre is totally spot on with his observation that linked clones have their place.
Comments are closed for this post.