Image Export — from disk to cloud in one command

kexport turns a running kldload disk into a portable image file. One command, five formats. The result lands in /root/exports/ and is ready to import into any hypervisor or cloud provider. No dd tricks, no qemu-img flags to memorize — just pick the format you need.

Supported formats

Basic usage

# Export to qcow2 (default output: /root/exports/hostname-YYYYMMDD.qcow2)
kexport qcow2

# Export all five formats at once
kexport all

# Custom output filename
KEXPORT_NAME=golden-centos-zfs kexport qcow2

# Custom output directory
KEXPORT_DIR=/mnt/nas/images kexport vmdk

Expected output for kexport qcow2:

[kexport] detecting root device... /dev/sda
[kexport] root pool: rpool (3 datasets)
[kexport] taking pre-export snapshot: rpool@kexport-20260325-091200
[kexport] creating sparse raw image... done (18.2 GiB logical, 4.1 GiB actual)
[kexport] converting to qcow2...
    (100.00/100%)
[kexport] output: /root/exports/myserver-20260325.qcow2
[kexport] size on disk: 2.8 GiB (compressed)
[kexport] done in 47s

Full workflow: install → configure → export → deploy

Step 1 — Install kldload

Boot the ISO, install to your target disk with the Web UI or unattended install. Pick any distro and profile. Reboot into the installed system.

Step 2 — Configure the system

Install packages, configure services, set up users, tune ZFS. This is your golden image — make it exactly right.

kpkg install nginx redis
systemctl enable nginx
useradd -m deploy
# ... any other setup ...

Step 3 — Export

# For Proxmox
kexport qcow2

# For VMware
kexport vmdk

# For Azure
kexport vhd

# All formats
kexport all

Step 4 — Import on the target hypervisor

Proxmox:

# Copy the image to the Proxmox host, then:
qm importdisk 101 /root/exports/myserver-20260325.qcow2 local-zfs
qm set 101 --virtio0 local-zfs:vm-101-disk-0
qm start 101

KVM / libvirt:

cp /root/exports/myserver-20260325.qcow2 /var/lib/libvirt/images/
virt-install --name myserver --import \
  --disk /var/lib/libvirt/images/myserver-20260325.qcow2 \
  --memory 4096 --vcpus 2 --os-variant centos-stream9

Azure:

# Upload the VHD to a storage account, then create a managed image
az storage blob upload --container-name vhds \
  --file /root/exports/myserver-20260325.vhd \
  --name myserver.vhd
az image create --resource-group myRG --name myserver-image \
  --source https://mystorage.blob.core.windows.net/vhds/myserver.vhd \
  --os-type Linux

VirtualBox:

# Copy the .ova file to your workstation, then:
VBoxManage import myserver-20260325.ova
# Or: File > Import Appliance in the VirtualBox GUI

Bare metal (raw):

# Write directly to a disk (destructive — target disk is wiped)
dd if=/root/exports/myserver-20260325.raw of=/dev/sdb bs=4M status=progress

Golden image workflows with kimage

kimage builds on kexport for teams that maintain a fleet of identical machines. While kexport is a one-shot export of the current disk state, kimage manages a versioned image library.

# Tag the current export as a named golden image
kimage create base-centos-zfs-v1

# List stored images
kimage list

# Promote an image (mark it as the current golden master)
kimage promote base-centos-zfs-v1

# Deploy a golden image to a remote host
kimage deploy base-centos-zfs-v1 root@192.168.1.50

# Roll back to previous image version
kimage rollback base-centos-zfs-v1

Images are stored in /root/images/ by default. Each version is a qcow2 with a companion manifest (.json) that records the distro, profile, ZFS version, kernel version, and export timestamp. This makes audit trails and reproducible infrastructure straightforward.

Which format should I use?

When in doubt, export qcow2. It is the most flexible format and qemu-img convert can convert it to any other format offline if your target changes later.