Headless boot from command line never completes with some guest OS

[Thierry Lelegard]

Configuration

VirtualBox version 7.0.14 r161095 for Windows (x86_64), downloaded from virtualbox.org.

One host: Lenovo laptop, 14 cores, 32 GB, Windows 11 Pro.

14 guests: Ubuntu, Debian, Mint, Fedora, Redhat (Rocky Linux), openSUSE Leap, openSUSE Tumbleweed, Alpine, Arch, Gentoo, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD.

Most VM's have identical configuration. Typically 6 CPU, 8 MB, 2 network interfaces (first is NAT, second is host-only). All VM configuration files are in the attached archive. All VM's have the VBox Guest Additions installed, when supported on the guest.

The VBoxManage command lines are indifferently run from a PowerShell window, a Cygwin bash window or a MinGW bash window. The result is the same.

The host is a development system for an open source project. The VM's are used to build binaries. So, I need scripting for automation (boot, build, get binaries, shutdown). This is why being able to start and stop VM's from the command line is essential.

Problem description

All 14 VM's work fine when started with a GUI, from the VBox GUI.

However, with some guests, Fedora, Redhat and a few others, the boot never completes when started from the command line in headless mode with the command "VBoxManage startvm <vm-name> --type=headless".

The type of problem may vary: 1) Black screen when starting gnome, 2) CPU soft lockup error, 3) Stuck on first line of display after OS loaded (after grub). I see this in the small snapshot window from the VBox GUI. The guest is never accessible (ping) on the host-only network adapter.

When I start the VM from the command line without "--type=headless", as long as I leave the VM window in the background, with focus on other windows, a local terminal, the VBox GUI, the boot hangs (same symptoms as headless boot). However, when I pop up the VM window on the foreground and the "mouse integration" message appears, then the boot completes with some VM's (detailed list below).

The same phenomenon appears when I start the VM headless and then double-click in the VBox GUI to create the VM window. When the VM window appears and gets input focus, the boot sometimes continue.

Problem details by guest OS

All VM have identical configurations. I have attached the description ("VBoxManage showvminfo") of all. Most VM's differ only in file names, UUID, MAC address and dates. The BSD guests needed a different device set.

The following list details the behavior of the various guest OS after a headless boot from the command line.

• Redhat (Rocky), openSUSE Leap, openSUSE Tumbleweed, Arch Linux
  • Boot hangs, unblocked when the VM windows is opened and get focus.
• Fedora
  • Boot hangs, CPU soft lockup, neven unblocked, even when the VM windows is opened and get focus.
• Gentoo
  • Boot completes, Gnome started (seen on the small window in VBox GUI), guest not reachable (ping) on the host-only network interface until the VM windows is opened and get focus.
• Ubuntu, Debian, Mint, Alpine, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD
  • Headless boot ok, complete and the VM can be accessed by ssh. No need to open any GUI.

As a summary, starting a VM headless from the command line works on 4 Linux and 4 BSD and fails on 6 Linux.

Note that the behavior may vary. With the Redhat VM, after popping up the VM windows the boot may continue or may remain stuck. On at least one occurrence, the openSUSE Leap VM boot completed without opening the VM window.

Fedora guest example

$ VBoxManage startvm vmifedora --type=headless
Waiting for VM "vmifedora" to power on...
VM "vmifedora" has been successfully started.

• The guest never boots. The small window in the VBox GUI shows a black screen with one line of text on top. Nothing progresses further.
• We open the VM window with a double click in the VBox GUI. The top text line is simple 'Booting Fedora Linux ...'.
• Soon after we open the VM window, a kernel message appears: "watchdog: BUG: soft lockup - CPU#1 stuck for 21s".
• The "soft lockup" messages appears again from time to time.
• Then, there is no other choice than powering off the VM.

The corresponding logs are in the archive in subdirectory vmifedora/Logs.

[Thierry Lelegard]

VM configuration and log files

[Thierry Lelegard]

Update: The problem only appears when VBox runs on E-cores of the system. The CPU is Intel Core i7-13700H Gen13, from the Alder Lake / Raptor Lake family, with P-cores and E-cores.

Due to the Windows power policy, interactive processes naturally run on P-cores while background processes run on E-cores. With VirtualBox, starting a VM from the GUI creates an interactive process and a headless start creates a background process.

Using "powercfg /powerthrottling disable", I force most VirtualBox exe to run on P-cores:

powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VBoxHeadless.exe'
powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VirtualBoxVM.exe'
powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VirtualBox.exe'
powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VBoxNetDHCP.exe'
powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VBoxNetNAT.exe'
powercfg /powerthrottling disable /path 'C:\Program Files\Oracle\VirtualBox\VBoxSVC.exe'

Then, starting a VM in headless mode behaves identically as starting it from the GUI. VBoxHeadless.exe runs on P-cores.

However, there is still a problem with E-cores. These cores are slower than the P-cores in the same CPU. However, these E-cores are still way faster than older CPU's on which VirtualBox works perfectly well.

So, the performance of the E-core cannot explain the problem. There is a specific problem when VBoxHeadless.exe runs on E-cores which causes some distros to hang on boot.

Specifically, in the case of Fedora which repeatedly reports "soft lockup - CPU stuck" errors, we can see in the Windows Task Manager of the host that 4 E-cores are busy looping on something while the kernel of the guest reports a "CPU stuck".

[Thierry Lelegard]

Update 2: The problem also disappears when Hyper-V is completely disabled, even with power-throttling enabled on VirtualBox executables and, consequently, the VM running on E-cores.

Therefore, we can say that a VM boot hangs when Hyper-V is enabled (NEM mode in VirtualBox) and the VM runs on the E-cores (headless start with power-throttling enabled on VirtualBox).

The hangs depends on the guest OS (see list in the original report).