Virtually Jason

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