Virtually Jason

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

(8/10/2015)  Update:  Unfortunately, some backend things have changed since I originally cobbled this script together and it doesn't work any more.  I'll fix it if I get the chance, but in the meantime, there's a free utility called  RVTools  that can identify orphaned VMDK files (which are entertainingly called Zombie VMDKs on the vHealth tab of the application).  That's a great application to be aware of anyway, as it makes it very easy to get access to a lot of important information that the vSphere client obscures. (11/9/2015) Update: I went ahead and put together a post detailing how I used RVTools and a helper script to identify, rename and then delete orphaned VMDK files . Every organization has to wrestle with orphaned VMDK files.  What is an orphaned VMDK file, you ask?  It's a VMDK file that's sitting on your SAN, consuming expensive storage, but isn't actually being used by any VM.  They're notoriously hard to find (especially...