Table of Contents
Linux Guest Installation Hints
- This needs more testing, but it seems as if using the “VMSVGA” graphics controller and leaving “3D Acceleration” off you get the best results. Maxing out video memory to 128MB is a good idea though.
- “Nested VT-x/AMD-x” is needed only if you want to run another hypervisor inside the VirtualBox guest apparently
- UEFI can be enabled for the VM on installation, but there might be no benefits from it.
- The Host I/O caching for storage controllers can be very resource intensive on the host the documentation says.
- For networking “virtio-net” seems best and fastest type of adapter for Linux guests (Windows would need extra drivers).
| Settings Group | Setting | Value |
|---|---|---|
| Motherboard | Base Memory | depends 😉 |
| Motherboard | Chipset | PIIX3 |
| Motherboard | TPM Version | None |
| Motherboard | I/O APIC | On |
| Motherboard | Hardware Clock in UTC | On |
| Motherboard | UEFI | On |
| Motherboard | Secure Boot | Off |
| Processor | Number of CPUs | depends 😉 |
| Processor | Nested VT-x/AMD-V | Off |
| Acceleration | Paravirtualization Interface | Default |
| Acceleration | Hardware Virtualization | Nested Paging |
| Screen | Video Memory | 128MB |
| Screen | Graphics Controller | VMSVGA |
| Screen | 3D Acceleration | Off (might be able to turn on after installation?) |
| Storage | Host I/O Cache | Off (can apparently impact the host a lot) |
| Network | Adapter Type | virtio-net |
Guest Additions on Fedora Linux
Installation:
- Install build requirements via
dnf install gcc make perl kernel-headers kernel-devel bzip2 tar - Reboot just to be safe
- Mount the guest additions image
- Execute the autorun file from the guest additions image
- Reboot
Known issues so far:
- Apparently copy and paste of files from a Windows host to a Linux guest does not work, but it does the other way around. A global shared folder for all VMs could be a workaround for this issue.
- Shared folders need to have their permissions set manually inside the guest, e.g. by adding your user to the group “vboxsf” via
usermod -aG vboxsf USERNAMEand rebooting (otherwise the system seems to forget the group membership) - Somehow (only did a quick test) using /home/USERNAME/ for all shared folders seems to work best (maybe that’s a Fedora security thing, but that’s just a guess)
- Might have to build kernel packages for guest additions everytime a new kernel is installed – unless dkms or something might work like back in the day?
Green Turtle Troubleshooting
ChetB made the following post on the VirtualBox forums and it seems to work! Thx for writing this up! I am putting it here for reference so it does not get lost:
Guest Machines all have green turtle on Windows 11 Host
Post by ChetB » 30. Jan 2025, 19:56
I have had the same problem that a lot of others have had after upgrading their Windows 10 Host machine to Windows 11. All the guest machines were running slow and had the green turtle on the virtual machine status bar instead of the “V” indicating that virtualization was running. I read and tried all the following and non of them fixed the problem and Windows Hyper-V continued to start up after a reboot.
viewtopic.php?p=539641#p539641
viewtopic.php?f=25&t=99390
viewtopic.php?p=528455#p528455
viewtopic.php?f=1&t=62339
I finally ran across the following post for Vmware on how to disable Hyper-V on Windows 11 Pro and after following Step 3 it fixed the problem and is actually a Microsoft issued script. FYI, I executed all 3 steps and it wasn’t until I ran step 3 did Hyper-V stop loading. I hope this helps others. I can’t post the link because it references an external domain which is not allowed, so here are the 3 Steps/Phases. If anyone needs the URL’s let me know and I will get them to you via a private message.
Phase 1:
1. In Start menu search for “core isolation” to find the Core isolation page in Settings app. Turn off the Memory integrity protection, which will also disable the Kernel-mode Hardware-enforced Stack Protection. If Windows wants to restart, tell it “not yet” because there’re some features to turn off, first.
2. In Start menu search for “windows features” to find and open the Windows Features control panel. Turn off Hyper-V and all its subfeatures, and also Windows Hypervisor Platform, Virtual Machine Platform, and Windows Sandbox. The OS should ask to restart, let it.
Some people seem to succeed by doing just that. Check System Information. Is the VBS feature no longer in running stated? If not, let’s try Phase 2, which throws several more kitchen sinks at the problem.
Phase 2:
1. In Start menu search for “command” to find Command Prompt, right-click it, and run as administrator (elevated). It has to be elevated, otherwise the command you’re about to type/paste won’t work.
2. Run command
bcdedit /set hypervisorlaunchtype off
3. Close the command prompt window
4. Hit Win+R to get the Run dialog, and run:
regedit
5. After a UAC/elevation prompt, the Registry Editor opens. Right below the menu bar there’s a texbox where you can paste this path and hit Enter:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard
6. The tree view below the textbox (on the left) should have taken you to the path you pasted, and the values in this registry node should be shown in the right pane. Find the value named “EnableVirtualizationBasedSecurity”, double-click it to edit the value, and in the dialog box that appears type 0 in the “Value data” field, unless of course that’s already the value that’s set. Hit OK to save the change and close the Registry Editor.
7. Hit Win+R again to get the Run dialog, and run:
gpedit.msc
8. The Local Group Policy Editor should open. There’s no convenient textbox to paste a path into, so you’ll have to painfully expand nodes to find this path:
Computer Configuration → Administrative Templates → System → Device Guard
9. Find and double-click a setting in the right pane named “Turn On Virtualization Based Security”, and in the dialog that appears, select the “Disabled” radio button, then OK button, and close the Local Group Policy Editor.
10. Restart the OS and again check System Information to see if the VBS value has become “disabled.”
Still not there? That’s what happened to me, but there’s one more thing to do, luckily assisted by a tool (script) provided by Microsoft, which in my experience finally takes that last step toward the nirvana of seeing the “disabled” value for VBS:
Phase 3:
There is a manual way to do this, and I found the instructions, but they’re a bit scary. It involves using bcdedit to modify the boot configuration to apply a configuration change that sets a “DISABLE-LSA-ISO” option. Lots of opportunity for something to go wrong if the instructions I found are flawed, or if a mistake is made (typo, missed a command). So, I’m strongly recommending (and providing instructions for) the method that uses the Microsoft-provided script. I’ve tested it, it worked for me, and the same script provides a way to undo the whole thing later if desired, too. Power users are welcome to find the instructions I found on their own, or to simply open the script file and examine what it does for any manual implementation activities.
1. Do a Google search for the following “Download Device Guard and Credential Guard hardware readiness tool” and select the link for the Microsoft site. This tool is provided by Microsoft to check Device Guard and Credential Guard capability, and to turn on/off the features. There’s no setting anywhere in Settings app or control panel for this, and this “tool” is actually a PowerShell script, but it provides the necessary functionality. Find the Download button and click it, and your browser will download a ZIP archive.
2. Find and extract the folder contained in the archive. Don’t try to run the script from within the archive. If you’re using Windows Explorer, it can make a ZIP archive look like just another folder, but it isn’t. You need to drag out the “dgreadiness_v3.6” (version as of when I wrote this post) folder from the archive into a real folder, e.g. onto your Desktop.
3. Search for “powershell” in Start menu to find Windows PowerShell, right-click it, and run as administrator (elevated). You must run it elevated or the script won’t work.
4. You need to change the current drive and directory to the one where the script is. If you’re not command prompt savvy: type “C:” for example (no quotes) if the folder is on the C: drive, or “D:” if it’s on the drive, etc., and hit Enter, which should change the active drive to the correct one; next, open the folder you extracted the script files into, copy the address from the address bar into the clipboard (highlight and Ctrl-C), then type the following command (replacing <path> with a Ctrl-V to paste the path you just copied), and hit Enter:
cd “<path>”
5. The prompt in front of your blinking cursor should now match the folder where the script file is located, meaning your “current directory” is the correct one.
6. Unless you know that you’ve already set this policy (power user), run this command next, to allow the script to be run:
Set-ExecutionPolicy Unrestricted
7. You’ll have to respond to a security prompt by typing “y” (if I remember correctly), possibly followed by Enter. It should then say it has successfully changed the execution policy.
8. Now we can run the script. Type/paste (if the version number has changed since I posted this, adjust according to the filename of the .ps1 script file in the extracted folder):
DG_Readiness_Tool_v3.6.ps1 -Disable
9. The script will do some stuff, and then you’ll get to restart, and during restart you will get a full-screen prompt asking you to confirm you want to opt out of Device Guard and Credential Guard. Answer in the affirmative. I don’t have precise instructions for the exact sequence of events and prompts/actions after running the script, because I ran it several days ago and didn’t document what I saw.
10. Once Windows has restarted with these features “opted out of,” fire up System Information and check that VBS value again. For me, this was the final step that did the job, and when I ran a VMWare Workstation VM, it gave me the coveted Monitor Mode value of “CPL0”!
11. By the way, for the sake of security, you might want to change the PowerShell script execution policy back to the more restrictive default one after these steps. If so, launch Windows PowerShell again, as administrator, and execute:
Set-ExecutionPolicy Default