Host: Intel DG31PR board; q8400 processor. VT enabled in Bios. XP SP3.
Create virtual machine for an os/2 guest. When I try to power it on, I get this message:
OS/2 is not supported with software virtualization. To run OS/2, you need a CPU that supports hardware virtualization.
In VMWARE log I find this:
Jan 06 17:19:32.703: vmx| MONITOR MODE: allowed modes : BT
Jan 06 17:19:32.703: vmx| MONITOR MODE: user requested modes : BT HV HWMMU
Jan 06 17:19:32.703: vmx| MONITOR MODE: guestOS preferred modes: HWMMU HV BT
Jan 06 17:19:32.703: vmx| MONITOR MODE: filtered list : BT
Jan 06 17:19:32.703: vmx| Msg_Post: Warning
Jan 06 17:19:32.703: vmx| [msg.cpuid.os2WithBT] OS/2 is not supported with software virtualization. To run OS/2 you need a CPU that supports hardware virtualization.
Jan 06 17:19:32.703: vmx| ----------------------------------------
Jan 06 17:19:32.750: vmx| Module MonitorMode power on failed.
What am I doing wrong? Pse be gentle, I'm a relative beginner with VMWare although I've been involved in mainframe virtualization for many years.
tnx
How did you configure the VM? Which guest OS did you select?
Please attach the vmx file, maybe there's something that needs to be modified.
Did you enable VT just now or was it enabled before? If you enabled it just now, make sure you power cycle the PC. A reboot after the change is not sufficient!
André
André Pett wrote:
How did you configure the VM? Which guest OS did you select?
Please attach the vmx file, maybe there's something that needs to be modified.
Did you enable VT just now or was it enabled before? If you enabled it just now, make sure you power cycle the PC. A reboot after the change is not sufficient!
André
Guest OS was OS/2 "experimental". vmx attached.
VT was enabled a week ago, several boots gone by.
To see whether the issue is related to the host or the VM itself, please create a 64-bit VM and try to start it. Does it start or do you get an error message? What do you see in the vmware.log regarding "MONITOR MODE" (like in your first post)?
André
the attached vmx has
guestOS "other"
not
guestOS = "os2"
or
guestOS = "os2experimental"
as we would expect reading your post.
?
Oops - wrong vmx file. That one would power on, but couldn't get a console to work (that's in another thread:-(
Here's the one for the machine that won't power on (which was named 'Virtual Machine'; I forgot to change the name):
.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "7"
floppy0.present = "TRUE"
mks.enable3d = "TRUE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
nvram = "Virtual Machine.nvram"
virtualHW.productCompatibility = "hosted"
ft.secondary0.enabled = "TRUE"
tools.upgrade.policy = "useGlobal"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "OS2-rit-vm"
extendedConfigFile = "Virtual Machine.vmxf"
memsize = "1024"
ide0:0.present = "TRUE"
ide0:0.fileName = "Virtual Machine.vmdk"
ide0:0.writeThrough = "TRUE"
ide1:0.present = "TRUE"
ide1:0.fileName = "S:"
ide1:0.deviceType = "atapi-cdrom"
ide1:0.allowGuestConnectionControl = "FALSE"
floppy0.allowGuestConnectionControl = "FALSE"
floppy0.fileType = "file"
floppy0.fileName = "d:\Virtual Machines\ecs-rit.flp"
floppy0.clientDevice = "FALSE"
ethernet0.present = "TRUE"
ethernet0.allowGuestConnectionControl = "FALSE"
ethernet0.features = "1"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.networkName = "Bridged"
ethernet0.addressType = "generated"
guestOS = "os2"
uuid.location = "56 4d 25 2d 05 3e 9d 18-85 e2 3d b8 83 0d 85 9d"
uuid.bios = "56 4d 25 2d 05 3e 9d 18-85 e2 3d b8 83 0d 85 9d"
vc.uuid = "52 ed ce 26 67 20 5c 3f-d5 dd 77 f6 92 86 4e 63"
tools.syncTime = "TRUE"
guestOSAltName = "os2"
bios.forceSetupOnce = "TRUE"
Did you test the 64 bit VM yet? (see my previous post)
André
André Pett wrote:
To see whether the issue is related to the host or the VM itself, please create a 64-bit VM and try to start it. Does it start or do you get an error message? What do you see in the vmware.log regarding "MONITOR MODE" (like in your first post)?
André
created a 'other os, 64 bit' VM. It powers on OK; I don't get an error message until I try to access the console (that's another problem topic and another thread).
from the log:
Jan 07 11:15:14.421: vmx| MONITOR MODE: allowed modes : BT
Jan 07 11:15:14.421: vmx| MONITOR MODE: user requested modes : BT HV HWMMU
Jan 07 11:15:14.421: vmx| MONITOR MODE: guestOS preferred modes: HWMMU BT HV
Jan 07 11:15:14.421: vmx| MONITOR MODE: filtered list : BT
Jan 07 11:15:14.421: vmx| HV Settings: virtual exec = 'software'; virtual mmu = 'software'
I'm still confused about the missing "HV" in "allowed modes". Please run the CPU compatibility tool. For details see http://kb.vmware.com/kb/1003944
André
From what I just read in http://www.vmware.com/pdf/vmserver2.pdf it appears that your CPU might not be supported. see page 24
André
Here's CPU ID tool output
NX/XD yes
CMPXCHG16B no
RTDSCP no
64 BIT LONG MODE yes
64 BIT VMWARE no
SUPPORTED EVC MODES none
I'm not trying to run a 64bit OS.
I'm following issue.
I'm not trying to run a 64bit OS
That's correct, however as you can see in the log
OS/2 is not supported with software virtualization. To run OS/2 you need a CPU that supports hardware virtualization
So this seems to be a requirement for OS/2. You may try to set the OS in the VM's settings to "other" and see what happens.
André
André Pett wrote:
OS/2 is not supported with software virtualization. To run OS/2 you need a CPU that supports hardware virtualizationSo this seems to be a requirement for OS/2. You may try to set the OS in the VM's settings to "other" and see what happens.
André
I was taken in by the fact that the Q8400 has VT support - apparently that's not enough to support hardware virtualization.
I have tried setting the OS to "other" and it will in fact power on. However, this then fetches up against my other problem - see http://communities.vmware.com/thread/298164 - I can't get the console to open.
jt335577 wrote:
I was taken in by the fact that the Q8400 has VT support - apparently that's not enough to support hardware virtualization.
Hardware virtualization is supported on the Q8400. However, it sounds like your CPU is reporting that it does not have VT support. This sounds like Intel erratum AV69, which does affect the Q8400. This erratum can be fixed with a microcode update. Check with your system vendor to see if there is a BIOS update available which may contain the necessary microcode update.
Jim Mattson wrote:
jt335577 wrote:
I was taken in by the fact that the Q8400 has VT support - apparently that's not enough to support hardware virtualization.
Hardware virtualization is supported on the Q8400. However, it sounds like your CPU is reporting that it does not have VT support. This sounds like Intel erratum AV69, which does affect the Q8400. This erratum can be fixed with a microcode update. Check with your system vendor to see if there is a BIOS update available which may contain the necessary microcode update.
Sigh. Intel motherboard DG31PR with the latest BIOS. I guess I'll have to take this one to Intel.
Thanks.
If you post your complete vmware.log file, I can take a look to see if this is erratum AV69.
Your log file shows the following information for CPUID leaf 1:
CPUID[0] level 00000001, 0: 0x0001067a 0x00040800 0x00000301 0xbfebfbff
The problem is that the third field (ecx) reports an extremely limited set of features:
0x00000301 decodes as only SSE3, TM2 and SSSE3. It does not include VT (VMX) support, which would be bit 5.
For this processor, the third field should read something like 0x000ce3bd.
This is exactly the symptom one would expect from erratum AV69.
From Intel's processor specification update:
AV69. Enabling PECI via the PECI_CTL MSR Does Not Enable PECI and May Corrupt the CPUID Feature Flags
Problem: Writing PECI_CTL MSR (Platform Environment Control Interface Control Register) will not update the PECI_CTL MSR (5A0H), instead it will write to the VMM Feature Flag Mask MSR (CPUID_FEATURE_MASK1, 478H).
Implication: Due to this erratum, PECI (Platform Environment Control Interface) will not be enabled as expected by the software. In addition, due to this erratum, processor features reported in ECX following execution of leaf 1 of CPUID (EAX=1) may be masked. Software utilizing CPUID leaf 1 to verify processor capabilities may not work as intended.
Workaround: It is possible for the BIOS to contain a workaround for this erratum. Do not initialize PECI before processor update is loaded. Also, load processor update as soon as possible after RESET as documented in the RS – Wolfdale Processor Family Bios Writers Guide, Section 14.8.3 Bootstrap Processor Initialization Requirements.
I got fed up and went to Intel on this one. One of their second level people finally gave me the suggestion that I should again flash the BIOS update, but use the method for full bios refresh, rather than the windows-based update process. I suspect that the microcode fix referred to in AV69 is in a part of the bios core that is not updated unless you do the full refresh.
At any rate, the VMWare cpu id tool gives me a good answer, and I am now able to power on the OS2 guest; unfortunately, I am still hung up on the console issue (my other topic in this community).