Acceleration tab is greyed out in Virtual Box 4.2.10

[Shubh]

Hello,

I have a host OS win7 64 bit. and have installed Vbox 4.2.10 to run a 64 bit ubuntu. However I am not able to run the OS. Showing the Error “This kernel requires an X86-64 CPU but only detected an i686 CPU – unable to boot please use a kernel appropriate for your CPU”. After googling this error, i have enable the Intel VT from the BIOS settings and had a cold boot. Then also it's same problem. Then was trying to enable the virtualization setting from the accelaration tab. to make it effective. but This Acceleration tab is greyed out there. Please help me : How to make the acceleration tab on? or is there could be some other issue related to this problem??

Thanks
Shubh

[mpack]

In order to run a 64bit guest the following is required :-

1. You must have a 64bit CPU.
2. That CPU must support VT-x or AMD-v (hardware support for virtualization).
3. No other software can be already running and using VT-x (common offenders on Windows hosts include Hyper-v and VirtualPC / XPmode).
4. Setting the VT-x option in the VM settings is not actually required (VBox tries to use the feature regardless), but if you set this option then VBox will at least warn you with an error if the feature is not present, e.g. if you move hosts.

Also, the VM must be shut down (not running or suspended) before you can change important parts of the VM recipe.

If you need further help then please read Minimum information needed for assistance and provide the necessary diagnostic info.

[michaln]

Setting the VT-x option in the VM settings is not actually required (VBox tries to use the feature regardless)

Wrong. It's the other way around -- with the VT-x option enabled, a VM may still run when VT-x is not present/available. But if VT-x is disabled for a VM, it will never be used.

[mpack]

Strange - I've seen plenty of log files which seem to say the opposite: VT-x not enabled in VM settings, but detected and enabled in VM.

And VirtualBox would run without complaint despite the fact that a feature it was told to use was not available? Really?

[Ramshankar]

Strange - I've seen plenty of log files which seem to say the opposite: VT-x not enabled in VM settings, but detected and enabled in VM.

And VirtualBox would run without complaint despite the fact that a feature it was told to use was not available? Really?

Could you point us to such a log file?

[mpack]

Not offhand. You expect me to trawl the site looking for logfiles containing a feature I didn't regard as significant?

Perhaps I'm misinterpreting the logs - after all I'm not aware that you have ever documented the contents. Here for example :

00:00:01.651258 HwVirtExtForced <integer> = 0x0000000000000000 (0)

I've always interpreted the HwVirtExtForced flag as meaning the state of the VT-x checkbox. Is that not correct? If correct, you are saying I have never seen a log with that flag set to zero and still containing that load of HWACCM lines?

Edit:  Never mind. I just checked a 64bit Win7 VM of my own. It shows VT-x enabled in the VM settings, but HwVirtExtForced==0 and HWACCM stuff is all there - as of course it must be for the VM to run. So where does the VT-x flag appear in the log, and what does that HwVirtExtForced flag mean? @shubh: I'm acutely aware that this outbreak of pedantry is not very useful to you. Just disregard my erroneous point 4 - you must explicitly enable the VT-x checkbox.

[Ramshankar]

Not offhand. You expect me to trawl the site looking for logfiles containing a feature I didn't regard as significant?

The reason I asked for the log was to try find out what exactly you maybe misinterpreting.

Code: Select all

HWACCM: VMX enabled!
...
HWACCM:    VT-x/AMD-V init method: LOCAL
...
Changing the VM state from 'CREATING' to 'CREATED'.

Is usually what indicates that VT-x is being enabled and will be used for the VM.

If hardware virtualization is not available for some reason, you probably would see something like:

Code: Select all

HWACCM: No VT-x or AMD-V CPU extension found. Reason ...

The HWACCM/HM lines after the CFGM tree is more useful (in this context) as to what features ultimately got enabled and are in use than the various CFGM settings. There are instances when the VM may fallback to software virtualization (depending on where the VT-x/AMD-V setup fails) though that would be logged as well and perhaps only happens in very rare cases where the setup code fails.

[mpack]

I was already aware (in fact I mentioned it in my previous message) that the HWACCM lines in the log indicate VT-x usage. The question however was not whether it was used, but how to tell from the log file whether it had been configured in the VM settings, and whether that is actually necessary. Hence my question about the HwVirtExtForced line which I had mistakenly assumed equated to the VT-x selection.

I see the latter field =1 or =0 in various logs, so it isn't just an unused stub, it's being set by something, and the naming seems to imply a VT-x connection. Also I have logs here on my own PC that show it set =0 while a bunch of HWACCM lines show VT-x being enabled. So, =1 seems not to be a requirement for the VM to use HWACCM. Hence my earlier comments.

[Ramshankar]

There isn't a direct line in the log that indicates whether the option was enabled or not (upto VirtualBox 4.2.x). The usage HWACCM lines are the definite indicator that hardware virtualization was enabled. The forced setting implies there will be no falling back to raw-mode. I didn't check yet but it could be the 64-bit guest OS type *might* be setting it, as we cannot fallback to raw-mode.

[mpack]

Ok, so the HwVirtExtForced line means that I chose a 64bit template during VM creation, hence lack of VT-x should be regarded as an error (no silent fallback). Makes sense thanks.