가상화와 QEMU/KVM · 디스크 이미지: qcow2, 백킹파일, 스냅샷 · 이론

qcow2 와 백킹 체인

LabHub 에서 이어서 보기

한 줄 요약

qcow2 의 진짜 힘은 압축이나 암호화가 아니라 백킹 파일이다. 골든 이미지 하나 위에 얇은 오버레이를 얹어 VM 수십 대를 만들 수 있다.

왜 이게 필요했나

VM 100대를 띄워야 한다. 각각 20GB 디스크가 필요하다. 그대로 하면 2TB 다. 그런데 그 100대는 같은 OS 이미지에서 출발하고, 실제로 달라지는 부분은 대당 몇백 MB 다.

qcow2 의 백킹 파일이 이 문제를 푼다. 읽기는 백킹 파일에서, 쓰기는 오버레이에만. 100대가 20GB 골든 이미지 하나를 공유하고 각자는 변경분만 갖는다.

어떻게 동작하나

기본 조작

qemu-img create -f qcow2 base.qcow2 20G        # 씬 프로비저닝: 실제 점유는 거의 0qemu-img info base.qcow2qemu-img info --output=json base.qcow2         # 스크립트로 파싱하기 좋다qemu-img convert -f raw -O qcow2 in.raw out.qcow2qemu-img check base.qcow2

qemu-img info 에서 봐야 할 두 값이 있다.

virtual size — 게스트가 보는 크기
disk size — 실제로 호스트 디스크를 먹는 크기

둘의 차이가 씬 프로비저닝이다. 갓 만든 20G 이미지의 disk size 는 200KB 정도다. 모니터링에서 virtual size 만 보면 오버커밋을 놓친다. 호스트 디스크가 500GB 인데 virtual size 합계가 2TB 인 상황은 정상적으로 성립하고, 게스트들이 실제로 채우기 시작하면 그때 터진다.

백킹 파일

qemu-img create -f qcow2 -b /var/lib/libvirt/base.qcow2 -F qcow2 vm01.qcow2qemu-img info --backing-chain vm01.qcow2

-F 로 백킹 파일의 포맷을 명시해야 한다. 예전에는 생략 가능했지만 지금은 경고가 나거나 거부된다. 포맷을 추측하게 두는 것이 보안 문제가 될 수 있기 때문이다.

백킹 체인에는 규칙이 있다.

1. 백킹 파일은 절대 수정하면 안 된다. 오버레이는 "백킹의 이 블록은 안 바뀌었다" 를 전제로 하므로, 백킹이 바뀌면 오버레이들이 조용히 깨진다. 골든 이미지는 읽기 전용으로 두는 것이 관례다.
2. 경로가 이미지 안에 기록된다. 백킹 파일을 옮기면 오버레이가 못 찾는다. qemu-img rebase -u -b <새경로> <오버레이> 로 기록만 고칠 수 있다(-u 는 unsafe — 데이터를 실제로 옮기지 않고 참조만 바꾼다).
3. 체인이 길어지면 읽기 성능이 떨어진다. 블록 하나를 찾기 위해 여러 파일을 거슬러 올라가야 한다. qemu-img convert 로 평탄화(flatten)하는 것이 정기 정비 항목이다.

스냅샷 두 종류

내부 스냅샷(internal) — qcow2 파일 안에 여러 시점을 함께 담는다.

qemu-img snapshot -c before-upgrade disk.qcow2   # 생성qemu-img snapshot -l disk.qcow2                  # 목록qemu-img snapshot -a before-upgrade disk.qcow2   # 적용(되돌리기)qemu-img snapshot -d before-upgrade disk.qcow2   # 삭제

파일 하나로 관리되어 편하지만, 파일이 커지고 VM 이 켜져 있는 동안에는 qemu-img 로 건드리면 안 된다(실행 중 이미지 변경은 손상을 부른다). 실행 중 스냅샷은 QEMU 모니터나 libvirt 를 통해야 한다.

외부 스냅샷(external) — 현재 이미지를 백킹으로 삼는 새 오버레이를 만든다.

qemu-img create -f qcow2 -b disk.qcow2 -F qcow2 disk.snap1.qcow2

원본은 그 시점에 얼어붙고 이후 쓰기는 새 파일로 간다. 백업 도구가 원본을 안전하게 복사할 수 있어 백업 워크플로에서 표준이다. 되돌리기는 오버레이를 버리는 것으로 끝난다. 대신 파일이 늘어나고 체인 관리가 필요하다.

| 항목 | 내부 스냅샷 | 외부 스냅샷 |
| --- | --- | --- |
| 파일 개수 | 1개 | 시점마다 1개 |
| 되돌리기 | -a | 오버레이 삭제 |
| 백업 친화성 | 낮음 | 높음 (원본이 고정됨) |
| 실행 중 생성 | 모니터/libvirt 필요 | 모니터/libvirt 필요 |
| 체인 관리 | 불필요 | 필요 |

cluster_size

qcow2 의 할당 단위다. 기본 64KB.

qemu-img create -f qcow2 -o cluster_size=1M big.qcow2 100G

크게 잡으면 메타데이터가 줄어 순차 I/O 에 유리하고, 작게 잡으면 랜덤 쓰기에서 낭비가 줄어든다. 대용량 이미지에서 1M 로 올리는 것이 흔한 튜닝이다.

현장에서 만나는 모습

백킹 파일을 실수로 수정해 VM 수십 대가 깨지는 사고. 골든 이미지에 패치를 적용하려고 직접 부팅한 순간, 그 위에 얹힌 모든 오버레이가 일관성을 잃는다. 패치는 골든 이미지의 사본을 만들어 거기에 적용하고 새 세대로 배포해야 한다.

호스트 디스크가 갑자기 가득 차는 사고. 씬 프로비저닝된 이미지들이 동시에 커지면 호스트가 먼저 죽는다. VM 은 디스크 오류를 만나고 파일시스템이 깨진다. virtual size 합계와 실제 여유 공간을 함께 감시해야 한다.

다음 실습에서 할 것

qcow2 를 만들고 정보를 읽고 변환하고, 백킹 체인을 세우고, rebase 로 경로를 고친다. 이어지는 실습에서는 내부/외부 스냅샷을 모두 다뤄 비교표를 만든다.