Installing Alpine Linux in OpenBSD's VMM Hypervisor

vmm-alpine.sh

# Assuming you're a regular user that has doas allowances for vmctl
mkdir -p ~/vmm
cd ~/vmm

# Grab the the one of the virt iso's of Alpine Linux
curl https://nl.alpinelinux.org/alpine/v3.6/releases/x86_64/alpine-virt-3.6.0-x86_64.iso -o alpine-virt-3.6.0-x86_64.iso

# Make a new virtual disk image, change the size as needed
vmctl create alpine-virt.img -s 6G

# Boot Alpine from the ISO. Make sure you have this exact disk order because as of 29 May 2017
# VMM's SeaBIOS will only try to boot from the first one it seems!
# Also, this assumes:
# - you want 1024M of memory, tune as desired
# - you configured a virtual switch called "local" in your /etc/vm.conf 
#   (see: http://www.h-i-r.net/2017/04/openbsd-vmm-hypervisor-part-2.html)
doas vmctl start alpine -d alpine-virt-3.6.0-x86_64.iso -d alpine-virt.img -n local -m 1024M -c

# You shoud get a serial console connection immediately. Hit enter or whatever to boot Alpine.
# Once in Alpine, run:
setup-alpine

For the poor souls about to install Alpine on vmm, there's a bug in 6.6 and -current at least as of 1/28/2020 which prevents newer versions of Alpine from running properly (they are suddenly killed, no rhyme or reason I can find). Older versions of Alpine work well, though! Tested and very stable on alpine-virt-3.5.3-x86_64.

I don't know if this is still a problem, I am trying to run alpine-virt-3.11.3-x86-64.iso and it seems to be woring fine for at least 45-50 mins, mostly idle though.

Can you tell any amount of how to try and replicate this?

I've had this issue too. Guessing it's hardware related. openbsd72 running alpine-virt anything greater then or equal to 3.6 fails. No idea why.

Are you on Intel-based hardware for the OpenBSD host? If so, it's probably the Linux kernel probing some expected Intel hardware via MMIO registers. vmm(4) and vmd(8) do not implement support for emulating that access yet, but there is some preliminary support I committed a few months ago that's gated behind an #ifdef. It requires a -current host and building vmd(8) from source and twiddling the MMIO_NOTYET definition.

It might help the guests boot. If not, check the output and share it on misc@openbsd.org for me please.

Done. Thanks @voutilad :)

See my reply on the email list: https://marc.info/?l=openbsd-misc&m=167303917804395&w=2

In short, I think this is an issue we will fix in -current but since I don't think I have newer Intel hardware that supports the TSLEEP instructions to test my changes it may be a few days to confirm.

Looks like recent patch in 7.2 fixed this. Thank you!

Looks like recent patch in 7.2 fixed this. Thank you!