Hi, this post is looking for feedback and to help others out with a similar issue.
I have been tackling this problem for a few days (I'm a VMWare novice) and finally I have at least found a solution but not really a proper reason why this occurs.
Basically we have a number of working VMs in VSphere, which we P2V'd using the VMware cold boot convertor (4.1.1).
I have been backing these up quite happily with VRanger Pro 4.5.0, recently I had to restore one of these VMs into an isolated vSwitch along with a different VM name to do some testing.
The restore ran fine, but then the VM was booted I got presented with an "Error Loading Operating System" error.
No problem I thought, might just need an MBR fix or to set the active partition again. I tried all of this using the Server 2003 R2 CD and the recovery console, but nothing would solve it.
I then came across a fix to the problem using a virtual floppy, containing the ntldr, ntdetect.com and a customised boot.ini (I grabbed the ntldr and ntdetect.com from the working VM to ensure of the same OS files).
I then edited the non-working VM to make sure it booted from floppy first, and it successfully booted the VM (basically the floppy disk did the boot process loading ntldr and ntdetect.com, and then the customised boot.ini loaded the OS from the correct partition).
I then decided that whilst this works, I was not happy to accept a virtual floppy booting my OS each time.
Eventually I stumbled upon the idea of downloading the .vmdk descriptor file both from the working VM and the non-working restored VM to compare the disk geometry (to download the small hidden descriptor, I went into datastore browser in vSphere/vCenter, and started downloading the big VMDK file (this then downloads the small descriptor file first, allowing me to cancel the big download of the flat .vmdk).
I found that the geometry of the hard disk was different across the 2 descriptor files, when they should be exactly the same.
The working VM had these entries (other entries removed)
-------------------------------------------------------------------------------
ddb.geometry.sectors = "32"
ddb.geometry.cylinders = "8716"
The non-working VM had these conflicting values
------------------------------------------------------------------
ddb.geometry.sectors = "63"
ddb.geometry.cylinders = "4323"
So I decided to edit the descriptor file for the non-working VM and change both the sectors and cylinders values to be the same as the working VM. I uploaded the file back using the datastor browser. The VM then booted fine :) :)
My guess is that the virtual could not boot originally because the geometry was incorrect and could not find the boot sector location. It's strange though because if I use the descriptor generator available on-line ( http://forums.phdvirtual.com/wrapgen/) and put in the correct size of the -flat VMDK then it gives me the values which do not work......
I can only think that the original P2V conversion did something strange with the geometry of the VMDK file, maybe it's because the original physical servers had 2 physical ~34GB disks in a RAID1 configuration and perhaps the offline cold boot convertor made the geometry consistent with 2x34Gb disks ? Which would seem to roughly match the geometry settings that actually work.
If I clone the working VM in VCenter, then the clone will boot OK with no problems, presumably because the descriptor gets properly copied across as part of the clone process...
It would appear that Vrange 4.5.0 (i've also tried 4.5.3 and it has same issue), only generates the descriptor header file based on the size of the VMDK flat after it's restored.. I would sugges that VRanger actually takes a look at the original descriptor file, reads the geometry parameters/values and makes sure that when it gets restored the same geometry gets written back as well.
Hopefully this will help others, and any advice from other people on this would be most helpful.
Thanks,
Simon.
I have been tackling this problem for a few days (I'm a VMWare novice) and finally I have at least found a solution but not really a proper reason why this occurs.
Basically we have a number of working VMs in VSphere, which we P2V'd using the VMware cold boot convertor (4.1.1).
I have been backing these up quite happily with VRanger Pro 4.5.0, recently I had to restore one of these VMs into an isolated vSwitch along with a different VM name to do some testing.
The restore ran fine, but then the VM was booted I got presented with an "Error Loading Operating System" error.
No problem I thought, might just need an MBR fix or to set the active partition again. I tried all of this using the Server 2003 R2 CD and the recovery console, but nothing would solve it.
I then came across a fix to the problem using a virtual floppy, containing the ntldr, ntdetect.com and a customised boot.ini (I grabbed the ntldr and ntdetect.com from the working VM to ensure of the same OS files).
I then edited the non-working VM to make sure it booted from floppy first, and it successfully booted the VM (basically the floppy disk did the boot process loading ntldr and ntdetect.com, and then the customised boot.ini loaded the OS from the correct partition).
I then decided that whilst this works, I was not happy to accept a virtual floppy booting my OS each time.
Eventually I stumbled upon the idea of downloading the .vmdk descriptor file both from the working VM and the non-working restored VM to compare the disk geometry (to download the small hidden descriptor, I went into datastore browser in vSphere/vCenter, and started downloading the big VMDK file (this then downloads the small descriptor file first, allowing me to cancel the big download of the flat .vmdk).
I found that the geometry of the hard disk was different across the 2 descriptor files, when they should be exactly the same.
The working VM had these entries (other entries removed)
-------------------------------------------------------------------------------
ddb.geometry.sectors = "32"
ddb.geometry.cylinders = "8716"
The non-working VM had these conflicting values
------------------------------------------------------------------
ddb.geometry.sectors = "63"
ddb.geometry.cylinders = "4323"
So I decided to edit the descriptor file for the non-working VM and change both the sectors and cylinders values to be the same as the working VM. I uploaded the file back using the datastor browser. The VM then booted fine :) :)
My guess is that the virtual could not boot originally because the geometry was incorrect and could not find the boot sector location. It's strange though because if I use the descriptor generator available on-line ( http://forums.phdvirtual.com/wrapgen/) and put in the correct size of the -flat VMDK then it gives me the values which do not work......
I can only think that the original P2V conversion did something strange with the geometry of the VMDK file, maybe it's because the original physical servers had 2 physical ~34GB disks in a RAID1 configuration and perhaps the offline cold boot convertor made the geometry consistent with 2x34Gb disks ? Which would seem to roughly match the geometry settings that actually work.
If I clone the working VM in VCenter, then the clone will boot OK with no problems, presumably because the descriptor gets properly copied across as part of the clone process...
It would appear that Vrange 4.5.0 (i've also tried 4.5.3 and it has same issue), only generates the descriptor header file based on the size of the VMDK flat after it's restored.. I would sugges that VRanger actually takes a look at the original descriptor file, reads the geometry parameters/values and makes sure that when it gets restored the same geometry gets written back as well.
Hopefully this will help others, and any advice from other people on this would be most helpful.
Thanks,
Simon.