Diary of a Bad Golfer

I recently ran into a problem where a user accidently reverted to a snapshot within Lab Manager, they didn’t realize this at first and by the time they did I had upgrade Lab Manager to the latest version (2.5.3). This ended up being a bit of a pain so I thought I would document the steps I took.

My first thought was I could fire up the snapshot version of the Lab Manager server, consolidate the disk on the VM in question and then import it into the current environment.

I knew the directory ID of the machine after it was reverted to snapshot (1133). However on the SAN snapshot this directory ID did not exist, I tried booting up the snapshot copy of the Lab Manager server but since it couldn’t contact the managed ESX hosts. Since it couldn’t connect to the hosts I couldn’t even view the properties of the machine to see what the directory ID was at that point.

So at this point all I knew was the machine name, but since Lab Manager stores all VMs but a numbered folder I had no idea where it was. I ran a search in the SAN snapshot looking in all .vmx files for the name of the machine, the command I used was:

find <path to SAN snapshot> -name *.vmx -exec grep -q “<machine name>” ‘{}’ \; -print

That returned 2 directories, just to test it I ran that command in the current SAN volume used by Lab Manager and it returned 3 directories. So now I knew the directory but wasn’t exactly sure how to get it into the existing Lab Manager configuration. Since the user didn’t want the current version of the VM, I went into that directory (1133) and made a backup of all files in it and then removed all of them. I copied everything from the directory I found on the SAN snapshot into the 1133 directory, and renamed the .vmx file to match the one that was in the before (for the 1133 VM). After I did that I was able to deploy the machine from within Lab Manager like normal.