KubeVirt HAL과 라이브 NAD 업데이트로 바뀌는 VM 운영

KubeVirt의 HAL, passt 사용자 공간 네트워킹, 라이브 NAD 업데이트가 Kubernetes 기반 VM 운영에 주는 변화를 정리한다.

2026-08-14 · 최초 발행 2026-04-17

KVM 고정 경로에서 벗어나는 KubeVirt

KubeCon + CloudNativeCon Europe 2026에서 공개된 KubeVirt 1.8은 Kubernetes 위에서 VM을 운영하는 경로에 변화를 더했다. Hypervisor Abstraction Layer(HAL)로 KVM 외 백엔드 지원 가능성을 열고, passt 사용자 공간 네트워킹을 코어로 승격했으며, VM을 재시작하지 않고 NetworkAttachmentDefinition(NAD)을 바꾸는 라이브 업데이트를 도입했다.

KubeVirt는 Kubernetes CRD로 VM 수명주기를 관리하는 Native Virtualization 프로젝트다. VMI(VirtualMachineInstance) CRD로 VM을 Pod 형태로 감싸며, VM은 virt-launcher 컨테이너 내부의 QEMU 프로세스로 실행된다. 하이퍼바이저 호출은 libvirt가 맡고, virt-handler DaemonSet과 CDI(Containerized Data Importer)가 운영 구성에 포함된다.

기존에는 KVM/QEMU 조합이 사실상 유일한 실행 경로였다. HAL이 도입되면서 VMI API와 하이퍼바이저 드라이버의 경계가 명시적으로 분리됐다. 컨테이너와 VM을 하나의 제어 평면에서 관리하려는 환경에서는 이 분리가 이후 백엔드 선택의 기반이 된다.

HAL이 만드는 하이퍼바이저 선택 경로

HAL은 플러그형 드라이버 스펙을 통해 실제 하이퍼바이저 백엔드를 교체할 수 있게 한다. KVM뿐 아니라 Cloud Hypervisor 연계 경로를 제공하고, Firecracker와의 향후 연계 경로도 확보한다.

KVMCloud HypervisorFirecracker (예정)VirtualMachine CRDvirt-controllervirt-handler (Node)Hypervisor AbstractionLayer백엔드 선택libvirt + QEMUcloud-hypervisor 드라이버firecracker 드라이버/dev/kvm

CRD에서 시작한 요청은 virt-handler를 거쳐 HAL에 도달하고, 선택된 드라이버에 따라 각 하이퍼바이저 실행 경로로 이어진다. HAL은 VM Lifecycle, Device Plugin, Migration에 대한 공통 인터페이스를 정의해 드라이버별 기능 격차를 줄이는 역할을 한다.

항목 KubeVirt 1.7 이전 KubeVirt 1.8
하이퍼바이저 KVM/QEMU 고정 HAL 기반 다중 백엔드
사용자 네트워킹 slirp/netbind passt 코어 승격
NAD 변경 VM 재시작 필요 라이브 업데이트
라이브 마이그레이션 동일 노드 유형 전제 드라이버 간 제약 명시화
보안 경계 cap_net_admin 필요 rootless 강화

재시작 없이 NAD 참조를 바꾸는 흐름

라이브 NAD 업데이트는 VMI가 실행 중인 상태에서 NetworkAttachmentDefinition 참조를 변경하는 기능이다. Multus CNI와 함께 네트워크를 재구성하며, SR-IOV와 VLAN 튜닝 변경에 사용할 수 있다.

YesNoNetworkAttachmentDefinition 변경virt-controller WatcherVMI 상태 확인라이브 업데이트 가능?Multus CNI 재바인딩Deferred 재적용 (다음재시작)virt-launcher에 Hot-Plug요청VM 네트워크 재구성 완료

NAD 변경을 감지한 뒤 VMI가 라이브 업데이트를 수용할 수 있는지 확인한다. 가능하다면 Multus CNI를 통해 런타임 네트워크를 재바인딩하고, virt-launcher에 Hot-Plug 요청을 전달한다. QEMU 내부 virtio-net 장치의 Hot-Plug 명령을 안전하게 트리거하는 것이 핵심이며, 상태 머신은 롤백 경로도 보장한다. 수용할 수 없는 변경은 다음 재시작 시점에 재적용된다.

엣지 VNF와 Windows VDI에 적용하는 방식

Telco 엣지 VNF 환경에서는 OpenStack 기반 VNF를 KubeVirt로 재수용하고, 라이브 NAD 업데이트로 SR-IOV VF를 교체할 수 있다. 제어 평면 격리에는 passt를 사용할 수 있다.

레거시 Windows VDI를 Kubernetes에 통합하는 경우에는 HAL을 활용해 GPU 패스스루 드라이버 교체를 쉽게 만들 수 있다. 라이브 NAD 업데이트는 네트워크 정책 핫픽스 적용 경로가 되며, ArgoCD 기반 GitOps에서는 VM 매니페스트와 컨테이너를 동일한 파이프라인으로 배포할 수 있다.

운영 전 확인할 제약과 효과

HAL은 하이퍼바이저 선택권을 넓혀 보안 프로파일을 최적화할 여지를 제공한다. 라이브 NAD 업데이트는 네트워크 변경 위험을 낮추고, passt 사용자 공간 스택은 rootless 운영을 쉽게 만든다. VM과 컨테이너의 이원 운영 비용을 줄이고, 엣지와 리테일 환경에서 라이브 업그레이드가 가능해지며, OpenStack 유지보수 비용을 단계적으로 해소할 수 있다.

다만 Cloud Hypervisor 경로의 라이브 마이그레이션에는 여전히 제한이 있다. 라이브 NAD 업데이트는 Multus 기반 구성이 필요하며, 단일 CNI 구성에는 적용할 수 없다. virt-handler의 신규 메트릭은 Prometheus 알람에 반영해야 한다.

KubeVirt 1.8은 Kubernetes 위 VM 운영을 단일 하이퍼바이저 전제에서 복합 백엔드와 라이브 네트워크 재구성까지 다루는 방향으로 옮긴다. HAL과 라이브 NAD 업데이트는 검증 환경에서 먼저 시험해 도입 영향도를 확인한 뒤 엣지, VDI, VNF 영역에 점진적으로 전개할 수 있다.

Sources

KubeVirtKubernetes가상화네트워킹Multus CNI