iforbes
Hot Shot
Hot Shot

How to migrate Persistent desktop link clones desktops to new datastore

Jump to solution

Hi. We have View persistent link clones running in our View environment. We need to migrate these desktops to new storage. Rebalance is out as that will include a refresh operation - destroying anything and all installed in the user's c:\. Is there a method to migrate persistent link clone desktops to a new datastore, while keeping the desktop in the exact same condition (i.e. c:\ is not refreshed).

Thanks

0 Kudos
1 Solution

Accepted Solutions
iforbes
Hot Shot
Hot Shot

Never say impossible. I came across the solution when I read Duncan Epping's article:

http://www.yellow-bricks.com/2012/03/15/dr-of-view-persistent-linked-clone-desktops/

I adapted this to my situation. Basically, replicate the View datastores to the new storage. Mount the replicated datastores without re-signature to the ESXi cluster. Power down and unregister the View desktops from vCenter. Register the desktops from the replicated/mounted datastore to vCenter and power on the desktops.

To vCenter, nothing drastic has occurred as it just sees the activity as vm's being unregistered and re-registered from the exact same datastore (identical UUID). View Admin is happy because it just sees the events as desktops that were powered off and then subsequently powered back on. Nothing has changed with respect to View's ADAM database, as we're still using the identical datastores.

I've already tested this before for a View DR scenario, and it was successful. Between remembering that and Duncan's article it helped me to adapt the same process for this. Nothing is impossible Smiley Happy

View solution in original post

0 Kudos
5 Replies
kgsivan
VMware Employee
VMware Employee

Without a refresh, this is impossible

0 Kudos
cgrubbe
Enthusiast
Enthusiast

Came across a similar situation and the only non destructive way I found was to clone the VM's.  This of course has its own set of issues when it comes View, having to create a new pool and manually add machines into it, grant access, all the usual manual pool setup.  I had a relatively small number of machines to deal with, so it wasn't too much of a headache.

0 Kudos
iforbes
Hot Shot
Hot Shot

Never say impossible. I came across the solution when I read Duncan Epping's article:

http://www.yellow-bricks.com/2012/03/15/dr-of-view-persistent-linked-clone-desktops/

I adapted this to my situation. Basically, replicate the View datastores to the new storage. Mount the replicated datastores without re-signature to the ESXi cluster. Power down and unregister the View desktops from vCenter. Register the desktops from the replicated/mounted datastore to vCenter and power on the desktops.

To vCenter, nothing drastic has occurred as it just sees the activity as vm's being unregistered and re-registered from the exact same datastore (identical UUID). View Admin is happy because it just sees the events as desktops that were powered off and then subsequently powered back on. Nothing has changed with respect to View's ADAM database, as we're still using the identical datastores.

I've already tested this before for a View DR scenario, and it was successful. Between remembering that and Duncan's article it helped me to adapt the same process for this. Nothing is impossible Smiley Happy

View solution in original post

0 Kudos
kgsivan
VMware Employee
VMware Employee

Hi iforbes

Sorry for my comment; because for a traditional datastore change, there is no certified way without OS disk being refreshed, is that what I meant

From your original question, it was not clear to me that this is related to a VSAN datastore. With Software Defined Storage, yes definitely are ways...

0 Kudos
iforbes
Hot Shot
Hot Shot

Hi kgsivan. I'm not using VSAN at all. This is traditional datastores. It's possible to do it the way I outlined.

0 Kudos