kubevirt-vm-migration-platform

ADR 002: AWS as the disposable migration target

• Status: Accepted

Context

KubeVirt needs Kubernetes worker nodes with hardware virtualization (/dev/kvm). The laptop cannot host both nested ESXi and a KVM-capable Kubernetes cluster with enough memory. Project 1 already established Terraform, EKS and GitOps practice on AWS. AWS announced on 2026-02-16 that nested virtualization is available on supported non-bare-metal EC2 instances (KVM and Hyper-V as L1 hypervisors, no additional cost), in addition to bare-metal instances.

Decision

The destination Kubernetes + KubeVirt environment runs on AWS, is created only through Terraform, and is disposable: built for a working session and destroyed afterwards. No AWS resources are created in Stage 0.

Scope clarification (Stage 0 refinement)

This ADR decides where the target runs and how it is managed (Terraform, disposable). It deliberately does not decide:

• the Kubernetes topology: EKS and self-managed Kubernetes are parallel, unvalidated options;
• the EC2 instance family, exact size, Region or AMI;
• nested-virtualization instance vs *.metal.

Those are deferred decisions, to be made from test evidence against the KubeVirt host-requirement checklist (feasibility section 5).

Cross-reference (Stage 1H): the first-migration target topology, instance family, Region and node OS are decided by design in ADR 007, still subject to a runtime validation gate.

Consequences

• Cost is bounded by session length; Git + Terraform are the source of truth.
• Open validation questions: whether the chosen worker architecture (EKS-managed or self-managed) satisfies every KubeVirt host requirement (CPU nested virtualization, /dev/kvm, /dev/vhost-net, /dev/net/tun, privileged DaemonSets, host kernel/userland alignment, runtime, device ownership, node image, storage, networking).
• EBS gp3 volumes are RWO and AZ-scoped: VM workers and volumes live in one AZ; no live migration across nodes.
• Every session repeats cluster bootstrap, so KubeVirt/CDI install must be automated.
• Blocker: AWS credentials must be recovered or re-issued first.

Post-implementation note (added 2026-10-15). In Stage 1I (2026-10-01), Terraform created all 10 AWS resources of the target and later destroyed exactly those 10. AWS confirmed the removal, and no orphaned volume remained (Stage 1I record, sections 16 and 19). The credentials blocker was resolved: Terraform ran with the operator’s credentials on the jump host, outside Git. The automation consequence above was not met in this repository. Terraform (infra/terraform/stage-1i-target) covers only the AWS layer. Kubernetes, KubeVirt, CDI and the CSI driver were installed on the node step by step, as recorded in Stage 1I section 16, and the helper scripts used were archived outside Git. A rebuild therefore repeats those recorded steps; it is not a single command.

Evidence

AWS: nested virtualization on EC2, What’s New 2026-02-16, KubeVirt installation requirements, EKS Kubernetes versions. Project 1 ADR 001 (Terraform for AWS) precedent.