ADR 002 placed the target on AWS (Terraform, disposable) but left the topology open: EKS or self-managed Kubernetes, instance family, AMI, and nested virtualization versus bare metal. ADR 004 chose upstream KubeVirt + CDI with versions recorded as one runtime-validated tuple. Stage 1H had to close these questions from official evidence, without creating anything.
The evidence that decided it (all retrieved 2026-09-28; details and URLs in the Stage 1H record):
Chosen target for the first KubeVirt migration:
| Item | Value |
|---|---|
| Platform | Self-managed Kubernetes, bootstrapped with kubeadm, one node acting as control plane and worker (control-plane taint removed) |
| Compute | One EC2 m8i.xlarge (4 vCPU, 16 GiB, Intel), nested virtualization enabled at launch, on demand; m7i.xlarge as the alternate |
| Region / AZ | ap-south-1, one Availability Zone |
| Node OS | CentOS Stream 9, x86_64 (official CentOS AMI) |
| Runtime | CRI-O 1.36, systemd cgroup driver, cgroup v2, SELinux enforcing |
| Kubernetes | 1.36 (patch pinned at build time) |
| KubeVirt / CDI | v1.9.0 / v1.66.1 |
| CNI / CSI | flannel / AWS EBS CSI driver |
| Lifecycle | Built and destroyed with Terraform per session (ADR 002) |
This is the platform KubeVirt’s own CI uses for Kubernetes 1.36, with EC2 nested virtualization in place of kubevirtci’s VMs. The tuple stays a candidate until the Stage 0 runtime validation gate passes on the real node.
Not a claim about production suitability.
| Alternative | Outcome | Reason |
|---|---|---|
| EKS with nested-virtualization managed nodes | Deferred | Kernel alignment would need a self-built EL9 node AMI, which removes most of the managed-node benefit. The /dev/kvm path on EKS is undocumented, the VPC CNI is not a KubeVirt CI platform, and the control plane adds USD 0.10/h (+42%). Not rejected: a later stage can compare it on evidence |
| Local VMware-hosted Kubernetes | Rejected as the primary target | Guests would run four layers deep; the laptop has about 6 GiB free and ESXi is at 11.3 of 16 GB; ADR 002 fixed AWS; keeping VMnet8 would invite artificial preservation of 192.168.50.31 |
Bare-metal EC2 (m7i.metal-24xl, USD 5.0904/h) |
Fallback only | About 23 times the cost. Used only if nested virtualization fails, and only after a new decision |
Software emulation (useEmulation) |
Rejected | Not representative; the build stops if /dev/kvm is missing |
| Ubuntu or Amazon Linux nodes | Rejected | Non-EL kernels are outside KubeVirt’s upstream validation [E7] |
| Multi-node / multi-AZ | Deferred | Nothing in one cold migration needs it |
/dev/kvm, /dev/vhost-net, /dev/net/tun, privileged API server, CRI-O, SELinux, cgroup v2, EL kernel) is under our control and inspectable. The only unproven element is nested virtualization on the chosen type in ap-south-1.Stage 1H record, sections 6 to 12 and 22, sources E1 to E9, E25 to E38, E42 to E48.
Added 2026-10-15. The decision, context and alternatives above are unchanged. Stage 1I built this target with Terraform, used it for the first migration, and destroyed it on 2026-10-01. All values are OBSERVED in the Stage 1I record, sections 16 and 19.
| Aspect | Outcome |
|---|---|
| Design decision | Self-managed, single-node kubeadm cluster on one nested-virtualization m8i.xlarge in ap-south-1, CentOS Stream 9, CRI-O, flannel, EBS CSI, KubeVirt v1.9.0 and CDI v1.66.1 |
| Deployed and validated | m8i.xlarge in ap-south-1a with NestedVirtualization=enabled. VT-x and /dev/kvm were present and kvm_intel loaded with nested=Y; virt-host-validate qemu passed its hardware-virtualization checks. CentOS Stream 9 (kernel 5.14.0-754.el9, SELinux enforcing), Kubernetes v1.36.5 via kubeadm, CRI-O 1.36.6, flannel v0.28.9, KubeVirt v1.9.0 (Available), CDI v1.66.1 (Available), and the EBS CSI driver (v1.66.0 release manifests, driver image v1.65.0). The first migration ran on this tuple (section 18), which resolves the “candidate until the runtime gate” caveat for this one workflow. The record shows equivalent checks; it does not report results against the Stage 0 G1 to G7 labels |
| Differences from the design | The newest AMI named “CentOS Stream 9 x86_64” booted CentOS Stream 10 in image mode. Terraform replaced it with the centos.org-listed CentOS Stream 9 AMI before anything was installed (record W1). The kubeadm preflight warned that the EL9 kernel version was “unsupported” (W4). The cloud-config hostname did not take effect (W3) |
| Limitations | One node acting as control plane and worker, so no HA and no live migration. Functional validation only, with no performance measurement. EKS was still not tested |
| Destroyed | VM, disk and Service removed through Kubernetes (I5-C to I5-F). terraform destroy removed exactly the 10 Terraform-managed resources (I5-G), which took the cluster software with the instance. AWS lookups confirmed removal (I5-H), and the orphan-volume scan found nothing (I5-I) |
The consequence “the only unproven element is nested virtualization on the chosen type in ap-south-1” is now proven for this instance type and Region.