Workstation 6.5.3 does not handle Host CPU change?

[BB202]

>>> Does moving a VM from a host with non VT-x CPU to a host with VT-x CPU require a special proceedure? <<<

I've had a Windows XP machine living happily on my Linux Host:

Guest: Windows XP, SP3, all updates current, 1GB RAM, 50 GB disk. Host: Ubuntu 8, current, 1.6 Ghz Intel chip, 2GB RAM, 120 GB disk; on an IBM thinkpad T41 2379-DJU. VM Software: VMware Workstation 6.0.4 build-93057 (created the guest and ran it)

For attempted move to new host VMware Workstation was loaded on new host and entire guest folder transferred by network the . New

attempted configuration:

New Host: Windows XP, SP3, fresh install all updates current, 3GB RAM, 100 GB disk, 2Ghz Intel dual core; on an IBM thinkpad T60 2007-76U. VM Software: VMware Workstation 6.5.3 build-185404

The Problem: Guest suffers BSOD and can only run in safe mode. Stop

code: 0x0000007e (0xc0000005, 0x00000000, 0xf79c50c0, 0xf79c4dbc) No

other technical information. On first boot into safe mode, guest discovers new hardware (the CPU) and installs Intel's intelppm (driver for CPU which is usually disabled in VM configuration). System event log also shows FIPS driver failed to load - event id 7026. All else is clear. To test out the possible issue of FIPS failure on

system boot, the FIPS driver was disabled through the registry on the old

host. The driver failed to load and produced the same event log entry,

but the VM booted fine - no blue screen on the old host even with FIPS

failure. On the new host, the VM can only run in safe mode.

I also tried using Workstation to clone the VM and moving the clone to

the new host. Also tried using Workstation on the old host to export the VM to the new location on the new host. Workstation on the new host takes ownership of the clone, but same result - a

blue screen. On noticing moved/copied system both player and workstation ask if VM is copied or moved - following both options produces same result, a BSOD on guest.

The guest runs fine in

either player or workstation on the old host, no events. Can anyone suggest a work around? Is there a way to force Workstation to understand that the CPU has changed and handle the guest looking for the old CPU?

-- Brendon

[KevinG]

If you move the VM from one system to another it should work if you do not have snapshots and/or and do not have the VM suspended.

[BB202]

I agree, but it does not in the configuration discribed above. The VM is shut down. There are no snapshots. Has anyone run into this CPU issue?

[KevinG]

I move VM's around from machine to machine here at VMware.

If you moved a virtual machine and it does not have snapshots or is suspended, I would look at possible corruption during the copy process.

Please explain exactly how you copied the VM (ftp...etc)

If it were a Linux guest, it could be an issue with an optimized kernel installed for a particular CPU, but since in your case it is Windows, this is not an issue

[BB202]

1) The two systems are on the same network. On the new host (T60), I created a new folder and enabled sharing. Full permissions.

2) Powered down the VM by asking guest OS to shut down. It did.

3A) On the old host (T41), I mounted the shared folder. Copied and pasted the entire folder for the Guest VM. An hour and a half later ... all files copied to new location. All looked fine, no errors reported. Moved all contents to unshared location. Result - as reported above.

3B) Figuring that I must be making a stupid mistake on the file copy and not moving some hidden setting or file, I decided to try a second route ... let Workstation export the VM for me. On the T41, using workstation, exported the VM directly to the share folder. The export process took considerably longer, but finished without reporting any errors. On attempting to run the guest VM ... exact same result as 2A.

[KevinG]

If the VM had a snapshot or was suspend then there would be CPU instructions stored in files and you could have an issue with unlike CPUs.

Since you confirmed that the VM did not have snapshots or was suspend, it is possible that the guest OS is looking for some external device that does not exist on the new system

Did you have any special device that were being used on the original VM?

This is an Window error code and not a VM error code.

Did you try running msconfig to turn off any applications and services at startup to help track down the issue?

[BB202]

There are no snapshots. Confirmed by looking in snapshot manager. I always do an orderly shutdown of the VM ... silly pre NT habit actually - I think regular shutdowns are good for Windows. Not that it matters, but the guest VM event log is clear.

The two hosts are substancially the same (IBM T41 vs. IBM T60), the VM is not allocated any special devices. Though the T41 is currently attached to external display - the VM is none the wiser.

The main hardware difference is the CPU. Pentium M 1.6 GHz in the T41, versus the Intel T2500 2 GHz dual core in the T60 - which has the "Intel Virtualization Technology". I have not dug in to the tech details of it yet.

My only clues to the problem are the pop-ups and event logs from the guest OS. In booting in safe mode, it discovers new hardware, and installs intelppm.sys - the driver for the intel processor. Intelppm.sys fails on subsequent boots. I can get rid of event by issuing "sc config intelppm start= disabled" to the guest, but it does not help. The other event is FIPS, which I ruled out as discribed above.

I did try to reload the VMware tools, but it can not be done in safe mode because the old installation can not be de-installed i safe mode - catch-22.

[BB202]

Oh ... the new host (T60) system event log is clear. Nothing there ... there is a warning for VMnetDHCP ... event 1 - timeout waiting for data.

Based on your suggestion, I will set the VM for diagnostic startup and shut it down, then copy the VM directory to see if that makes a differrence - it will load only basic services that way. But the 0x0000007E error is a bit more primal than that. It's worth a shot.

Copying over the files should take an hour, and I must first delete the VM files that I already copied over (not enough room on disk to keep both). If you have any suggestions to try with existing ported copy ... speak now ...

[BB202]

Boot attempt of VM shut down and set to boot in diagnostic mode failed with same result as before 0X0000007E stop code.

Also tried toggling the T60 bios setting relative to virtual machine managment - it was initially disabled, enabling it did not change results.