Bad Hardware Virtualization Detection -> fixed in SVN

[Shinkan]

My CPU is a Intel Core 2 Duo P7350.
Some models handle VT-x, others don't, but it is officially supposed to NOT have VT-x capability.

VirtualBox greys out Hardware Acceleration check box in GUI, but the option is checked by default, so I can not uncheck it. This cause some guests type (like OpenBSD) to complain about checked Hardware Acceleration that is in fact not available, asking for BIOS activation of it. My BIOS doesn't have this option, and my CPU do not have VT-x support.

Host is Windows 7 64bits, but I had the same issue with Windows 7 32 bits and Windows Vista 32 bits. VirtualBox is 3.1.2 but I have the same issue since at least 3.0.

[Sander van Leeuwen]

Yes, that's typically the point of greyed out options. OpenBSD support requires VT-x/AMD-V, so if you have neither, you're out of luck.

[Shinkan]

I don't agree with "Invalid" status.
I DO KNOW that my CPU is NOT VT-x, but VirtualBOx PRETENDS it is VT-x by checking GUI option and avoiding option change, and then COMPLAINS about invalid option on some guest install (like OpenBSD), requesting user to look at his BIOS.

That's not a normal behavior ; I don't want a software to decide for me then yelling at me because I made the wrong choice !!

[Technologov]

sandervl73: What is he trying to say, is that VT-x option in the Qt GUI must be unchecked when grayed out. I have a similar problem on one of my hosts.

Currently it is grayed out, but the checkbox is checked.

Component must be GUI. This is not a VMM bug, but a minor GUI bug.

-Technologov

[Technologov]

vbox-gui-acceleration-bug.PNG screenshot

[Technologov]

Added screenshot.

[Shinkan]

I'm not sure this is a PURE GUI bug. Creating VM with VBoxManage puts "hwvirtex" on by default, even though I DON'T HAVE hardware accel.

C:\Program Files\Sun\VirtualBox>VBoxManage.exe createvm --name test --register
VirtualBox Command Line Management Interface Version 3.1.2
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Virtual machine 'test' is created and registered.
UUID: 685f0ffb-e698-4795-b43a-ca6a620be791
Settings file: 'C:\Users\Shinkan\.VirtualBox\Machines\test\test.xml'

C:\Program Files\Sun\VirtualBox>VBoxManage showvminfo test
VirtualBox Command Line Management Interface Version 3.1.2
(C) 2005-2009 Sun Microsystems, Inc.
All rights reserved.

Name:            test
Guest OS:        Other/Unknown
UUID:            685f0ffb-e698-4795-b43a-ca6a620be791
Config file:     C:\Users\Shinkan\.VirtualBox\Machines\test\test.xml
Hardware UUID:   685f0ffb-e698-4795-b43a-ca6a620be791
Memory size:     128MB
VRAM size:       8MB
Number of CPUs:  1
Synthetic Cpu:   off
CPUID overrides: None
Boot menu mode:  message and menu
Boot Device (1): Floppy
Boot Device (2): DVD
Boot Device (3): HardDisk
Boot Device (4): Not Assigned
ACPI:            on
IOAPIC:          off
PAE:             on
Time offset:     0 ms
Hardw. virt.ext: on
Hardw. virt.ext exclusive: off
Nested Paging:   off
VT-x VPID:       off

We could assume that same strange behavior will occur with guests that need hardware accel, or those which pretend to (like OpenBSD) : "Hardware accel is set, but you moron did not activate it in the BIOS, and I really need hardware accel on this case".

[Sander van Leeuwen]

If you don't get a grip on yourself, I'll delete this ticket. We do not accept such kind of behaviour here.

It is not possible for us to determine if a given (Intel) CPU really has VT-x support or not. We're not going to keep track of a database of models and revisions of CPUs that support it. If you don't like Intel's policy of semi-randomly enabling and disabling this feature in specific models and revisions, I suggest you go and complain to them.

VT-x/AMD-V is turned on by default regardless of whether your CPU supports it. If it's not detected when starting a VM, we'll fall back to software virtualization. If a specific guest OS requires VT-x, then we refuse to run it if VT-x is not available. End of story.

You can work around this by selecting a different guest OS type, but such attempts are completely unsupported and you shouldn't complain if it doesn't work.

[Technologov]

sander: I disagree that you can't know if a given (Intel) CPU really has VT-x support or not.

Look at screenshot. You clearly see that the checkbox is grayed out. This means that the VBox GUI *knows* for sure that this Host is non-VT capable.

On such (non-VT) Hosts, the SMP slider in the GUI is grayed out.

What is needed: is to make the checkbox "grayed out + disabled", while currently it is "grayed out + enabled". See attached screenshot.

-Technologov

[Sander van Leeuwen]

Sigh. No, please give this a bit more thought. If cpuid.vmx is 0, it doesn't mean that the cpu doesn't support VT-x. It might simply mean it's disabled in the BIOS.

Or perhaps your system just went into suspend mode and the buggy BIOS didn't turn it back on properly during resume. (seen this many times too)

In conclusion: you can't really know if it's working/enabled until you actually try. So we assume it's there and use the fallback if for whatever reason we were unable to turn it on when starting the VM.

[Shinkan]

Replying to sandervl73:

If you don't get a grip on yourself, I'll delete this ticket. We do not accept such kind of behaviour here.

I'm not trying to have any kind of bad behavior, I was just describing a bug I had for many versions. I think that it's all that bug place is about. Shame on me about being cynical on my last post. Maybe that's what made you feel nervous.

Replying to sandervl73:

VT-x/AMD-V is turned on by default regardless of whether your CPU supports it. If it's not detected when starting a VM, we'll fall back to software virtualization. If a specific guest OS requires VT-x, then we refuse to run it if VT-x is not available. End of story.

The fact is that even by knowing for sure that a CPU/BIOS doesn't support VT, we can NOT disable it, exposing to strange behaviors next, including a message asking user to enable VT on his BIOS (which have no sense because either CPU and BIOS are not VT capable in my case). Moreover, the pointed message told that QNX & OS/2 needed VT, and I was trying to setup OpenBSD (with correct OS type set).

Feel free to leave the bug invalid or closed. I made my ways since this bug appeared first, and that's not blocking me. In understand the initial design decision is not bad at all. I just wanted to signal it.

[Technologov]

For non-VT capable hosts, the GUI is very confusing for newbies... both the "SMP slider" section and this "grayed-out, but enabled" checkbox.

I would recommend to change this:

Both "SMP slider" and this "grayed-out, but enabled" GUI checkbox should at least have a mouse roll-over tooltips explaining why it is grayed out...

The GUI must be self-explanatory for all hosts.

Maybe mark this as feature-request, if you wish...

-Technologov

[Sander van Leeuwen]

OpenBSD currently requires VT-x or AMD-V. Whether or not VT-x is enabled in the VM settings does not change the error condition.

What I can do is to change the error message in your case.

[Technologov]

What I ask is: to unmark (unselect) the check in the grayed checkbox on non-VT systems, at least for new VMs. (see screenshot)

Think about a newbie user:

For example, he has an old Dual-Pentium III system, he installs VBox 3.1.x, creates new VM, and the "hardware virtualization" checkbox is enabled. So he thinks that his system supports it, which is a *wrong* conclusion based on the GUI.

Why does it exist in the first place ? (I mean the grayed checkbox in enabled state, as in my screenshot)

Furthermore: since he has Dual CPU system, he naturally expects SMP to work on VMs, and he has no clue why is it grayed out. That is why I recommend introducing mouse roll-over tooltips for such cases, or change the description of GUI SMP slider from "Controls the number of virtual CPUs in virtual machine" ---> "Controls the number of virtual CPUs in virtual machine. This feature requires hardware virtualization."

-Technologov

[Perry G]

I don't know what all the fuss is about. I had this error when the VT-x/AMD-v was first set to enabled and then on auto-detect it was negated. I had an OS that was really ticked off and I edited the machine.xml and turned it to false. Situation solved. I did not have another problem with that particular OS. (I think it was OpenBSD but it has been so long I can't promise that). It has only happened once that I can remember in 2 years.

[Sander van Leeuwen]

Changed the error message in case it's certain VT-x and AMD-V are not available. Will be present in the next major version only.