«

»

Oct 11 2010

VMware View 4.5 Linked Cloning Operations Explained (Part 2)

Advertisement

In this second part of VMware View 4.5 Linked Clone Operations article we will explain how Recompose and Rebalance operations work. This article is based on a document created by Keith Johnston.

The part one of this article can be found at http://myvirtualcloud.net/?p=1237 covers provision, customisation and refresh.

 

Recompose

A recompose operation allows the administrator to preserve the persistent disk and all user data inside this disk while changing the OS disk to a new base image + snapshot. This allows administrators to easily push out OS patches and new software to users. Recomposing between major OS versions is not supported (XP->Vista, XP->Windows7,Vista->Windows7).

Because a new OS disk is created during a recompose, the clone is also re-customized during the recompose and a new snapshot is taken by View Manager once the customization completes.

An important note about recompose is that the network interface MAC address and Windows SID are not preserved after the operation. Some desktop management tools and some antivirus may present issues and require the previous values. However, SID is currently in disuse and even Microsoft is not supporting NewSID tool anymore. The UUID of the virtual desktop remain the same.

  1. View Manager puts the linked clone into the Maintenance state.
  2. View Manager calls the View Composer resync API for the linked clones being recomposed, directing View Composer to use the new base image + snapshot.
  3. If there is not yet a replica for the base image + snapshot in the target datastore for the linked clone, View Composer creates the replica in the target datastore (unless a separate datastore is being used for replicas, in which case a replica is created in the replica datastore).
  4. View Composer destroys the current OS disk for the linked clone and creates a new OS disk, linked to the new replica.
  5. The rest of the recompose cycle is identical to the customization phase of the provisioning and customization cycle.

I am not going to picture the operation as it is similar to the provision and customisation. The only difference is that the persistent disk is not touched and then attached to the new linked clone.

 

Rebalance

The rebalance operation moves linked clones to the best datastore available to take advantage of the available storage space. VMware View performs the rebalance operation because as of View 4.5, there is no other supported way of moving linked clones from one datastore to another. Don’t try to storage vMotion your desktops trough vCenter.

A rebalance operation may do nothing – if all the datastores have about the same amount of free space remaining, there is no point in moving linked clones around. A rebalance will only move linked clones if one of the datastores in the pool has much less free space than the others.

Just like the recompose network interface MAC address and Windows SID are not preserved after the operation.

image

  1. View Manager puts the linked clone into the Maintenance state.
  2. View Manager decides which VMs to move based on the free space in each datastore. See Storage Overcommit for Linked-Clone Desktops in the Administration guide for a discussion on how storage is managed and how View decides which datastores to use.
  3. View Manager detaches the OS and persistent disks from the VM
  4. View Manager moves the detatched disks to new datastores
  5. View Manager moves the VM itself to the new datastore using the relocateVM_Task API.
  6. View Manager re-attaches the disks to the linked clone
  7. View Manager calls the View Composer resync API for the linked clones
  8. If there is not yet a replica for the base image + snapshot in the target datastore for the linked clone, View Composer creates the replica in the target datastore (unless a separate datastore is being used for replicas, in which case a replica is created in the replica datastore).
  9. View Composer destroys the current OS disk for the linked clone and creates a new OS disk, linked to the appropriate replica.
  10. The rest of the recompose cycle is identical to the customization phase of the provisioning and customization cycle.

Similar Posts:

Permanent link to this article: http://myvirtualcloud.net/?p=1246

2 comments

  1. Tony Wieczorek

    Very important to get answered quick please!
    I have a client running View 3.0 and need to migrate to a new array. I’ve been moving their linked clones one at a time using the rebalance option.
    I was told (and read) that this is the only way to do it. Few questions…
    1. Can I do a SAN array copy and copy the whole LUN to another LUN and be done with it?
    2. If they have replicas for each pool can i run concurrent moves with each pool?
    3. Is there a better way to do this that I can’t seem to find on VMware or the internet?
    Tony

  2. Andre Leibovici

    Tony,

    Please be aware that re-balance will delete the delta disk and this is the same effect as doing a refresh.In saying that, this is the only supported method to move linked clones between datastores or arrays. To speed up the process de-select the current datastore in View and select only the destination datastore, after that trigger the re-balance option.

    Andre

Leave a Reply