Followup to the Unidesk Deleted Layer from a CachePoint Issue


One of my customers deleted their Unidesk desktops from the View Administrator again and, once again, the system happily deleted a layer from the CachePoint.  This causes a problem in that you can no longer build desktops on that CachePoint that use that Layer (read that linked older post if you want more detail about that situation).  Last time this happened, we knew which Layer was affected because it was a rarely assigned application, but this time we didn’t have any such indicator.  We went through a discovery process this time that we didn’t go through last time and we came up with a far easier solution this time, so here’s the scoop.

First, we had to figure out which Layer was affected.  To do so, I used the Datastore Browser in the vSphere Client.  I knew which CachePoint was missing the Layer, for that CachePoint was the one that was failing to build out the desktops.  I simply Browsed the datastore that that CachePoint manages, as well as the datastore that houses the Master CachePoint.  I browsed into each system’s (the MCP and the CP) folder, then went into the UnideskLayers folder.  First, I looked at the OS Layer, since that strikes me as being most important.  We only have 1 OS in this environment, so this was nice and easy.  I simply verified that all of the files that were present on the Master CachePoint were also present on the Secondary CachePoint, which they were.

With the OS verified, I moved on to my Application Layers.  The desktop that was failing to build had 3 Application Layers associated with it, so I expanded the …\UnideskLayers\App\ folder to find the folders for each of those three layers.  Once again, I compared the contents of the Secondary CachePoint’s instances of those folders against the contents of the Master CachePoint’s instances of those folders.  On the second Application Layer that we examined, we found a hit.

Those Layer .vmdk files do not have pretty names.  It’s a long unique identifier, followed by some versioning information (the B#.R#.V# section).  I don’t know exactly what each of those bits denote (the R# section seems like it may an incremented counter of the number of Versions created of that Layer and I’d guess that the B# probably refers to the Gold Image on which that Layer was created, but those are guesses based purely on the patterns of those numbers), but the R# section makes for a nice easy way to distinguish between the various .vmdk files.

On the second Application Layer that we examined, I noticed that we had an …R2… vmdk file on the Secondary CachePoint, whereas the Master CachePoint held both …R1… and …R2… vmdk files.  Using the Datastore Browsers, I just copied the missing …R1… vmdk file from the Master CachePoint to the Secondary CachePoint (maintaining its relative position in the “UnideskLayers” folder structure).  Once that was copied over, I tried building out a desktop once again and, success!  The desktop built and the application launched successfully!

I expect that this method is not flawless, as it’s possible that the Secondary CachePoint doesn’t actually need all of the versions stored on the MCP, so try them one at a time to ensure that you’re not copying files that the CachePoints don’t need/expect, as that would probably eat up your expensive storage space.

Comments

  1. It sounds like the best practice would be to delete desktops from within Unidesk MA, rather than from View? There's too much of a chance in a CP losing a layer if the desktop(s) being deleted from View are the only ones using that layer (i.e. no locks on the layer .vmdk).
    I'd like to see a feature in the Unidesk MA to be able to delete a View Pool. This should include all of the tasks that View performs when it deletes a Pool - which include removing the desktop object from AD and any other cleanup tasks.

    ReplyDelete
  2. Absolutely - if you build the desktop with the MA, then delete it from the MA. Unidesk often refers to desktops by the acronym of MM - this stands for Managed Machine. If Unidesk is managing the machine, let it manage the machine.

    Unidesk employees are very good about checking their forums (including several of their senior architects). Unidesk already does a lot of cleanup for you on MM deletion; I'm sure that they'd be happy to hear your feedback there and they might even be able to integrate ideas into new releases.

    ReplyDelete

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Deleting Orphaned (AKA Zombie) VMDK Files