virtualbox vt-x is disabled in the bios

[adldata]

I am a beginner IT student (read - as in first week of IT course). As one of my subjects I am to install Virtual Box version 4.18 (nothing earlier, nothing later). Our school has sent as 2 vdi files. One for Ubuntu and one for WIndows 8 64 bit.

I have a PC running WIndows 7 64 bit.

I get the error about running the vt-x and having it enabled. This occurs only when I try to use Win8 VM. Ubuntu works fine.

I get 2 screens pop up. one about having the setting enabled (I do not have it endabled and I have no where in my bios to be able to change it). The 2nd screen talks of PC hardware issues in the Win 8 VM window.

All research to date refers to a known issue but not on the version I am using.

I do not know what Virtual Box is all about yet so asking me to explain my purpose for it is useless, I have just been told to install it, once installed our lecture notes will guide us through using it. My lecturer is not available to ask and I need to press on with my weekly labs and this is holding me up. Any help would be good.

For the record there is another thread on here relating to my issue (sorry I am not allowed to link it as I am a new member apparently) however it relates to a later version and thus the suggested --longmode feature discussed in that thread does not work. I have tried to run the latest version of Virtual Box but with the setup files my uni sent me, this fails to work.

[Ann]

Hello,

the Vt-x/AMD-V option is in BIOS ( for Lenovo CPU )

BIOS -----> advanced -----> CPU Setup -----> enable Intel Vt-x/AMD-V technology.

the above location may be change depends on CPU model ( Dell,Lenovo, etc.. ).

install windows 8 vdi on windows 8 host. it will definitely work. but you need 64 bit CPU and windows 8 64 bit host to install windows 8 64 bit guest.

Thank you

[mpack]

You should read the following topic: I have a 64bit host, but can't install 64bit guests.

Though the linked topic discusses 64bit guests, the actual problem is that VT-x/AMD-v needs to be enabled, which is also the case for all Win8 guests whether 32 or 64bit.


Incidentally, the prohibition on installing later versions of VirtualBox is rather stupid: the VBox version you are trying to use (*) predates the Win8 official release by quite a ways. How do you expect that version to support an OS that didn't exist?

Also, the "longmode" hack was precisely to allow older VBox versions to accept Win8 installations, so it does apply to you. Whether or not the workaround works, I can't tell you.

(*) There has never been a VBox version 4.18. The latest release is 4.3.x. I assume you meant 4.1.8.

[birchclass]

As the once-proud owner of a low-end Toshiba Satellite, I find myself needing to extend this question. Let me explain:

-- I am running Ubuntu as my host OS and want to run my old copy of Windows 8 on a VM. I keep getting virtualization-turned-off errors similar to those described in this thread.

-- Every post I've seen online about this virtualbox error basically say "turn on virtualization in the BIOS settings -- it's easy!"

-- The processor/motherboard on this machine are indeed designed to allow virtualization (in this case AMD-V), but Toshiba has actively turned this option off on the BIOS setup screen so users will pay for a "nicer" machine (resulting, I am somewhat satisfied to see, in a bunch of posts saying things like "this will be my last Toshiba ever.")

While it looks like there may be a hack to re-enable this -- google "Enabling Intel VT on the Aspire 8930G" to see a rather helpful post about how to do it on a different platform with similar InsydeH2O BIOS -- I would prefer to have a more formal, standardized solution endorsed by someone like Ubuntu or the VirtualBox dev team. I'm comfortable with bits and pieces of various programming languages, but I certainly don't know enough about low-level memory addressing on InsydeH2O BIOS to distinguish a command saying "do something great" from one saying "please unintentionally turn this laptop into an expensive brick."

So my question is twofold:

-- Is there an easy way in one or more common Linux flavors to make sure that the machine has EFI/UEFI enabled (in other words "is not in legacy mode")?

-- Is there a well-known tool along the lines of Grub or rEFInd that can handle turning virtualization on in a standardized way, so long as the tool has access to a EFI/UEFI setup? (It looks at a glance like dmidecode might be enough to get us part of the way there by reading BIOS values in a standardized way, but the writing part appears to be left to the user.)

If I understand the idea of EFI/UEFI standards correctly, the whole bloody point of that new set of standards was to abstract some of this junk away from hardware makers. So I'm finding it a bit frustrating that the only answers I can find online about this are kludgy workarounds that involve flipping unlabled memory addresses, as if we never left the bad old days. It seems like in 2014, there's gotta be a better way, and I'm hoping someone on here can show me what it is, or at least point me a bit farther in the right direction. Thanks for your time.

[michaln]

I would prefer to have a more formal, standardized solution endorsed by someone like Ubuntu or the VirtualBox dev team.

That's not going to happen, sorry. We really have no interest in debugging/hacking OEM hardware. We don't even have one of those systems.

If I understand the idea of EFI/UEFI standards correctly, the whole bloody point of that new set of standards was to abstract some of this junk away from hardware makers.

Not really. The primary motiviation was designing firmware that is 32-bit, optionally 64-bit, and not firmly tied to PCs. For the BIOS writers it was also a welcome opportunity to stop writing the whole thing in assembler.

It seems like in 2014, there's gotta be a better way, and I'm hoping someone on here can show me what it is, or at least point me a bit farther in the right direction.

Not really. For security reasons, Intel designed the VT-x enable/disable registers such that once they're written, they cannot be modified until the CPU is powered off and on again. In other word, unless the firmware is buggy, there's nothing anyone can do about it short of replacing the firmware. Neither Ubuntu nor Oracle will do that.

If unscrupulous OEMs want to abuse the VT-x design to permanently disable VT-x on systems that are perfectly capable of using it, I'm afraid that that's a matter between the OEM and its customers.

[birchclass]

Michain, thanks for the strong, piece-by-piece answer. Disheartening as the content is, It looks like you know what you're talking about, and I appreciate that you put a good bit of detail into your reply.