All you need to do is install the QEMU User space emulator for aarch64 and register it in binfmt_misc as the interpreter for aarch64 binaries.

On Alpine Linux

apk add qemu-aarch64 qemu-openrc
rc-service qemu-binfmt start

On Debian/Ubuntu

apt-get install -y --no-install-recommends binfmt-support qemu-user-static
update-binfmts --enable

On Fedora

dnf install qemu-user-static

On GitHub Actions

- name: Install qemu-aarch64 and register in binfmt
  uses: jirutka/setup-alpine@v1
  with:
    arch: aarch64

See .github/workflows/ci.yml for a complete example.

After that, run alpine-make-vm-image with the option --arch aarch64.

The Linux kernel (linux-virt, linux-lts or linux-edge package) in Alpine v3.18 and earlier doesn’t have EFI_ZBOOT enabled, so EFI stub cannot load a compressed vmlinuz. We backported it to v3.18, but then we had to revert it due to a problem with Grub (see alpine/aports#15263).

If you want to build an image with an older branch of Alpine Linux, you can, but you must install the kernel from the v3.19 branch (or newer). This is relatively safe because the kernel package doesn’t have any dynamic dependencies.

1. Create a repositories file with a pinned main repository from v3.19, e.g.:

   @v319 https://dl-cdn.alpinelinux.org/alpine/v3.19/main
   https://dl-cdn.alpinelinux.org/alpine/v3.18/main
   https://dl-cdn.alpinelinux.org/alpine/v3.18/community

2. Run alpine-make-vm-image with the options --repositories-file ./repositories and --packages linux-virt@v319 (or linux-lts@v319 if you use --kernel-flavor lts).

This will first install linux-virt from v3.18, but in the later step it will reinstall it from the v3.19 branch.

VMware and disk images (virtual disks) is one big mess. You can find that VMware uses the VMDK format, but the problem is that this is not a single format. Actually it has many subformats with very different structure and various (in)compatibility with VMware hypervisors.

When I’ve created a disk image using qemu-img create -f vmdk or converted Qcow2 to VMDK using qemu-img convert -O vmdk, vSphere client loaded this image without any problem, but the data was corrupted. Eventually I found in some old documentation that ESXi does not support “sparse” disks…

So after many trials I found out that the least bad and functional solution is to create Qcow2 image and then convert it to VMDK using:

Unfortunately, this creates a “thick” image, i.e. its size equals the “provisioned space”, not actually used space as in Qcow2. However, you can compress it with gzip to avoid transferring multiple gigabytes of zeros over network.