virtualbox.org

I'm running 6.0.14 on MacOS with plenty of memory and CPU. On a virtually load-less system, launching a VM instance takes a good long time to even get to the BIOS splash screen and then on to the OS boot screen.

The example I have in front of me is a Windows 10 guest with nothing special. Launching VB manager takes less than a second. Selecting my Win10 guest and pressing the "Go" button (it's "powered off") causes VB to take 100% of a single CPU for 38 seconds before the white-on-black "VirtualBox" splash screen is shown, then another 10 seconds or so showing the chasing-dots o that same screen before Windows startup screen shows. After that, the guest runs perfectly acceptably.

What is taking 38 seconds, here? I would expect that launching a VM would nearly instantly display the VB BIOS screen and only take maybe a second or so to initialize and move-on to the OS boot screen. At first, I thought the delay might be for pressing some hotkey like ESC or whatever to open-up the BIOS setup screen but that seems unlikely with a 100% CPU usage during that entire time interval.

I'm happy to post whatever configuration would be relevant. This is not a critical VM in any way -- just a Win10 VM for testing. I can adjust settings, re-create the VM, etc. if necessary for testing.

Some obviously related settings:
Host system: 2018 MacBook Pro, 2.6GHz i7, 32GiB memory; Intel graphics + Radeon Pro 560X, FileVault 2 enabled (whole-disk encryption)
No guest disk encryption
Type "Microsoft Windows"
64-bit Win10
4096 MiB configured guest memory
2 CPU, no execution cap
PAE/NX enabled
Paravirtualization interface: Default
Hardware virtualization: Nested paging enabled
No graphics acceleration enabled
Network: NAT
Serial/USB disabled

We need to see a complete VBox.log, from a complete VM run, where the problem occurs:

• Start the VM from cold-boot (not from a paused or saved state) / Observe or recreate the problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

I'm attaching the VBox.log from a cold launch -> wait for Win10 login screen -> power-off from Win10 login screen. There is a long gap where the VM looks like it's doing nothing besides trying to take a whole lot of screenshots, and failing. I'm not going anything with my keyboard during that time; screenshots seem like something that shouldn't be happening all that often.

Tailing the log file while the VM was starting, I could see that the instance's screen was black until about this point in time:

00:00:37.692006 ERROR [COM]: aRC=VBOX_E_VM_ERROR (0x80bb0003) aIID={ab4164db-c13e-4dab-842d-61ee3f0c1e87} aComponent={DisplayWrap} aText={Could not take a screenshot (VERR_NOT_SUPPORTED)}, preserve=false aResultDetail=-37
00:00:37.977150 AHCI#0: Reset the HBA
00:00:37.977176 VD#0: Cancelling all active requests
00:00:38.054484 Display::i_handleDisplayResize: uScreenId=0 pvVRAM=0000000117d04000 w=1024 h=768 bpp=32 cbLine=0x1000 flags=0x0 origin=0,0

At this time, the VB BIOS screen showed for a second or two and then the OS began to boot. Once the VB BIOS (or whatever it's called) screen shows, things move along as expected (i.e. quickly). Something it stalling before that point and then everything seems fine.

This issue seems to be limited to this particular VM. I have some Linux VMs that go right to the "VirtualBox 6.0 - Press F12 to enter Setup" screen, then after second or so start to boot the OS.

I can't quite remember, but this VM may have been one downloaded from modern.ie, rather than one created from scratch from within my VirtualBox install.

Comparing to my other VMs, this one says "Hyper-V Virtualization" and the others all say "KVM Virtualization". Actually, all my VMs have "Virtualization" set to "Default" so they aren't specifically set to those values.

I see some differences between this Win10 VM and the others that are behaving more like I expect:

• Win10: Enable EFI is checked, Chipset is "ICH9"
• All others: Enable EFI is disabled, Chipset is "PII3"

Disabling EFI for that VM causes a somewhat immediate "BOOT FAILURE: INT8".

Your guest template was set to Windows 10 64-bit:

00:00:01.029620 Guest OS type: 'Windows10_64'

There are a few things unusual about this Windows 10 guest:

00:00:01.109793 [/Devices/efi/] (level 2)

The default template chooses BIOS, through Windows 10 is supposed to be happy with EFI.

00:00:01.109815 [/Devices/ich9pci/] (level 2)

The default chipset, as you noted, is PIIX3, not the chosen ICH9.

Your guest is using the old VboxVGA video card, not the default VboxSVGA:

00:00:01.109892 [/Devices/vga/0/Config/] (level 4)
00:00:01.109893   3DEnabled        <integer> = 0x0000000000000000 (0)
00:00:01.109893   CustomVideoModes <integer> = 0x0000000000000000 (0)
00:00:01.109894   FadeIn           <integer> = 0x0000000000000001 (1)
00:00:01.109894   FadeOut          <integer> = 0x0000000000000001 (1)
00:00:01.109895   HeightReduction  <integer> = 0x0000000000000000 (0)
00:00:01.109895   LogoFile         <string>  = "" (cb=1)
00:00:01.109896   LogoTime         <integer> = 0x0000000000000000 (0)
00:00:01.109896   MonitorCount     <integer> = 0x0000000000000001 (1)
00:00:01.109897   ShowBootMenu     <integer> = 0x0000000000000002 (2)
00:00:01.109897   VRamSize         <integer> = 0x0000000008000000 (134 217 728, 128 MB)

The "Could not take a screenshot (VERR_NOT_SUPPORTED)" are common in guest logs, though not nearly so many as you have. I surmise that this error happens when Virtualbox recognizes that the guest screen is not in a state that permits screenshots. Your guest appears to have got stuck while the guest OS is in such a state, thus the long repeated error.

Your guest gets a lot of these, too:

00:00:38.560467 EFI: Out of bounds EFI_VM_VARIABLE_OP_VALUE write (0x##).

Maybe the guest OS doesn't like EFI?

Seems you're using the Microsoft-provided Windows 10 virtual machine. It's been a while since I tried one of these, maybe it came as an OVA appliance? This would explain the unusual settings.

You also have at least one snapshot in your guest's disk data. Maybe a corrupted sector?

00:00:01.061286 File system of '/Users/christopherschultz/VirtualBox VMs/MSEdge - Win10/Snapshots/{7f68f8a7-d72f-4423-a0bc-f7713faba2f1}.vmdk' is apfs

I would try a fresh Windows 10 guest, change the processor count to 2 and bump up the memory, but don't change anything else in the new guest's settings. Install 10 using an ISO made from the MS Media Creation Tool. Compare performance in this new guest.

One other thing that won't change performance but might upset that snapshot:

00:00:01.052951 File system of '/Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso' (DVD) is apfs

Remove the Guest Additions CD image after using it.

ChristopherSchultz wrote:Comparing to my other VMs, this one says "Hyper-V Virtualization" and the others all say "KVM Virtualization". Actually, all my VMs have "Virtualization" set to "Default" so they aren't specifically set to those values.

This is probably working as expected: When "Virtualization" is set to "Default", "Hyper-V Virtualization" is chosen for Windows guests and "KVM Virtualization" is chosen for Linux guests.

scottgus1 wrote:Your guest gets a lot of these, too:

00:00:38.560467 EFI: Out of bounds EFI_VM_VARIABLE_OP_VALUE write (0x##).

Maybe the guest OS doesn't like EFI?

AFAIK, the EFI implementation (up to and including VirtualBox 6.0.x) doesn't provide the guest OS with write access to its storage (whereby I don't know if this VBox.log file message indicates an attempted write access by the guest OS). But that leads to another suggestion to try:

VirtualBox 6.1.0 provides a new UEFI BIOS implementation, so it would be interesting to try and run the VM on it ...

As mentioned, switching from EFI -> BIOS won't allow the OS to start at all, so that's something I can't actually do with this guest. I'll try changing the other items. Having the ISO installed probably isn't helping, but VirtualBox shouldn't be trying to boot from that, anyway. Or at least if it does, it should give up pretty quickly.

Yes, the VM came from Microsoft as an OVA, so I got whatever settings they used, not whatever defaults my local VirtualBox setup would usually choose.

I can try a fresh one, but I haven't used the MS Media Creator to generate any media. I usually just get a temporarily-licensed VM from Microsoft because I'm not paying for any real licenses.

Removing the virtual optical drive (VMGuestAdditions.iso) did not change the behavior.

The log contains these lines:
00:00:38.494636 AHCI#0: Reset the HBA
00:00:38.494667 VD#0: Cancelling all active requests

I'm assuming whatever those are points to what is wrong.

Changing the chipset from ICH9 to PIIX3 has not changed the behavior, either.

Reverting the snapshot to the base disk image has not changed the behavior.

I suggest that you don't thrash around.

This seems to be just another variant of the "VirtualBox 6.x on OS X is really slow" post that we've had several of already. At the moment there is very little data.

Where did you get this VM? It doesn't seem to be a standard Win10 install, it looks like a Win10 Edge test/demo VM.

Why are you using EFI in this VM? Btw. I'm aware that you can't just switch to MBR. You would have to backup (before) and restore (after the change) using Macrium Reflect Free - I believe it can correct for the boot sector and partition map differences between EFI/GPT and MBR.

I haven't been thrashing around, this was very methodical. I was given a few items that might have been causing a problem, so I individually changed their values to see if it improved the situation. In each case, there was no improvement. Scientific method FTW.

This is not a variant of "VirtualBox 6.x on OS X is really slow," because, as I have stated, this only happens on a single one of my guest VMs. All others are okay. Once the boot process begins, it runs at full speed. The problem is that something weird is happening before the BIOS/EFI even boots.

I got this VM from modern.ie. It is indeed a Win10 Edge test/demo VM, like I said earlier.

Why am I using EFI in this VM? Because it was configured as such. If you read my "thrashing around" posts, you'll see that I tried using BIOS instead of EFI and the result was "BOOT FAILURE: INT8". That is somewhat less useful than a boot process that stalls for 38 seconds every time.

My very uneducated guess is that the EFI that VirtualBox 6.0 provides isn't working as the guest VM expects. I'm downloading a fresh VM from Microsoft to see if a later version will improve things.