Migrating View vCenter and Connection server?

[wframe]

Hi all,

I have one View Connection server (4.6), and one vCenter server (4.1) with View Composer (2.6).

The View Composer server is unhealthy and at the very least I would like to completely replace this.  Ideally I would like to start with fresh installs for both.

Is it possible to migrate an existing deployment without downtime for the guests (linked clones and others)?  Ideally to servers with the most recent versions, running parallel to the existing setup?  If that doesn't work, for the View Connection server alone?

My primary concern is the migration of two manual pools of linked clones that recently needed to be rebalanced on new storage with short notice (i.e. no time to coordinate with View update), to the chagrin of our users.  I would like to avoid refreshing these desktops again.

Your insight would be greatly appreciated!

[mittim12]

Any kind of movement of linked clones to a new vCenter will require a new pool to be created and pointed to the new vCenter instance which in turn means they will be refreshed.   Also, any kind of rebalance to new datastores requires a refresh.

[wframe]

Thanks for the quick response mittim12 - will look into the View Connection server side of things then!

Just went through rebalancing to new datastores and I don't think our users would be happy if I let them know they would need to start from scratch again : )

[mittim12]

Are you using persistent disk with these linked cloned pools?  If so then only the OS is refreshed and the persistent disk would remain in it's current configuration.    If your not using persistent disk I would look into imlementing some time of profile management (View Persona) to assist in situations like this.     You will eventually have to refresh your clones.

[wframe]

We do have that implemented - from my outside perspective, this pools was created as a balance between needs for personal VMs (e.g. some team members need SQL or other specific applications) and the need to minimize storage usage via linked clones.  Thus we now have linked clones that take up less space, but are individually customized to a point where it refreshing requires significant coordination and effort.