KubeVirt 라이브 마이그레이션 실측 1: 게스트는 0.34초 멈췄는데 서비스는 2.4초 끊겼다

상태: 실측 (2026-10-31). TT Lab 실습 VM 세 대 안에 쿠버네티스와 KubeVirt v1.9.0 을 세운 중첩 클러스터에서 잰 값입니다. 기본 시험은 다섯 번, 막히는 조건과 CPU 모델 시험은 조건마다 한 번씩입니다. 숫자는 모두 마이그레이션 한 건마다 남긴 원자료(VMIM 단계 기록, libvirt 작업 정보, 탐침 기록)에서 뽑았습니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」, 원인을 확인하지 못한 해석은 「추정」 으로 표시합니다.

목차

• 1. 결론부터
• 2. 라이브 마이그레이션이 하는 일
• 3. 측정 환경과 방법
• 4. 기본 실측: 부하 없는 1Gi VM 다섯 번
  • 4.1 왜 0.34초 멈춤이 2.4초 끊김이 되나
• 5. 옮겨지지 않는 조건
  • 5.1 RWO 는 저장소가 NFS 여도 막힌다
  • 5.2 containerDisk 와 ctr 의 함정
  • 5.3 실패까지 걸리는 시간
• 6. CPU 모델: 어느 노드끼리 옮길 수 있나
  • 6.1 섞인 하드웨어에서는 어떻게 되나
  • 6.2 내 노드에서 확인하는 법
• 7. 정리

1. 결론부터

노드를 고치거나 커널을 올리려면 그 노드의 VM 을 어딘가로 옮겨야 합니다. KubeVirt 는 이것을 라이브 마이그레이션으로 합니다. 게스트를 끄지 않고 메모리를 다른 노드로 복사한 뒤 아주 짧게 멈췄다가 새 노드에서 이어서 돌립니다. 문서만 읽으면 「거의 끊기지 않는다」 로 들리는데, 직접 옮겨 보니 조건이 꽤 많았습니다.

• 게스트 멈춤과 서비스 끊김은 다른 숫자입니다. 부하 없는 1Gi VM 다섯 번에서 libvirt 가 잰 멈춤은 중앙값 343ms 였지만, Service 를 거친 새 연결은 중앙값 2.4초 동안 응답이 없었고 유지하던 TCP 연결은 다섯 번 모두 끊겼습니다.
• 옮겨지지 않는 VM 이 생각보다 많습니다. 디스크가 RWO 면 저장소가 NFS 여도 막히고, local-path·hostDisk·pod 네트워크 bridge 도 막힙니다. containerDisk 는 옮겨지지만 노드에 이미지를 ctr 로 받아 두었다면 15분을 기다린 뒤 실패합니다.
• LiveMigratable: True 는 CPU 를 보지 않습니다. 기본값 host-model 은 원본 노드의 CPU 기능을 대상에게 전부 요구해서, 같은 이름으로 보이는 노드끼리도 기능 한두 개 차이로 5분 뒤 실패했습니다. 섞인 하드웨어에서는 이름 붙은 CPU 모델을 정해 두는 것이 답이었습니다.

메모리를 바쁘게 쓰는 VM, 노드 비우기(drain), 동시 마이그레이션 한도는 2편에서 봅니다.

2. 라이브 마이그레이션이 하는 일

KubeVirt 에서 VM 은 노드 위의 파드(virt-launcher) 안에서 도는 QEMU 프로세스입니다. 파드는 다른 노드로 「옮길」 수 없으므로, KubeVirt 는 대상 노드에 새 파드를 하나 더 띄우고, 게스트의 상태를 그쪽으로 복사한 뒤, 원래 파드를 끝내는 방식으로 옮깁니다. 이 과정을 시작하는 객체가 VirtualMachineInstanceMigration(줄여서 VMIM)입니다. virtctl migrate 도 이 객체를 하나 만들 뿐입니다.

1. 대상 파드 준비. virt-controller 가 대상 노드에 virt-launcher 파드를 새로 만듭니다. 이 파드의 QEMU 는 게스트 없이 「들어올 마이그레이션」 을 기다립니다. 실측에서는 VMIM 을 만든 뒤 대상 파드가 준비되기까지 2–4초가 걸렸습니다. 대상 파드를 스케줄할 수 없으면 여기서 멈춥니다(5·6절).
2. 사전 복사(pre-copy). 원본 쪽 QEMU 가 게스트 메모리를 보냅니다. 게스트는 그동안 계속 돌기 때문에 이미 보낸 페이지를 다시 고칩니다. 그래서 1회차에는 전체를, 다음 회차부터는 그사이 바뀐(더러워진) 페이지만 다시 보냅니다. 0 으로 찬 페이지는 거의 보내지 않아서 1.016GiB 게스트에서 실제로 보낸 양은 456MiB 였습니다. 반복은 3–4회, 속도는 약 88MiB/s 였습니다.
3. 멈추고 마지막 복사(stop-and-copy). 남은 양을 목표 시간 안에 보낼 수 있게 되면 게스트를 멈추고 남은 페이지와 CPU 상태를 보냅니다. 이때가 게스트가 실제로 멈춘 시간이고 libvirt 가 Total downtime 으로 적습니다. KubeVirt v1.9 는 목표를 300ms 에서 시작해 진행이 막히면 조금씩 올립니다(상한 maxDowntimeMs 기본 900ms).
4. 대상에서 재개. 대상 QEMU 가 게스트를 이어서 돌리고 원본 파드는 끝납니다. 디스크는 옮기지 않습니다. 두 파드가 같은 PVC 를 동시에 붙이기 때문인데, 그래서 PVC 가 여러 노드에서 함께 붙을 수 있는 RWX(ReadWriteMany)여야 합니다(5절).

메모리를 보내는 데이터는 두 노드의 virt-handler 파드 사이, 즉 파드 네트워크로 흐릅니다. 따로 마이그레이션 전용 망을 주지 않으면 서비스 트래픽과 같은 선을 나눠 씁니다.

3. 측정 환경과 방법

재는 방법은 셋입니다.

• VMIM 단계: 0.5초마다 VMIM 의 단계(Pending → Scheduling → Scheduled → PreparingTarget → TargetReady → Running → Succeeded)를 적었습니다.
• libvirt 가 잰 값: 끝난 뒤 대상 파드에서 virsh domjobinfo --completed 로 경과 시간, 멈춤(Total downtime), 보낸 양, 반복 횟수를 읽었습니다. 실제로 적용된 설정은 VMI 의 status.migrationState.migrationConfiguration 에서 읽었습니다.
• 바깥에서 본 끊김: 게스트 안에 에코 서버(ncat -lk 7777 --exec /bin/cat)를 띄우고, 컨트롤 플레인에서 VMI 를 고르는 ClusterIP Service 로 20ms 마다 두드렸습니다. 매번 새로 맺는 연결(새 연결)과 하나를 계속 쓰는 연결(유지 연결) 두 가지이고, 시도마다 200ms 안에 답이 없으면 실패로 셉니다. 「끊김」 은 가장 긴 연속 실패 구간입니다.

한 번 세우는 데 걸린 시간도 적어 둡니다. VM 셋 준비 276초, csi-driver-nfs 52초, KubeVirt Available 122초, CDI Available 91초, Fedora 바탕 디스크 가져오기 193초였습니다. CDI 가져오기에서 한 번 걸렸는데, csi-driver-nfs 에 mountPermissions 를 주지 않으면 볼륨 폴더가 root 0755 라 가져오기 파드(uid 107)가 permission denied 로 끝없이 재시작합니다. NFS 는 fsGroup 으로 소유권을 바꿔 주지 않으므로 StorageClass 에 mountPermissions: "0777" 를 주어 풀었습니다.

4. 기본 실측: 부하 없는 1Gi VM 다섯 번

Fedora VM(1Gi, RWX, masquerade, evictionStrategy: LiveMigrate)을 두 워커 사이에서 다섯 번 왕복했습니다. 마이그레이션 정책은 두지 않았습니다(기본값). CPU 는 두 워커가 함께 낼 수 있는 이름 모델 Skylake-Client-v4 로 고정했습니다. 왜 그래야 했는지는 6절에서 봅니다.

VMIM 을 만든 뒤 끝날 때까지 약 10초가 걸렸고, 그중 실제 복사(libvirt 경과)는 6.4초였습니다. 나머지는 대상 파드를 스케줄하고 띄우는 시간(1–2초), 대상 준비(0–2초), 끝난 뒤 상태를 정리하는 시간입니다.

4.1 왜 0.34초 멈춤이 2.4초 끊김이 되나

KubeVirt 의 기본 네트워크 바인딩인 masquerade 에서 게스트는 파드 뒤에 숨어 있습니다. 바깥에서 보이는 주소는 virt-launcher 파드의 IP 이고, 파드 안에서 NAT 로 게스트에 넘깁니다. 그런데 2절에서 본 것처럼 마이그레이션은 새 파드를 만들어 옮기는 일이라, 끝나고 나면 게스트를 감싼 파드가 바뀌고 파드 IP 도 바뀝니다.

• 유지하던 연결이 끊기는 이유. 원래 파드 A 를 거쳐 맺은 TCP 연결의 NAT 상태는 파드 A 의 네트워크 안에 있습니다. 파드 A 가 끝나면 그 상태도 사라집니다. 다섯 번 모두 유지 연결이 시간 초과로 끊겼고, 다시 맺은 연결은 됐습니다.
• 새 연결도 한동안 갈 곳이 없는 이유(추정). Service 의 엔드포인트가 파드 A 에서 파드 B 로 넘어가고 각 노드의 규칙에 반영될 때까지는, 멈춤이 끝난 뒤에도 새 연결이 닿지 않습니다. 탐침 기록에서 실패 구간은 VMIM 이 Succeeded 로 보이기 약 1초 전에 시작해 그 뒤 1–3초 이어졌습니다. 멈춤 0.34초를 뺀 나머지가 엔드포인트 전환에 쓰인 시간이라고 보지만, 엔드포인트가 바뀐 시각을 따로 찍지는 않았습니다(미실측).

그러니 「라이브 마이그레이션이라 끊기지 않는다」 를 믿고 설계하면 안 됩니다. 클라이언트가 끊긴 연결을 다시 맺고, 몇 초짜리 실패를 재시도로 견디게 만들어 두어야 합니다. masquerade 가 아닌 바인딩(Multus 로 붙인 별도 망 등)에서 같은 값을 재지는 않았습니다(미실측).

5. 옮겨지지 않는 조건

VMI 의 상태에는 LiveMigratable 조건이 있습니다. False 면 그 이유가 함께 나오고, VMIM 을 만들려고 하면 승인 웹훅이 생성 자체를 거절합니다. cirros VM 으로 조건마다 실제로 만들어 보았습니다.

5.1 RWO 는 저장소가 NFS 여도 막힌다

KubeVirt 는 저장소가 실제로 여러 노드에서 붙을 수 있는지를 보지 않고 PVC 의 접근 모드만 봅니다. 저장소가 NFS 라 원래 공유가 되더라도 PVC 를 RWO 로 만들었다면 옮길 수 없습니다. 실제 환경을 읽기만으로 점검해 보니 기존 VM 이 바로 이 경우였습니다. 저장소의 StorageProfile 은 RWX 를 낼 수 있는데 VM 을 만드는 코드가 PVC 를 RWO 로 적고 있어서 모두 LiveMigratable: False 였습니다. 옮길 수 있게 하려면 루트 디스크를 RWX PVC 로 다시 만들어야 합니다 (VM 을 끄고 RWX 로 복제해 바꾸거나, v1.9 의 볼륨 마이그레이션). 볼륨 마이그레이션은 이번에 재지 않았습니다(미실측). 접근 모드와 볼륨 모드 이야기는 학생 VM 이 뜨기까지 3편에 더 자세히 있습니다.

5.2 containerDisk 와 ctr 의 함정

containerDisk(디스크를 컨테이너 이미지로 받는 방식)는 옮겨집니다. 쓰기 층을 함께 보내는 블록 마이그레이션(BlockMigration)으로 처리됩니다. 그런데 폐쇄망처럼 이미지를 노드에 미리 넣어 두는 환경에서는 함정이 있었습니다.

• 노드에서 ctr 로 받거나 ctr images import 로 반입한 이미지는 CRI 에서 저장소 digest(repoDigests)가 비어 있고, 원본 파드의 imageID 가 sha256:<설정 digest> 만 남습니다.
• KubeVirt 는 대상 파드의 이미지를 「원본과 같은 digest」 로 고정하려고 imageID 의 sha256 값을 그대로 붙여 <저장소>@sha256:<값> 을 만듭니다. 이 값은 저장소에 없는 참조라, 대상 파드는 NotFound·ImagePullBackOff 에 빠지고 VMIM 은 15분 4초 동안 Scheduling 에 머물다 실패했습니다.
• 같은 이미지를 crictl pull(CRI 경로)로 다시 받아 repoDigests 를 채운 뒤 새로 띄운 VM 은 옮겨졌습니다.

이 동작은 업스트림에 이슈로 올렸습니다(kubevirt#19694). 그 전까지는 미리 넣는 이미지를 crictl pull 로 받거나, 반입 뒤 crictl inspecti 로 repoDigests 가 채워졌는지 확인하는 것이 안전합니다.

5.3 실패까지 걸리는 시간

막히는 곳에 따라 기다리는 시간이 크게 다릅니다. 웹훅이 거절하는 조건은 즉시 알 수 있지만, 대상 파드를 스케줄하지 못하면 5분, 대상 파드는 떴는데 이미지를 못 받으면 15분 뒤에야 Failed 가 됩니다. 기다리지 않으려면 VMIM 을 지우면 취소됩니다.

6. CPU 모델: 어느 노드끼리 옮길 수 있나

게스트는 처음 부팅할 때 본 CPU 기능을 계속 쓴다고 믿습니다. 옮겨 간 노드에 그 기능이 없으면 게스트가 죽을 수 있으니, KubeVirt 는 대상 파드에 노드 선택자를 붙여 기능이 맞는 노드에만 스케줄합니다. 노드마다 붙는 CPU 라벨(cpu-model.node.kubevirt.io/…, cpu-feature.node.kubevirt.io/…, cpu-model-migration.node.kubevirt.io/…)은 virt-handler 의 노드 라벨러가 답니다.

두 워커가 CPU 세대가 다른 인텔 호스트(family 6 의 model 151 과 170) 위에 있어서, 같은 조건을 그대로 시험할 수 있었습니다. 노드 라벨러는 두 워커에 같은 host-model 이름을 붙였지만 필수 기능은 달랐습니다. 한쪽에만 rfds-clear, 다른 쪽에만 ddpd-u·rfds-no 가 있었습니다.

여기서 읽을 것이 셋입니다.

1. LiveMigratable 은 CPU 호환을 계산하지 않습니다. host-model VM 은 True 였지만 옮길 자리가 없었고, 대상 파드가 5분 동안 Pending 이다가 unschedulable pod … timeout period exceeded 로 끝났습니다.
2. host-model 의 대상 조건은 「원본과 같은 host-model 이름 + 원본 노드의 필수 기능 전부」 입니다. 이름이 같아도 기능 하나가 모자라면 안 됩니다. 그리고 host-model 이름은 「가장 가까운 이름 모델」 일 뿐이라 세대를 알려 주지 않습니다. 세대가 다른 두 호스트가 같은 이름을 받았습니다.
3. host-passthrough 는 공급사만 봅니다. 그래서 세대가 다른 노드로도 옮겨졌습니다. 이번 게스트는 대상에 없는 기능(ddpd-u·rfds-no 등)을 본 상태였으니, 그 기능을 실제로 쓰는 프로그램이었다면 위험했습니다. passthrough 는 CPU 가 완전히 같은 노드끼리만 써야 합니다.

이 관계는 사용자 가이드에 정리돼 있지 않아, 그 절을 더하는 문서 PR 을 올렸습니다(user-guide#1052).

6.1 섞인 하드웨어에서는 어떻게 되나

같은 규칙(위 host-model 선택자가 실측으로 확인해 준 규칙)을, 인텔 노드 넷과 AMD 노드 하나가 섞인 실제 노드들의 라벨에 적용해 계산해 보았습니다. 노드 이름을 빼고 쌍의 종류로 묶으면 이렇습니다.

• host-model 로는 CPU 가 완전히 같은 쌍만 됩니다. 다섯 대 중 그런 쌍은 하나였습니다. 「같은 제품군이니 되겠지」 가 통하지 않았고, 차이는 보안 완화·프리페처 제어처럼 눈에 잘 띄지 않는 기능 비트 한두 개였습니다.
• 이름 모델을 정하면 넓어집니다. 인텔 넷이 함께 낼 수 있는 이름 모델은 31개였고, 그중 Skylake-Client-v4·Skylake-Client-noTSX-IBRS· Broadwell-noTSX-IBRS·Haswell-noTSX-IBRS 처럼 AVX2 를 지키는 모델이 있습니다. AMD 까지 다섯 대가 함께 내는 모델은 IvyBridge·SandyBridge· Westmere·Nehalem·Penryn(각 -v1 포함) 10개뿐이라 AVX2 를 잃습니다. 공급사가 섞이면 「옮길 수 있음」 과 「게스트 성능」 을 맞바꾸게 됩니다.
• 실제로는 하드웨어 말고도 고려할 것이 있습니다. 메모리가 작은 노드, 장치 패스스루로 묶인 노드는 받는 쪽에서 빼는 것이 맞고, 그러면 쓸 수 있는 쌍은 더 줄어듭니다.

이 표는 라벨 계산입니다. 중첩 시험에서 확인한 것은 「host-model 이름만 같은 두 대」 줄 하나입니다.

6.2 내 노드에서 확인하는 법

두 노드의 CPU 기능 라벨을 비교하면 host-model VM 이 옮겨질지 미리 알 수 있습니다.

diff <(kubectl get node A -o json | jq -r '.metadata.labels|keys[]|select(startswith("cpu-feature."))') \
     <(kubectl get node B -o json | jq -r '.metadata.labels|keys[]|select(startswith("cpu-feature."))') \
  && echo "A·B CPU 기능 같음"

두 노드가 함께 낼 수 있는 이름 모델은 cpu-model.node.kubevirt.io/ 로 시작하는 라벨의 교집합입니다. 섞인 노드에서 옮길 VM 은 그중 하나를 spec.domain.cpu.model 에 적거나, KubeVirt CR 의 spec.configuration.cpuModel 로 클러스터 기본값을 바꿉니다.

7. 정리

이 글의 실측은 TT Lab 의 실습 코스 「KubeVirt 라이브 마이그레이션」(사이트 경로 /course/kubevirt-live-migration)에서 그대로 따라 해 볼 수 있습니다. 같은 VM 셋과 같은 판으로 공유 스토리지, KubeVirt, 공통 CPU 모델 고르기, 옮기고 멈춤 시간 읽기, RWO 거절 읽기, drain 순서를 밟습니다. KubeVirt 의 구조가 처음이라면 학생 VM 이 뜨기까지와 KubeVirt 소스 코드 읽기 시리즈가 바탕이 됩니다.

티티 한마디. 이사하는 동안 손님이 문 앞에서 기다린 시간은 0.34초였는데, 손님은 2.4초 동안 초인종이 안 된다고 했어요. 집 주소(파드 IP)가 바뀌었거든요! 그리고 이삿짐 트럭은 「같은 동네(CPU 기능)」 로만 가요. 이름만 비슷한 동네는 도착해서야 길이 없다는 걸 알게 되니, 미리 지도를 맞춰 두세요.