VMware Cloud Community
chris94
Contributor
Contributor

Recovery of Guest OS Wndows Using RDM's to a Different LUN???

We are running ESX 3.5 on a SAN and using RDM's (physical mode) for all drives. The LUN holding the OS for a Windows 2003 server has failed. We do not do VCB backups. Took a new LUN, reinstalled Windows, then did a full restore. After the reboot, the guest VM just continuously reboots before the Windows splash screen.

Does anyone know if the issue is that the LUN ID is different with the new config is what woul be causing this? I have an open case with Support, but no answer yet. This seems like something that would/sould have come up in the past.

Thanks in advance

Reply
0 Kudos
11 Replies
lockenkeyster
Enthusiast
Enthusiast

Is it possible this is a BSOD on each boot? If so, try booting into Safe Mode and disabling auto-reboots so that you can read the message regarding the failed boot:

System Properties->Advanced tab->Startup and Recovery Settings->uncheck "automatically restart"

Reply
0 Kudos
chris94
Contributor
Contributor

I am able to hit F8 and choose options, (including safe mode), but it immediately restarts. If I dont hit any keys, it restarts while on the "Starting VMware" splash screen.

Reply
0 Kudos
lockenkeyster
Enthusiast
Enthusiast

Can you post the contents of the vmware.log for this VM?

Reply
0 Kudos
chris94
Contributor
Contributor

No problem. Thanks for the help.

Reply
0 Kudos
lockenkeyster
Enthusiast
Enthusiast

So here's the first part of the offending section:

Sep 03 10:30:32.899: vcpu-0| Unknown int 10h func 0x2000

Sep 03 10:30:36.014: vcpu-0| HBACommon: First write on scsi0:0.fileName='/vmfs/volumes/473f9f77-68292bf4-f2df-000423c9b864/pajctl01_2/pajctl01_2_1.vmdk'

Sep 03 10:30:36.022: vcpu-0| DISKLIB-CHAIN : UpdateContentID: old = 0xa95e471b, new = 0x95041f6e

Sep 03 10:30:36.147: vcpu-0| Triple fault.

Sep 03 10:30:36.147: vcpu-0| Msg_Hint: msg.monitorEvent.cpl0SS (sent)

Sep 03 10:30:36.147: vcpu-0| *** Virtual machine kernel stack fault (hardware reset) ***

Sep 03 10:30:36.147: vcpu-0| The virtual machine just suffered a stack fault in kernel mode. On a real computer, this would amount to a reset of the processor. It can be caused by an incorrect configuration of the virtual machine, a bug in the operating system, or a problem in the VMware ESX Server software. Press OK to reboot virtual machine or Cancel to shut it down.

Just as a sanity check - does this VM have the exact same config as the last one? (# of CPUs, RAM, etc.). If it does, my next step would be to recreate again, restore everything but the systemstate, and see if that boots properly. This isn't ideal, but I have had issues properly restoring systemstate on Windows (physical & virtual).

Reply
0 Kudos
chris94
Contributor
Contributor

Yeah, the config is the same. The machine was fine until the System State restore, like you said. Unfortunately, I really need the system state to be restored in this case. It has a legacy app with custom config that no one in the company has any knowledge of.

Thats why I'm wondering if the machine is trying to use the original LUN path (from the Windows reg).

Reply
0 Kudos
lockenkeyster
Enthusiast
Enthusiast

Odd... seeing as how you can't even make it into safe mode I am wondering if the boot partition is screwy. After you do the restore, can you boot from the Windows .iso and run "fixmbr" from the system restore command line?

Reply
0 Kudos
chris94
Contributor
Contributor

I wish I could, but I cant get past the Recovery Console admin password. Its not accepting the password, which I now know is pretty common., That's Microsoft for ya!

Reply
0 Kudos
lockenkeyster
Enthusiast
Enthusiast

I wish I could, but I cant get past the Recovery Console admin password. Its not accepting the password, which I now know is pretty common., That's Microsoft for ya!

Yikes!

Ok... back to the ESX-centric reasoning then... Do you know the mount point id for the old lun? Maybe there is a way to create a pointer to the new RDM lun which is named the same thing as the old mapping - the idea being to trick the VM into thinking the storage is coming from the same place. Just a thought, sorry if it's not coherent (or possible).

Good luck.

Reply
0 Kudos
chris94
Contributor
Contributor

lock:

Your comment about the mbr got me thinking, and i was able to resolve the issue. Our VM's are using RDM's on an EMC SAN. EMC recommends using diskpar to set the starting offset of the partition on all LUN's to 128. I forgot to do that when I created the new LUN. I started over and the machine boots.

Now I have to just make sure Windows is clean.

Thanks for all of your input. Sometimes you just need a point in the right direction.

Reply
0 Kudos
lockenkeyster
Enthusiast
Enthusiast

Excellent! Glad to hear you're up and running. Take care

Reply
0 Kudos