Stage 1I — The First VM Running on KubeVirt

Steps 1 to 6 are earlier Stage 1 work. I1 changed the guest offline (guest agent, network by driver, first-boot cleanup) and froze the image. I2 booted that exact image in isolation. I3 built the AWS platform. I4 moved the image, imported it with CDI, created the VM and proved it end to end. I5 checked the VM one last time (HTTP 200, the same page hash), then removed the VM, its disk and the AWS platform through their owners and verified the removal: sub-gates I5-A to I5-J all PASS.

Everything on the left runs on one laptop. Everything on the right is one EC2 instance in one public subnet. Only three kinds of traffic cross the Internet, all from the operator's single /32: HTTP to NodePort 30080, the SSH tunnel to the API (TCP 22), and the one-time SFTP transfer in I4. TCP 6443 has no security group rule, so the Kubernetes API is reached only through the SSH tunnel.

Read from the outside in. The VM is not a container: it is a qemu-kvm process inside the compute container of a Pod, and the guest runs its own kernel (6.8, while the node runs 5.14). Kubernetes schedules the Pod. KVM in the node kernel accelerates the vCPUs, nested on AWS Nitro.

One Pod contains everything the VM needs. Its network namespace has the Pod side (eth0, 10.244.0.30), a bridge (k6t-eth0, 10.0.2.1) and tap0, the VM's virtual cable. The compute container runs libvirt (virtqemud, virtlogd) and the qemu-kvm process, which is the VM. The disk arrives as the raw block device /dev/rootdisk. QEMU opens it as a host_device, and the guest sees it as vda. The device list, process list and /dev/rootdisk come from the read-only live check.

The request crosses five zones: Internet, AWS, Kubernetes, the launcher Pod and the guest. 10.244.0.30 is the Pod's address, which Kubernetes uses. 10.0.2.2 is the guest's address, private to that Pod. Masquerade NAT joins the two, so they never conflict. Curling 10.0.2.2 from the jump host proves nothing: that address is not reachable from there, and even inside the Pod such a test would skip the security group, the NodePort and the Service. Only the external curl tests what a client uses.

The golden and prepared files stay on the laptop, immutable, as the rollback point. A temporary copy went to the node. CDI uploaded it and converted it to raw on a 40 GiB Block, RWO, encrypted gp3 volume, and the temporary copy and scratch volume were then deleted. The runtime disk on EBS is writable and changes as the guest runs. RWO is why LiveMigratable=False. Reclaim Delete means removing the PV removes the EBS volume.

What the user sees is unchanged: the same hostname, machine-id, filesystem UUIDs, SSH host keys, nginx package and configuration, and page hash. What the platform supplies changed: the NIC is now enp1s0, plus a new MAC, virtio disk, KubeVirt SMBIOS and the 10.0.2.2 address. The netplan match by driver from I1 is why the new NIC name did not matter. The stock apt timers came along with the image, which is a drift item for I5 or operations to decide.

There are three lanes. The API is reached only through an SSH tunnel to the node's loopback. Headlamp is reached only through two loopback forwards, and logs in with a read-only account. The application is the one public data path, open only to one /32. Everything else is closed: 6443, guest SSH, the CDI upload proxy and Headlamp itself. The transfer key was temporary and is destroyed. The source VM is untouched: this was a point-in-time copy, not a cutover.

Each PASS is backed by checks in the Stage 1I record: 41/41 for I1, 54/54 for I2, a fully healthy platform for I3, 36/36 guest checks plus external HTTP for I4, and 10 of 10 sub-gates for I5 (a final HTTP 200, then a teardown verified in Kubernetes and in AWS). "DataVolume Succeeded" alone proves only that CDI finished writing. The image was proven by the transfer hash, and the guest by boot, identity and HTTP checks.

Three chains tell the whole story. A request enters through one public port and reaches nginx. A disk goes from an immutable file to a block device the guest calls vda. A VM is a Kubernetes object that ends up as one qemu-kvm process. The guest and its content are the same; only the manager changed.