Virtually Jason

A few of my customers have large teams managing their VDI and all of the desktop layers that make up those desktops.  One of them asked for help creating a policy to track changes to those layers, as they had run into trouble with accidentally rolling out desktops using a layer version that was still undergoing testing or not knowing what changes had been made on a specific version of a specific layer.  This is a little outside of the normal content that I like to post about on this blog, but we came up with a solid policy that has helped them to get their environment under control, and so I’m going to do my best to explain what we came up with here. The first important detail to the policy was a strong naming standard.  We decided that layer names should be based on two factors, a group specific notation and the name of the application (or set of applications) in the layer.  Most applications are not group specific and so do not need a group notation, but occasio...

One of my customers needed to do a complicated migration recently.  They wanted to move their View + Unidesk VDI environment from vCenter 5.1 on Windows to the vCenter Server Appliance running vCenter 6.  We moved the ESXi hosts and used them to carry the desktops over, just like we do with servers in this sort of situation, but the View stuff added to the complexity.  On the Unidesk side, there's a nice KB article that we followed, but there isn't such guidance for View. You may not have noticed it (I sure didn't until this migration), but on the list of desktop pools, there's a column that lists the vCenter server on which that pool was created.  It turns out that the pools are irrevocably associated with the vCenter server itself and so, when you migrate vCenter servers, you have to recreate all of your desktop pools.  This customer had about 2 dozen pools; an arduous task, but ultimately not all that time consuming... until you think about the ramificatio...

One of my customers has many physical datacenters, each with its own vCenter server.  The servers are all connected via Linked Mode, which works fine in the GUI, but at the CLI I don't usually want to connect to every one of them.  Fortunately, connect-viserver doesn't do so unless you use the -AllLinked switch, so that's fine.  Unfortunately, I'm left in a position where I need to connect my PowerCLI session to any one of many vCenter servers, and I don't necessarily like typing that much or remembering that many server names. Fortunately, I can address both of those points in one fell swoop, through PowerShell Profiles .  When you launch PowerShell, it simply applies the appropriate PowerShell Profile (aka. a script that you can use to customize your work environment) to that session and you're good to go.  So, I put together a customized PowerShell Profile for myself that presents me with a "Connect to vCenter" option and a little text driven men...

One of my customers set up a large number of ESXi hosts, installed on local storage.  Since they're not doing anything with that storage, they never bothered renaming those datastores and so their vCenter inventory was filled with instances of "datastore1 (#)".  This is just a housekeeping thing, but that's really messy.  Generally speaking, a bit of mess isn't a big deal, but those little messes always seem to cause problems when you're troubleshooting some other major issue.  And, fortunately, this is really easy to fix.  Rather than write my own script, I did some quick googling and found that VMNICK had done all the work already, with his own " rename local host storage " script. In his post, he notes that the script might explode if you use the string "datastore1" on any other datastores in the environment.  Excepting a very particular subset of situations, I'm not a fan of explosions, and so I figured that I could probably fix t...

Every now and then, as a virtualization engineer, you'll be going through a log entry or be examining a setting and you'll ask yourself, "I wonder where that file is?".  Why might you ask yourself that?  Probably because you're staring at a path that looks something like this: "/vmfs/volumes/5126bbe6-5478b245-773b-04519ad9e307/SacDC1/SacDC1.vmdk" and all of your datastores are named things like this: "sac-LUN1".  Needless to say, correlating the two can be a bit difficult. Translating LUN Names, just how do we do it?  Really quite simple, there's nothing much to it! (can you tell I have young kids at home?)  The only way that I know of to translate those UIDs to human friendly datastore names is to look at each datastore and see if the UID matches.  While that's an arduous and time consuming task for a human, it's a trivial one for a machine!  So, I put together the following PowerCLI one-liner to track down the datastore: get-...

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...

Have you ever been in a situation where you've needed to reload a VM's VMX file?  It's not very common, but it does happen occasionally.  VMware has a KB Article about how to do it, but it requires vim-cmd, which means that you need access to the host's CLI.  This isn't that big of a deal, unless you need to reload a lot of VMs that are scattered across many ESXi hosts.  Fortunately, Techazine has posted an article about a technique that reloads all invalid VMs via PowerCLI.  In my use case, I only needed to target a small set of VMs, so I just used that technique as follows: @("VM1","VM2","VM3") | % {(get-vm $_ | get-view).reload()}