Skip navigation


2 posts

Automated Linked Clone Pool (SVI) is one of the most promising desktop provisioning for administrators. Since there are multiple components related to this, misconfiguration in any of those will lead to pool error during or new pool creation or pool maintenance operations like recompose, rebalance and refresh. Here I am going to discuss the most common errors and a possible root cause of  which may happen to such environment. I hope this would be helpful as a checklist to the reades for resolving such issues and errors.


01.  Linked Clones not joined to Domain

Linked Clones, during provisining first joins to the domain controller. For the the Domain selected at the Guest Customization page of pool creation wizard will be used. Even for sysprep customization same domain name is used for membership and NOT the domain which is mentioned inside the custom specification. If linked clones are not joining to the domain are the issues whcih is most likely to happen


  1. The DNS Server mentioned in the Parent snapshot is not resolving the Domain name
  2. For sysprep pool, the DNS configuration mentioned in the Custom Spec is wrong
  3. The Parent VM settings, Network card is not enabled for "Connect at power on" before taking the snapshot
  4. Domain is not reachable in the network
  5. VMware tools are not installed in the Parent VM (specific to Sysprep Customization)
  6. Enough ports are available in virtual switch for all VMs to connect.
  7. The domain name is not resolved from Connection Server/vCenter/Composer


02.  View Composer Configuration failed

The View composer service typiclaly runs in vCenter Server. vCenter server for a Connection server can be configured at In View Administration - Configuration - Servers. For a given vCenter Server, Composer can be enabled and configured by checking the option"Enable View composer"

This may end up in error because of following reasons


  1. The credential used to add the vCenter server does not have a local administrator priviledge
  2. The View composer server is not running
  3. The view composer service port number is blocked by firewall (Default port number 18443)


03. Errors in Provisioning and Maintenance operations

Provisioning errors can be because of multiple external factors and environmental issues and setup problems to the VI infrastructure.

  1. An un-healthy cluster is selected for provisioning
  2. The selected datastore not visible to one or more  ESX in the cluster
  3. vCenter server reconfigured/upgraded without taking view into consideration (refire View upgrade guide)
  4. Datacenter or vCenter Name changed
  5. View composer service is not running
  6. View Composer Service is running but dead due to database connectivity issue (restart the service and verify)
  7. VCenter server is running but dead due to database connectivity issue (restart the service and verify)
  8. View Composer or vCenter Server Database error, conflict or stale entries


04. Licensing Errors

VMware recommends KMS activation for Linked clones (Vista or later). View composer will invoke a KMS activation from each linked clone. The parent VM must be set for KMS activation with valid KMS server.


  1. KMS Server is not reachable on the network where the clones are connected to.
  2. KMS server name is not resolved by DNS configured for linked clones
  3. The total no total activation request in KMS server is less than or equal to 25


05. Other Errors
  1. Unable to add Domain accounts in vCenter Configuration: This is becasue the specified domain is not reachable from the vCenter Server. The DNS entry need tobe verified for vCenter Server.

  2. View Administrator displays "Unable to connect to View Composer": The View composer service is running but dead due to database issues. Restart the Composer service and verify



This  is my first blog post. Here I'm going to discuss a use case where an  automated linked clone pool with persistent disk is required to move from  one Virtual Center server to another one. Many of you might be familiar  with the traditional process of upgrading linked clone pools using the  step by step upgrade process which include one by one upgrade of View,  vCenter, ESX, Parent VM and finally upgrading the pool using a recompose  operation to a new snapshot created after upgrading the parent Virtual  Machine. The detailed process is described in VMware View Upgrade Guide.  But if someone is looking for moving linked clone pools with user data  and ownership to another vCenter server then it is not easy as upgrade  and there is no straight defined method to perform such migration. But  leveraging some of the View features we can achieve the migration of  such pools to a different vCenter Server maintaining the data and  ownership.


First  of all let us see how an SVI pool is internally constructed. An  'Automated Linked Clone Pool' internally refers to a 'Deployment Group'.  The pool specification will be according to attributes defined in the  Deployment Group and it comprises of information regarding the Virtual  Center, Parent VM and Snapshot information of the linked clone pool. The  vCenter information will be tagged with its vCenter ID. As an Admin,  one can edit an SVI pool and change certain Pool Settings, Provisioning  and vCenter Settings. But the vCenter for a pool cannot be changed at  any instance. Becacues any change to the vCenter information will cause  losing the structre of Deployment Group and View Connection Server and  Composer will lose track of the vCenter objects for the pool. Hence for a  given pool it is not possible to edit vCenter by any means of the  method.


Here  if admin wants to move the pool to a new set of ESX/Clusters then it  can be changed in vCenter settings during pool edit wizard. A successful  rebalance followed by this action will ensure that the pool is using  the new ESX/Cluster resources. This is a feasible option for those want  to move the pools from vCenter 4 to vCenter 4.1 without disturbing the  existing 4.0 ESX Cluster. This can be done as follows

  • Upgrade Virtual Center from 4.0 to 4.1
  • Create a new cluster using new ESX 4.1 machines in the same vCenter Server
  • From View Administrator edit the pool, and in vCenter settings select new cluster as the resource pool
  • Rebalance the pool (You can also recompose the pool in case if you want to  want to refer to new snapshot of a ESX 4.1 VM)


How  can we migrate pool from one vCenter to another one? It will not be a  pure migration as such but can be achieved by moving the persistent  disks along with user ownerships. As an example here I am discussing how  to perform the same from a vCenter 4.0 to 4.1. Let us assume that there  are two vCenter servers available 4.0 and 4.1and ESX servers on both  has access to at least one common SAN storage LUN. In this vCenter 4.0  is configured with a View 4.5 Connection Server and an SVI pool exists  on this vCenter. As a first step to the migration, from the pool  inventory 'delete' the pool you will get a confirmation dialogue box as  below


Choose  the option 'Use following datastore' and browse for the common  datastore which is presented across ESX in both the vCenters. The pool  should be deleted from the connection server leaving all the persistent  disks on the chosen datastore. Now from the Server TAB in View  administrator page add the second vCenter and configure the View  composer. Add the same domain accounts in the View composer  configuration which was used on the first one. Create a new automated  linked clone pool on the new vCenter. Make sure that you use a snapshot  of an OS that is same as the old pool. The new pool should be created  with following provisioning settings


  • provision desktops on demand
  • minimum no of desktops =  1
  • maximum number of desktop = greater than or equal to the no of VMs in the old pool


Once  the pool is created entitle the pool to all users who all were entitled  in old pool. Now the task is to create the desktop for each user  keeping thier old data. For that open the 'Persistent disks' page and  select 'Detached' tab. All the persistent disks which were archived from  the old pool will be listed here.



You  may notice that those entire archived persistent disks will have the  "Last Pool" column blank. This is because the old pool (or the source  pool for those persistent disks) was deleted. Now each persistent disks  has to be edited and associated with the new pool. Depending upon the  number of persistent disks this may be a tedious job because as of now  there is now way of editing 'multiple selected persistent disks' from  the 'View Administrator' page. So you have to edit each persistent disk  and need to choose the newly created linked clone pool.

edit persistent disk.png


Here  one thing you will notice that the user ownership for each datadisks  are maintained properly. Once completing the edit task you will able to  easily create linked clones  in the new pool for each persisten disks.  Using Control (or shift) key select all the edited persistent disks and  click on the "Recreate Desktop" button



All the linked clones will be immediately provisioned and user settings and data will be intact in each VMs.

Now you will have a pool in the new vCenter which is same as that of the old pool.