NULLos in other virtual machines
NULLos 0.3 does not only start in QEMU. This page says which settings a virtual machine needs, how you convert
the image into other formats, and what of this has really been checked.
As of 30 Oct 2026, NULLos 0.3. Every statement carries one of these marks:
- tested in QEMU: recreated and tried in QEMU 11.1.2 on a Mac, with output of the serial console as proof.
- tested in UTM: tried in UTM 5.0.8 on a Mac with Apple chip, also with output of the serial console.
- not tested: only per vendor documentation, with source.
- does not work: tried, does not work.
What every virtual machine needs
| Setting | Value | Mark |
|---|
| Processor | x86_64 (Intel/AMD, 64 bit) | tested in QEMU |
| Firmware | UEFI (EFI). With BIOS or "Legacy" NULLos does not start (according to nullos.de) | tested in QEMU: UEFI; BIOS not tried |
| Secure Boot | off: NULLos is not signed (according to nullos.de) | QEMU has no Secure Boot on here |
| Memory | 256 MB is enough | tested in QEMU |
| Disk | SATA (AHCI) or NVMe | tested in QEMU |
| CD | the ISO as a CD drive | tested in QEMU |
| Network card | Intel e1000, Intel e1000e or virtio-net | tested in QEMU |
| Keyboard | PS/2 or USB | tested in QEMU |
These network cards do not work (does not work): VMware vmxnet3, AMD PCnet (in VirtualBox "PCnet") and
Realtek RTL8139. NULLos does start, but finds no network card. ip then only shows lo, and pi
reports „Netz nicht erreichbar“ ("network unreachable").
Converting the image
You can insert the ISO directly as a CD. The image nullos-0.3-x86_64.img is a raw disk. Many
programs want their own format. qemu-img (comes with QEMU) converts it:
qemu-img convert -f raw -O vmdk nullos-0.3-x86_64.img nullos.vmdk
qemu-img convert -f raw -O vdi nullos-0.3-x86_64.img nullos.vdi
qemu-img convert -f raw -O vhdx nullos-0.3-x86_64.img nullos.vhdx
| Format | for | Mark |
|---|
.vmdk | VMware, also VirtualBox | tested in QEMU: starts up to the shell |
.vdi | VirtualBox | tested in QEMU: starts up to the shell |
.vhdx | Hyper-V | tested in QEMU: starts up to the shell |
"Tested in QEMU" means here: the converted file starts in QEMU. Whether the program the format is meant for
accepts it the same way has not been checked.
Recreated in QEMU
The hardware that other programs usually offer can be rebuilt in QEMU. These additions to the
command from QEMU and SSH have been checked:
| Addition | recreated | Result |
|---|
-device nvme,drive=d,serial=n1,bootindex=0 with -drive if=none,id=d,format=raw,file=nullos.img | NVMe disk | tested in QEMU: disk sda on nvme, /boot present |
-cdrom nullos-0.3-x86_64.iso | CD | tested in QEMU: shell comes up, /boot is empty |
-nic none -netdev user,id=n0 -device e1000,netdev=n0 | network card e1000 | tested in QEMU: address via DHCP, pi answers |
the same with e1000e or virtio-net-pci | e1000e, virtio-net | tested in QEMU: address via DHCP, pi answers |
the same with vmxnet3, pcnet or rtl8139 | VMware, VirtualBox, Realtek card | does not work: no network card |
-device qemu-xhci,id=x -device usb-kbd,bus=x.0 | USB keyboard | tested in QEMU: types with German layout, even without PS/2 |
Note on QEMU: If you start the same copy first on SATA and then on NVMe, QEMU ends up in the EFI shell
(Shell>). The firmware remembers the old boot path in a file on the boot partition. Fix:
bootindex=0 as above, or a fresh copy of the image.
UTM (Mac)
UTM 5.0.8 on a Mac with Apple chip, mode "Emulate" (x86_64 is emulated, not virtualized).
The test VMs were created via AppleScript, not through the user interface. Proven with the serial console.
| Setting | Value | Mark |
|---|
| Architecture | x86_64, machine q35 (default) | tested in UTM |
| UEFI | on ("UEFI Boot") | tested in UTM |
| Memory | 256 MB | tested in UTM |
| ISO as CD (removable drive, interface IDE) | shell comes up, network works | tested in UTM |
.img as disk, interface IDE | disk sda on ahci, /boot present | tested in UTM |
.img as disk, interface NVMe | disk sda on nvme, /boot present | tested in UTM |
| Network "Shared" with e1000 or virtio-net-pci | address via DHCP (192.168.64.x), ping to 192.168.64.1 answers | tested in UTM |
| Keyboard | UTM switches PS/2 off by default and uses USB (source). USB keyboard works in QEMU even without PS/2 | not tested in UTM, recreated in QEMU |
UTM accepts raw and QCOW2 images, so it takes the .img directly (source).
Secure Boot is only available there together with TPM 2.0 (source).
Other programs (not tested)
For these programs this page only gives what the vendors document. None of it has been tried: on the
test Mac (Apple chip) they do not run x86_64 guests or are not installed, and there was no Windows computer
for Hyper-V. Documentation as of: 30 Oct 2026.
VirtualBox
| Setting | per vendor documentation |
|---|
| EFI | System → Motherboard → "Enable EFI", or VBoxManage modifyvm "VM" --firmware efi (source) |
| Secure Boot | checkbox "Enable Secure Boot", or VBoxManage modifynvram "VM" secureboot --disable (source) |
| Disk | SATA (AHCI) or NVMe; formats VDI, VMDK, VHD (source) |
| Converting | VBoxManage convertfromraw nullos-0.3-x86_64.img nullos.vdi --format VDI (source) |
| Network card | change it: the default is PCnet (Am79C973), which does not work with NULLos. Use "Intel PRO/1000 MT Desktop (82540EM)" or virtio-net (source) |
| Keyboard | PS/2 or USB (--keyboard ps2 or usb) (source) |
On Macs with Apple chip, VirtualBox does not start x86_64 guests (source).
VMware Workstation Pro and Fusion Pro
| Setting | per vendor documentation |
|---|
| EFI | Workstation: VM → Settings → Options → Advanced → "Firmware type: UEFI" (source). Fusion: Settings → Other → Advanced → "Firmware type" (source). The VM must be off for this |
| Secure Boot | in the same place, leave the checkbox "Enable UEFI Secure Boot" unticked |
| Disk | SATA (AHCI) or NVMe, format .vmdk (source) |
| CD | ISO on IDE, SCSI or SATA; CD drives do not work on NVMe (ibid.) |
| Network card | For 64-bit guests the documentation names the Intel Pro/1000 MT Server (e1000). Other card types are not described there. vmxnet3 does not work with NULLos |
On Macs with Apple chip, Fusion does not run x86 systems (source).
Hyper-V (Windows)
| Setting | per vendor documentation |
|---|
| EFI | only with Generation 2 (source) |
| Secure Boot | on by default in Generation 2; off with Set-VMFirmware -VMName "VM" -EnableSecureBoot Off (source) |
| Disk, CD | Generation 2 boots from virtual SCSI (disk .vhdx, ISO as SCSI DVD); the documentation does not mention AHCI or NVMe (source as for EFI) |
| Network, keyboard | Generation 2 only has synthetic devices, no e1000 card and no PS/2 (source as for EFI) |
NULLos will probably not work in Hyper-V. Generation 1 has no UEFI, Generation 2 only has devices for which
NULLos has no drivers. This is a conclusion from the documentation, not tried.
Parallels Desktop (Mac)
| Setting | per vendor documentation |
|---|
| EFI | prlctl set "VM" --efi-boot on, off by default (source) |
| Secure Boot | prlctl set "VM" --efi-secure-boot off (ibid.) |
| Disk | interface IDE, SCSI or SATA (source) |
| Network card | --adapter-type e1000, e1000e or virtio (source); on Macs with Apple chip always virtio |
On Macs with Apple chip, Parallels Desktop 27 can start x86_64 VMs as an early preview: only with UEFI, only one
CPU, without USB, only in the Pro, Business and Enterprise editions (source).
Mac with Apple chip: what x86_64 can do
| Program | x86_64 guest on Apple chip | Mark |
|---|
| QEMU | yes, as emulation | tested in QEMU |
| UTM | yes, mode "Emulate" (source) | tested in UTM |
| Parallels Desktop 27 | limited, as a preview (source) | not tested |
| VMware Fusion | no (source) | not tested |
| VirtualBox | no (source) | not tested |
Emulation is much slower than virtualization. In UTM the shell of NULLos 0.3 was there after 40 seconds
(observed on 30 Oct 2026, not measured exactly).