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. UnknownApril 6, 2013 at 11:00 AM

    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. Jason ColemanApril 6, 2013 at 5:27 PM

    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

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more