We are in the trial phase of virtual desktop deployments. One of the test sites is a department with 9 public workstations. The build of all 9 stations is the same however, there are 5 different roles. The roles are defined by several keys stored in the registry. As of right now I have a logon script that will apply the needed keys based on the users logon name (of which there are 5). I have the 9 VMs as linked clones and all is well but there is one change I forgot to make before the deployment and would like to "recompose" the deployed VMs.
The admin guide states that recomposing, refreshing, rebalancing only works on VMs in a persistant pool, but that you can edit a non-persistant pool to point to a new parent VM. So I loaded up my master vm and made the change, powered it down and made another snapshot, and edited the pool to point to the second snapshot. Now I am stuck on how I go about instructing the deployed VMs to update using the new snapshot. Is there something Im missing or do I have to destroy and provision new systems?
My reason for choosing automated non-persistant was to make it easier on the department in question. If I understand correctly persistant desktops do not allow multiple connections from the same account. So rather than making 9 seperate AD accounts and setting up a persistent pool I created 5 role based accounts and a logon script that will configure the machine as needed. That way they have some additional flexability to add more "type 1" stations just by logging out of a "type x" system and using the #1 logon. It seems to make sense in my mind but if Im way out past left field let me know.
Non Persistent Pool in a View manner menas that a connecting user is potencialy, always redirected to another, a free desktop. Refresh, Recompose and Storage Rebalancing are not availabale in Non-Persistent Pools. If you want to change a base image, you've to edit the pool and do that. The linked clones of the pools will be recreated then.
Don't forget to award the points if this answer was helpful for you.
Right, I know that, in fact I said it in my post.
My question was how do I get the VMs to use the new configuration. I have created a new snapshot as well as editing the original snapshot that the machines were based off of and edited to pool to change what snapshot they are looking at and in both cases the VMs did not reflect the change. So am I missing something or do I have to trash the VMs and reprovision?
You don't have to reprovision. Once you have updated the base image and changed the pool to use that image you can simply delete the non-persistent desktops. The pool will recreate new desktops according to your settings.
This is a problem in that it will also increment the naming counter (if you are using such things). I have lobbied VMware to change this feature since the beta of 3.0 and the introduction of linked clones. The problem, for us, is that because we simply patch the base image with MS patches we are deleting and recreating every month. So, each month the counter increments another 75. After 5 months the machine names are getting a bit ridiculous and we might end up changing them to start the counter over again.
Offering a recompose feature would be nice, I don't care that it just deletes it and recreates it. I want the counter to reuse the old machine names, that is what is important to us.
Yeah, after looking around for an answer I just decided to nuke the systems, shortly after which, I saw them coming back in the VI Client.
Though in my instance I blew away all 9 systems and when they were recreated they used the same #'s. I did it several other times as I was testing the deployment and they always used 1-9. On my latest try I deleted all but #3 (which was in use) and when they were rebuild they went 4-11. I will likely be dumping the set again and I will be sure to do the entire lot and see if they continue 4-11 or fall back to 1-9.
Well, in our case I deleted all the VMs again (#4-11) and when they were recreated they started a #1 so we are 1-9 again. Not sure how yours are constantly increasing.