Moving Linked Clone VM to different LUN without Data Loss

This week I received an interesting question from a colleague that I had also been asked in the past. However, in the past I was not able to present a good solution for the problem. Let me present the scenario.

A VMware View pool of persistent desktops was created and provided to developers using the Linked Cloning technology. Over time the developers deployed their own applications and created content in their virtual desktops. The storage administrator is now requiring the VMs to be moved around and distributed to different storage LUNs for maintenance and performance reasons.

Storage vMotion doesn’t work in this situation and is not supported with Linked Clones. VM cloning will also not work, failing with the following error message:


Screen Shot 2013-03-22 at 10.40.50 AM


Another option is VMware View Rebalance operation, but that one will refresh and reset the virtual desktops to their pristine state. Learn more about Rebalance and other Linked Clone operations in my article VMware View 4.5 Linked Cloning Operations Explained (Part 2).

The VMware KB “Converting a linked clone virtual machine to a full clone virtual machine (1026753)” will also explain how to use vmkfstools to convert the linked clone VMs into full clone and than add it to a VMware View manual desktop pool.

However, my colleague didn’t want to convert Linked Clone VMs to Full Clones because they would lose manageability over the desktop, such as refresh and recompose operations. For this same reason V2V solutions were also not an option because we would have to let View Composer do it’s customization job before doing the migration.


The solution: Horizon Mirage.


Mirage keeps a complete virtual copy of each end point synchronized with the data center. The administrator can re-assign the virtual copy to a new end point (virtual or physical) and all user profile, user data, and user-installed applications will be restored to the new device – even if the new device is a different hardware make or model, or virtual instead of physical. Mirage is hardware and driver agnostic as it created different driver layers for different hardware models.

The administrator is now create a new Linked Clone VM in the correct LUN and use Horizon Mirage to migrate all the data from one linked clone to another linked clone VM.

Mirage also leverages de-duplication in storage – This means that data is only stored once no matter how many users or end-point device exists in a organization.  Additionally, all data is compressed before it is sent and  SSL can be enabled between all client-server communication.

If you want to learn more about Mirage read my article VMware Mirage Architecture and Use Cases.


Please note that at the time of writing this article Horizon Mirage integration is not officially supported by VMware.


This article was first published by Andre Leibovici (@andreleibovici) at


    • forbsy on 03/03/2015 at 9:47 am

    Hi Andre. Did this Mirage method work for your friend?

  1. It worked but it’s a very convoluted process. I would just clone the VM and make it full clone on a new LUN. Is that possible in your case?

    • forbsy on 03/03/2015 at 7:57 pm

    I actually gave the Mirage idea a shot today in my lab. It does copy everything from the “backed up vm” to the destination vm, but creates too many issues within View Admin. View still thinks the backed up vm is on it’s original datastore (which it’s not since the destination vm was created on the datastore we wanted). There were some other small issues as well.
    I’ll have to try the cloning alternative, but that sounds like I’d be left with creating a Manual Pool and importing the clones – which isn’t all bad as these are persistent desktops and refresh, recompose operations aren’t performed on them anyways.

Comments have been disabled.