VM Hangs at 100% CPU On Boot

[rfkrocktk-oracle]

This issue has been present since VirtualBox 4, and is still present in the latest release of VirtualBox 5.1 on Ubuntu, package version: 5.1.2-108956~Ubuntu~trusty.

The issue is reproducible across all types of guest operating systems, therefore it appears to be a host-level bug in VirtualBox itself. I've seen this issue manifest on various Ubuntu and Fedora versions as well as Windows 7.

I can install an operating system on the first boot up (ie, when there's nothing installed on the virtual disk). After that, as soon as I power off and then power on the machine, I cannot even get the guest to POST. The machine hangs at 100% CPU usage and I don't even get the VirtualBox BIOS boot screen. I get a progress bar that eventually displays saying "Starting Virtual Machine", but no progress is made and one CPU is locked to 100% utilization.

Interestingly enough, I don't have this problem with headless VMs created via Vagrant, only with VMs I have manually installed using live CDs.

I'm running kernel 4.4.0 from the official Ubuntu repositories. The filesystem on the host is a BTRFS subvolume on top of a LUKS encrypted container. I have BTRFS compression enabled on the subvolume, but the bug is present with or without compression enabled. There's nothing triggered in syslog or dmesg on the host during the issue with the guest, nothing seems amiss.

A screenshot of starting the VM: ​https://imgur.com/bsyvLrp

Here is my VM's log with all of the attempted boots: ​https://gist.github.com/rfkrocktk/a0e7e52151f36b4cf4e131b639330864

[rfkrocktk-oracle]

I have verified this problem using the same filesystem hierarchy on a Fedora machine running kernel 4.6.7. I'm about to attempt to reinstall using LUKS + ext4 as opposed to BTRFS and see if that resolves the problem.

[rfkrocktk-oracle]

Seems to be related (if not the same as) #11862.

[rfkrocktk-oracle]

I was able to fix the problem by doing the following:

1. create a BTRFS subvolume named "home-$USER-virtualbox"
2. mount this subvolume at "/home/$USER/.virtualbox"
3. in mount options in fstab, include "nodatacow"
4. edit "~/.config/VirtualBox/VirtualBox.xml" to replace instances of "VirtualBox VMs" with the path to "~/.virtualbox"
5. rsync -avP --remove-source-files "~/VirtualBox VMs/" "~/.virtualbox/"
6. reimport all virtual machines in the VirtualBox GUI.

After this, all VM disk images are created in a CoW-disabled filesystem/subvolume/directory, and the bug disappears.

Oracle would do well to either file/fix the O_DIRECT kernel bug with BTRFS or to simply call "chattr +C diskimage.vmdk" every time a virtual machine disk image is created with VirtualBox if the directory is on a BTRFS filesystem.

[Frank Mehnert]

Sounds like a duplicate of #11862. Doing the chattr command would certainly help in some cases but not in all cases, for instance if the user copies / rsyncs the files to a btrfs system manually. I think it would make more sense to check the FS attributes and provide the user a warning in case the virtual disk image file has the CoW bit enabled.