Nested virtualization with VirtualBox under Android VM: linux boot hangs

I’m trying to build a VM image of Arch Linux using Packer under the Android VM (2023.07.1, tried both medium and large class). The nested hypervisor is VirtualBox.

The issue here is that while VirtualBox always starts, booting the Linux kernel almost always hangs just after the boot. A minority of times, however, it actually boots.

I have captured a video of the issue, but the message board does not le me upload images or add links to the video…

To post the link, just use spaces rather than :// or .

As for the larger issue, CircleCI instances are run on hosted systems at companies like Amazon AWS and so are already defined within a hypervisor. The following cover the issue

To do VM work you would need a solution that can operate within a cloud provider’s environment or you would need to look at a self-hosted runner. This allows you to deploy to your own hardware or a ‘bare metal’ system that you rent in the cloud.


Here’s the link to the video capture, Base64-encoded to pass the checks:


Note that the syslinux boot counter resetting to 15 every few seconds for the first minute is correct: it’s caused by some simulated keystrokes. The issue appears after the first minute and you can see the VM stuck at the first kernel boot message for 8 minutes before Packer times out.

As far as nested virtualization is concerned, my understanding is that the Android VM is tailored for running hypervisors, in particular the Android Emulator, which is based on qemu and uses hardware assisted virtualization just like VirtualBox. That seems to work fine, since the VM is actually starting, If virtualization extensions were not available, VirtualBox would refuse to even start a 64-bit VM. My specific issue is a random post-boot hang, which does not seem to have an explanation.


edd= Enhanced Disk Drive

So your virtual machine is locking up when VirtualBox tries to do a low-level hardware check regarding the features available to a physical device. You could try adding ‘edd=off’ to the startup command line and then see what other issues show up.

As for VirtualBox vs QEMU, QEMU was originally designed (a long time ago) to work on top of KVM which likely means it also understands the limitations of AWS’s Xen or Nitro platforms. So there may have been a lot of things done to QEMU to make it a good fit for the type of environment you are trying to deploy to which have not been done to VirtualBox, just due to its own history and the focus set by its owners.