[Openstack] Glance - 디스크 포맷별 특징

#1. 디스크 이미지 포맷

1. raw

: 가장 단순한 형태로 디스크를 그대로 파일로 덤프한다. dd if=/dev/sda of=disk.raw 명령과 동일한 결과물이라고 보면 된다.

물리 디스크:  [섹터0][섹터1][섹터2]...[섹터N]
raw 파일:     [섹터0][섹터1][섹터2]...[섹터N]  ← 1:1 복사

• 장점: 구조가 단순하고 변환 없이 바로 사용한다. 오버헤드가 없어 I/O 성능이 좋다. 모든 하이퍼바이저를 지원한다.
• 단점: 압축 없어 파일 크기 매우 크다. 스냅샷과 씬프로비저닝(thin-provisioning, 실제로 사용할 때만 저장 공간을 할당하는 방식)이 불가하다. (100GB 할당하면 실제로 100GB 차지)

2. qcow2

: KVM/QEMU를 위해 설계된 포맷으로 기능이 가장 풍부하다.

• 장점: 압축(zlib), 암호화(AES), 스냅샷, 씬프로비저닝, 백킹 파일을 모두 지원하고 KVM과 완벽하게 호환된다.
• 단점: raw보다 I/O가 약간 느리다는 점인데 이는 meta-data 오버헤드 때문

- 씬프로비저닝: 100GB 할당을 선언하면 실제로는 사용한 만큼만 저장하는 방식이다. 처음엔 200MB짜리 파일이었다가 데이터를 쓸수록 파일 크기가 증가하고 최대 100GB까지만 늘어난다.

- 백킹 파일

ubuntu-22.04.qcow2 (800MB) ← 원본, 절대 변경 안됨
                /        |        \
               /         |         \
    overlay1.qcow2  overlay2.qcow2  overlay3.qcow2
    (VM1 변경분)    (VM2 변경분)    (VM3 변경분)
       50MB            80MB            30MB

VM1이 파일 읽을 때:
  overlay1에 있으면? → overlay1에서 읽음
  overlay1에 없으면? → 원본에서 읽음

총 디스크 사용량: 800 + 50 + 80 + 30 = 960MB
raw였다면:       800MB × 3 = 2.4GB  (또는 50GB × 3 = 150GB)

 

3. vmdk

: VMware가 만든 포맷으로 ESXi, Workstation, Fusion 등 VMware 제품군과 완벽하게 호환되고 VirtualBox도 지원한다.

압축, 스냅샷, 씬프로비저닝도 지원함

• 종류

vmdk 종류:
  monolithicSparse  → 단일 파일, 씬프로비저닝 (일반적)
  monolithicFlat    → 단일 파일, 전체 사전 할당 (raw와 유사)
  twoGbMaxExtent    → 2GB 단위 분할 파일 (구형 FAT32 대응)
  streamOptimized   → 배포/전송 최적화용 압축 포맷

• 단점: KVM에서 사용하려면 변환이 필요해서 OpenStack 기본 환경에서는 비효율적이다.
• vmdk → qcow2 변환 : qemu-img convert -f vmdk -O qcow2 image.vmdk image.qcow2 VMware 환경에서 OpenStack으로 VM 마이그레이션할 때 변환 전 임시 보관용

4. vhd/vhdx

: 진짜 하드디스크를 파일로 만든것으로 VM이 이 파일을 디스크처럼 사용한다. OS, 프로그램, 데이터가 다 저장되어있다.

• 장점: Hyper-V를 완벽하게 지원한다. Azure의 기본 포맷이다. 즉, Azure VM의 디스크는 내부적으로 VHD/VHDX 형식으로 관리됨

vhd → 최대 2TB, 단순 구조, Hyper-V 1세대 VM vhdx → 최대 64TB, 로그 기반 장애 복구, Hyper-V 2세대 VM 전원 장애 시에도 데이터 손상 방지 (저널링)

• 단점: KVM 환경에서 변환이 필요하고 OpenStack에서는 비주류이다.

5. iso

: CD/DVD 내용을 그대로 복사한 파일 (e.g. 윈도우 설치 USB / 리눅스 설치 CD를 파일로 만든 것)

OS 설치용으로 부팅 가능한 미디어를 생성한다. 하지만 VM 디스크로 직접 사용이 불가하고 읽기 전용이다.

⇒ vhd/vhdx와 iso: ISO로 OS 설치 시작 (설치 대상은 VHD/VHDX), 설치가 끝나면 VHD 안에 OS가 들어간다.

 

6. 전체 흐름

OpenStack에서의 흐름:
  ① ISO를 Glance에 업로드
  ② VM 생성 시 빈 qcow2 볼륨 + ISO를 CD-ROM으로 마운트
  ③ VM 부팅 → ISO로 OS 설치
  ④ 설치 완료 후 ISO 언마운트
  ⑤ 완성된 qcow2 볼륨을 새 이미지로 Glance에 등록

 

7. 기타

ploop: Virtuozzo(구 Parallels)가 OS 컨테이너용으로 개발한 포맷

일반 VM 이미지와 달리 OS 컨테이너 전용, Virtuozzo 환경 외에서는 거의 사용되지 않음, 씬프로비저닝, 스냅샷 지원

vdi (Virtual Disk Image): Oracle VirtualBox와 QEMU가 지원하는 포맷

VirtualBox의 기본 디스크 포맷, QEMU에서도 읽기/쓰기 가능 씬프로비저닝, 스냅샷 지원, OpenStack 운영 환경에서는 거의 사용 X

 

8. AKI / ARI / AMI 포맷 (Amazon 계열)

Amazon EC2의 초기 이미지 포맷으로 이미지가 3개 파일로 분리된 구조.

AMI (Amazon Machine Image)
  → 실제 VM 디스크 이미지 (raw 포맷)
  → OS, 데이터 등이 담긴 루트 파일시스템

AKI (Amazon Kernel Image)
  → 하이퍼바이저가 처음 로드하는 커널 파일
  → Linux 기준: vmlinuz 파일

ARI (Amazon Ramdisk Image)
  → 부팅 시 마운트되는 초기 램디스크 (선택적)
  → Linux 기준: initrd 파일

부팅 순서:
  AKI(커널) 로드 → ARI(initrd) 마운트 → AMI(루트 디스크) 마운트

현재:
  AWS가 자체적으로 HVM 방식으로 전환하면서
  단일 이미지(AMI 하나)로도 부팅 가능해져 AKI/ARI는 구식이 됨
  OpenStack에서도 거의 사용하지 않음

 

왜 qcow2가 가장 많이 쓰이는가?

이유 1. KVM/QEMU와 매칭

OpenStack 기본 하이퍼바이저 = KVM KVM 기본 이미지 포맷 = qcow2

1. 변환 없이 바로 사용 가능
2. libvirt/KVM의 이미지 캐시, backing file 기능과 자연스럽게 연동
3. Nova가 VM 생성 시 qcow2 기반 backing file 체인을 자동으로 구성

이유 2. 씬프로비저닝으로 스토리지 절약

시나리오: VM 100개, 각 50GB 디스크

raw 사용 시: 100 × 50GB = 5,000GB 필요 (즉시!) qcow2 사용 시: 실제 사용량만큼만 차지 → 초기엔 100 × 500MB = 50GB 정도 ⇒ 스토리지 비용 절감 효과

 

이유 3. 백킹 파일(Base Image) 활용

raw: VM 생성 시 50GB 이미지를 통째로 복사 → 수 분 소요 qcow2: backing file 참조만 생성 → 수 초 내 완료

Nova의 이미지 캐싱 전략:

① 컴퓨트 노드에 Base Image를 한 번만 다운로드

② 이후 VM 생성은 overlay(변경분) 파일만 새로 만들어 연결

③ 수십 개 VM을 동일 Base Image로 수 초 만에 생성 가능

Base Image (Ubuntu 22.04) - qcow2
         ↓ 복사 없이 참조!
┌────────┬────────┬────────┐
│ VM1    │ VM2    │ VM3    │
│(변경분)  │(변경분)  │(변경분) │
└────────┴────────┴────────┘

→ 기본 OS 이미지 하나를 여러 VM이 공유하여 VM 생성 속도가 빠름
→ 스토리지 절약

 

이유 4. 스냅샷 생성이 빠름

raw 스냅샷: 전체 디스크 복사 → 50GB면 50GB 복사 ⇒ 시간 오래 걸림, 공간 2배 필요

qcow2 스냅샷: 현재 L1/L2 테이블 상태를 메타데이터로 기록

→ 거의 즉시 이후 변경분만 새 클러스터에 기록: 스냅샷 공간 = 변경된 블록만큼만

 

이유 5. 압축으로 이미지 배포 효율화

raw Ubuntu 이미지: 20GB, qcow2 압축 이미지: 800MB ⇒ Glance 저장 공간 절약, 네트워크 전송 빠름, 이미지 배포 효율 극대화

 

이유 6: 라이브 마이그레이션과의 궁합

OpenStack 운영 중 VM을 다른 컴퓨트 노드로 이동할 때
qcow2의 backing file 체인 구조가 유리:

  1. 공유 스토리지 없는 환경:
    qcow2 overlay(변경분)만 전송 → 전송량 최소화

  2. Ceph RBD 사용 시:
    raw 포맷 + Ceph의 자체 스냅샷/씬프로비저닝 활용
    → 이 경우에 한해 raw가 더 나을 수 있음