The problem - similar to other posters on this forum, after upgrading from VirtualBox 3.0.12 to 3.1.0 my two 64 bit Guest OS stopped working with the error: "VT-x/AMD-V hardware acceleration has been enabled, but it is not operational. Your 64-bit guest will fail to detect a 64 bit CPU and you will not be able to boot."

Both 64 bit guest OS had been working just fine under VBox 3.0.12. One thing to note is that immediately after the upgrade to VBox 3.1.0, I checked that all the guest OS worked, and they did. I then did a reboot of my entire system. When I again tried to open the 64 bit guest OS in VBox 3.1.0, I got the above mentioned error message. My 32 bit guest OS, WinXP, works fine in VBox 3.1.0.

Looking at the other posts on this topic I did the following:a) Followed the FAQ procedure to unset and reset the BIOS virtualization option - 64 bit guest OS still not functioningb) Issued a modprobe -r kvm_amd on the chance that I had that module running - 64 bit guest OS still not Functioning

I went back to VBox 3.0.12 (complete uninstall of 3.1.0 using Synaptic package manager and then reinstall of 3.0.12), and although VBox 3.1.0 made changes to the XML configuration files that left my 32 bit WinXP guest broken, the two 64 bit guest OS started working again. I repeated the upgrade to 3.1.0 and once again, the two 64 bit guests worked until I rebooted the entire system. I am puzzled by this behaviour.

Yeah, I just went ahead and did what you suggested. I guess I'll go back to 3.0.12 for now so I can use my 64 bit VMs. Any tips on where I can find docs on the format, content and settings of the xml config files? They seem to have changed a fair bit between 3.0.12 and 3.1.0.

Actually AFAIK there is no easy way to rebuild these unless you look and see if there happened to be a .bak file of the machine.xml, and the virtualbox.xml.If you can find one of these you might be able to simply rename them to the xml. You would need to rename the machine.xml and the virtualbox.xml first of course.

An alternative would be (if you do not have snapshots) to simply unattach the VDI,s delete the machine and recreate them as new and the attach the VDI instead of creating a new one. You should make note of the settings first though.

Also be sure to back everything up first. Actually had you backed up the xml files you could have simply restored them to begin with after reverting to 3.0.12.

I had done the backup thing with the xml files but it was after the first failed attempt to upgrade to 3.1.0. However, it was pretty easy to get everything back, I just renamed the .VirtualBox folder in my home directory and let 3.0.12 create a new one. Then I created my three virtual machines as new ones and at the step where you set up the virtual hard disk I told it to use an existing file and then pointed it at the appropriate .vdi image, adjusted the video settings and a few other things and I was back up running with all three VMs faster than it has taken me to type this

I hope the devs can sort this out - it might be an AMD CPU <-> Gigabyte MB thing, but why did it only show up in VBox 3.1.0? Regression in the software maybe?

An update. The AMD-V (AMD virtualizaton hardware) in use issue seems to be related to the Gigabyte family of motherboards and AMD Phenom CPUs. The Bug filed in a previous post has the details of what has been found. Simply put, versions of VBox before 3.1.0 didn't do a very good check of the term that says whether or not the virtualization hardware is in use but 3.1.0 does so it sees an issue. In my case, I found a newer BIOS on Gigabyte's website and after installing it on my motherboard, version 3.1.0 now works OK with my 64 bit guests. Others may not be so lucky.