A fantastic title for a blog post don’t you think? Well, not really but it’s there should someone else be searching for the exact same message.

I’ve been un-picking a very unhappy deployment of VMware’s SRM in our company lab setup today. Our lab is most probably not too dissimilar to your own in that every employee has access, can install and configure what they want. It is a lab and there to prove and / or disprove scenarios.

The problem

After a morning of working through the configuration I thought it (SRM) was finally fixed until I tried to execute a Planned Recovery. The Test Recovery completed without error but it wasn’t as plain sailing for the actual failover. This error appeared in the Recovery Steps:

SRM VM Tools Error

SRM VM Tools Error

I knew the tools were installed as I originally created the test virtual machine for a customer demonstration late last year. Odd. Hopping into vCenter I moved to the VM in question and selected to  Open Console.

The VM was up and running asking for a username and password, I provided these details and was presented with this screen:

Guest OS not licensed

Guest OS not licensed

So, at the time I created the demo last year you can see I deployed a virtual machine that wasn’t licensed. True, it was a quick build from an ISO to show there were no tricks with the intention afterwards to erase the VM – which of course didn’t happen. Ooops. So, the OS was asking for activation. Curious I decided to execute the SRM recovery again to watch for any messages that may appear in the guest OS to provide me with a clue or two.

- Please note, the VMware Tools was installed ;-)

I instigated the failover and watched the console screen intently. Imagine my surprise when this happened:

OS Shutting down

OS Shutting down

A graceful shutdown and the recovery then continued and succeeded, proof here:

Recovery completed

Recovery completed

This meant the login to the guest OS and acknowledgement of the license warning message then permitted the VMware Tools request for a graceful shutdown. Not being entirely convinced about this I set about testing these steps again.

I completed the Reprotect to reverse the Protected and Recovery site roles and ran the same test. Annoyingly this completed and didn’t stall on Shutdown VMs at Protected Site. Hmm. I failed over, then back, then over. Still nothing. Slightly perplexed I left it, had lunch and did other things.

Later I tried it again and bingo – stalled once more. This time when I logged into the VM I was presented with this license reminder screen:

OS Not Licensed Window

OS Not Licensed Window

Once again the shutdown completed successfully after I’d logged in.

In summary

Frustratingly I couldn’t reproduce the steps each time to guarantee the stalling of the guest OS shutdown but the fact it happened twice I thought I’d share it with you. Of course the fix to this is to always license your operating system, it goes with out saying, but also for test environments. You may well be building and flattening environments but in this example this did cause a hiccup and if it can occur in this manner then what else could happen?

Leave a Reply