systemd-vmspawn(1)

This feature is experimental and subject to change without advance notice. It will be stabilized and given a backward-compatibility guarantee in a future release, but may also possibly be removed.

Configures whether to run the guest as a confidential VM. Takes one of no, sev-snp or tdx. Defaults to no.

sev-snp enables AMD SEV-SNP. This requires KVM on an x86_64 host with SNP-capable hardware and firmware. A suitable SNP-built OVMF firmware is picked automatically from the installed QEMU firmware descriptors, by requiring the amd-sev-snp firmware feature; use --firmware= with a path to a firmware descriptor file to select a specific one. Secure Boot is effectively off by default (see --secure-boot=). Direct kernel boot via --linux= is required so that the kernel, initrd and command line are hashed into the launch measurement (kernel-hashes=on); booting the kernel off the disk image via the firmware would leave it outside the measurement. Credentials passed via --set-credential= or --load-credential= are bundled into a cpio archive appended to the initrd (mirroring what systemd-stub does for ESP credentials), so they enter the launch measurement via kernel-hashes=on; the SMBIOS and fw_cfg channels normally used to deliver credentials are not used because they are unmeasured and would be discarded by PID1 in confidential guests. This channel is measured but not confidential with respect to the host or VMM: the initrd (and thus the credentials it carries) is supplied to QEMU as plaintext and only its hash enters the launch measurement, which guarantees integrity but does not keep the credentials secret from the host. This requires the guest to run a sufficiently recent version of systemd (supporting /.extra/system_credentials/). A vTPM, if attached via --tpm=, must be treated as untrusted by the guest.

tdx enables Intel TDX. This requires KVM on an x86_64 host with TDX-capable hardware and a TDX-enabled host kernel. As with sev-snp, a TDX-built OVMF (TDVF) firmware is picked automatically from the installed QEMU firmware descriptors, by requiring the intel-tdx firmware feature; use --firmware= with a path to a firmware descriptor file to select a specific one. The CPU model is fixed to host. Firmware is measured into MRTD when the TD is built. Secure Boot cannot be enrolled at runtime (there is no writable NVRAM); its state is fixed by the selected TDVF image and is part of the measured firmware (see --secure-boot=). When booting a UKI, the whole UKI PE is measured into RTMR 1, and the loaded sections are measured individually by systemd-stub into RTMR 2. For direct linux boot, firmware measures the kernel PE into RTMR 1, and the Linux EFI stub measures initrd and command line into RTMR 2. Credentials passed via --set-credential= or --load-credential= are delivered through SMBIOS Type 11 OEM strings when the guest boots via systemd-stub or systemd-boot, which measure the SMBIOS table including the OEM strings into RTMR 0; the guest's service manager imports them only if that measurement took place, since the firmware's own SMBIOS measurement does not cover the OEM strings. For direct linux boot, where no boot loader runs, credentials are instead packaged into a cpio archive appended to the initrd, as under SEV-SNP, which the Linux EFI stub measures into RTMR 2. Both channels are measured but not confidential with respect to the host or VMM, since the host assembles the SMBIOS table and the initrd. A vTPM, if attached via --tpm=, must be treated as untrusted by the guest. To obtain TD Quotes for remote attestation, the guest is wired to the host's local TDX Quote Generation Service automatically: the unix socket /run/tdx-qgs/qgs.socket is used if it exists, otherwise vsock port 4050 on the host (cid 2). If the QGS is listening on neither channel, the guest's quote requests will fail. Added in version 262.

Added in version 261.

.RE

.SS "Networking Options"

.PP -n, --network-tap

$ mkosi -d arch -p systemd -p linux --autologin -o image.raw -f build
$ systemd-vmspawn --image=image.raw

$ curl -L \


       -O https://download.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-44-1.7.x86_64.qcow2 \


       -O https://download.fedoraproject.org/pub/fedora/linux/releases/44/Cloud/x86_64/images/Fedora-Cloud-44-1.7-x86_64-CHECKSUM \


       -O https://fedoraproject.org/fedora.gpg
$ gpgv --keyring ./fedora.gpg Fedora-Cloud-44-1.7-x86_64-CHECKSUM
$ sha256sum -c Fedora-Cloud-44-1.7-x86_64-CHECKSUM
# importctl import-raw -m Fedora-Cloud-Base-Generic-44-1.7.x86_64.qcow2 fedora-44-cloud
# systemd-vmspawn -M fedora-44-cloud

$ mkosi build
$ systemd-vmspawn \


    -D mkosi.output/system \


    --private-users $(grep $(whoami) /etc/subuid | cut -d: -f2) \


    --linux mkosi.output/system.efi \


    --forward-journal=vm.journal \


    enforcing=0

$ mkosi build
$ my_vsock_cid=3735928559
$ systemd-vmspawn \


    -D mkosi.output/system \


    --private-users $(grep $(whoami) /etc/subuid | cut -d: -f2) \


    --linux mkosi.output/system.efi \


    --vsock-cid $my_vsock_cid \


    enforcing=0
$ ssh root@vsock/$my_vsock_cid -i /run/user/$UID/systemd/vmspawn/machine-*-system-ed25519