Generally such errors are not associated with SCSI issues (they could be other drivers). To narrow down the drivers that could be causing the issue, could you remove the virtual devices that are not required (like COM ports) and boot into "safe mode without networking". If this boots up fine, we can start adding devices to figure out which one was causing the problem.
thanks for the reply!
I have removed all unnecessary devices from the VM settings, but selecting Safe Mode (with or without networking) still causes the same issue - the server gets stuck on the "Starting Windows..." text screen.
I even installed the VMware SCSI controller driver into the source server, so it might find the correct driver after it was converted, but still the same result - no boot.
any other suggestions please?!
You could try changing the controller type. There are two types of SCSI controllers (Lsilogic and buslogic). What is the type right now? You can try to switch this (Edit settings, SCSI controller->Change type).
The only catch with this is that if you select the type to LsiLogic, you need to make sure that the source had Lsilogic driver installed. Hope this helps.
yes, I had already tried both the SCSI controller options, and both produce the same result - the VM stuck on the "Starting Windows..." screen.
In that case, it is less likely to be a disk driver issue. Can you attach the converter logs from conversion? They might shed some light. Also you mentioned that you could convert several other machines successfully. Could you recongnize some differences between the two (in terms of hardware and applications installed).
Many possibilities ...
- the converter logs (located on the source machine that was converted under c:\windows\temp\vmware-temp\)
- screenshot of diskmanagement from the source machine that was converted
- copy of the boot.ini file from the source machine that was converted
A test you can try to narrow possibilities down is to only convert the C:\ partition and see if that works.
We have had a tech from VMware with us all morning to investigate this, and he has been able to resolve it for us - the affected VM is now booting.
He thought it might be a HAL issue between the physical server and the VM, so after several tries, we took the HAL files (c:\winnt\system32\hal.dll and ntoskrnl.exe) from one of the other multiprocessor Win2000 VMs, and copied these files to the affected VM (using a Bart PE style boot CD .iso) after making a copy of the existing files of course!
This enabled the VM to boot.
So I just need to P2V the server using the VMware Converter again, and apply these files and we should be good!
It appears that the x440 server has a different multiprocessor HAL to other multiprocessor servers.
thanks to all above for their suggestions,
Did the HAL.dll and the ntoskrn.exe file taken from the same OS service pack or just any windows 2000 OS service pack will do?