Skip to content

Split View: OpenStack & KVM 가상화 완전 가이드 2025: 프라이빗 클라우드 구축부터 운영까지

✨ Learn with Quiz
|

OpenStack & KVM 가상화 완전 가이드 2025: 프라이빗 클라우드 구축부터 운영까지

목차

1. 가상화 기초: 왜 가상화인가?

1.1 가상화의 정의와 역사

가상화(Virtualization)는 물리적 하드웨어 위에 여러 개의 격리된 가상 환경을 만드는 기술이다. 1960년대 IBM 메인프레임에서 시작된 이 기술은 2000년대 x86 가상화의 대중화와 함께 현대 클라우드 컴퓨팅의 핵심 기반이 되었다.

가상화가 필요한 이유:

  • 서버 통합: 물리 서버 활용률을 10-15%에서 60-80%로 향상
  • 비용 절감: 하드웨어 구매, 전력, 냉각, 공간 비용 대폭 감소
  • 민첩성: 수분 내 새 서버 프로비저닝 (물리 서버는 수주 소요)
  • 격리: 워크로드 간 보안 격리, 장애 격리
  • 재해복구: 스냅샷, 라이브 마이그레이션으로 빠른 복구

1.2 Type-1 vs Type-2 하이퍼바이저

하이퍼바이저는 가상 머신을 생성하고 관리하는 소프트웨어 계층이다.

Type-1 (Bare-Metal) 하이퍼바이저:

하드웨어 위에 직접 설치되어 실행된다. 호스트 OS가 필요 없어 오버헤드가 적고 성능이 우수하다.

  • KVM: Linux 커널 모듈로 동작. 리눅스 자체가 하이퍼바이저 역할
  • VMware ESXi: 엔터프라이즈 표준. vSphere 에코시스템
  • Xen: AWS EC2의 초기 기반. Citrix에서 관리
  • Microsoft Hyper-V: Windows Server에 내장

Type-2 (Hosted) 하이퍼바이저:

기존 OS 위에 애플리케이션으로 설치된다. 개발/테스트 환경에 적합하다.

  • VirtualBox: Oracle의 오픈소스 솔루션. 크로스 플랫폼
  • VMware Workstation/Fusion: 데스크톱 가상화
  • Parallels Desktop: macOS 전용

1.3 가상화 방식 비교

+--------------------------------------------------+
|        가상화 방식 비교                              |
+--------------------------------------------------+
| 전가상화 (Full Virtualization)                     |
|   - 게스트 OS 수정 없이 실행                         |
|   - Binary Translation으로 특권 명령 처리             |
|   - 성능 오버헤드 있음                               |
+--------------------------------------------------+
| 반가상화 (Para-virtualization)                     |
|   - 게스트 OS 커널 수정 필요 (Hypercall)              |
|   - Xen이 대표적                                   |
|   - 성능 우수하나 호환성 제한                          |
+--------------------------------------------------+
| 하드웨어 지원 가상화 (HW-assisted)                    |
|   - Intel VT-x / AMD-V                           |
|   - 게스트 OS 수정 불필요 + 높은 성능                   |
|   - KVM이 이 방식 활용                               |
+--------------------------------------------------+

1.4 하이퍼바이저 비교표

구분KVMVMware ESXiXenHyper-V
유형Type-1Type-1Type-1Type-1
라이선스오픈소스 (GPL)상용 (무료 에디션 있음)오픈소스 (GPL)Windows 포함
호스트 OSLinux독립 커널독립 커널Windows Server
성능우수우수우수양호
GPU 패스스루지원 (VFIO)지원 (vGPU)제한적지원 (DDA)
라이브 마이그레이션지원vMotion지원Live Migration
관리 도구libvirt, OpenStackvCenterXenCenterSCVMM
생태계방대 (Linux)가장 큰 엔터프라이즈축소 중Windows 생태계
엣지 배포용이무거움가능제한적

1.5 컨테이너 vs 가상 머신

  가상 머신 (VM)                  컨테이너 (Container)
+------------------+           +------------------+
|   App A | App B  |           | App A  |  App B  |
+------------------+           +------------------+
| Guest  | Guest   |           | Bins/  | Bins/   |
|  OS    |  OS     |           | Libs   | Libs    |
+------------------+           +------------------+
|   Hypervisor     |           | Container Engine  |
+------------------+           +------------------+
|   Host OS        |           |   Host OS         |
+------------------+           +------------------+
|   Hardware       |           |   Hardware        |
+------------------+           +------------------+
구분가상 머신컨테이너
격리 수준강함 (하드웨어 수준)약함 (커널 공유)
시작 시간수십 초 ~ 수 분밀리초 ~ 초
리소스 오버헤드높음 (각 VM에 전체 OS)낮음 (커널 공유)
이미지 크기GB 단위MB 단위
밀도10-50 VM/서버100-1000 컨테이너/서버
보안강력한 격리gVisor, Kata로 강화 가능
사용 사례이기종 OS, 레거시 앱, 높은 격리마이크로서비스, CI/CD, 스케일아웃

언제 VM을 선택하는가:

  • 서로 다른 OS 실행이 필요할 때 (Windows + Linux)
  • 강력한 보안 격리가 필수일 때 (멀티테넌트)
  • 레거시 애플리케이션 운영
  • 커널 수준 커스터마이징 필요

언제 컨테이너를 선택하는가:

  • 동일 OS에서 많은 인스턴스 실행
  • 빠른 스케일링 필요
  • CI/CD 파이프라인
  • 마이크로서비스 아키텍처

2. KVM/QEMU 심층 분석

2.1 KVM 아키텍처

KVM(Kernel-based Virtual Machine)은 Linux 커널 2.6.20부터 포함된 하이퍼바이저 모듈이다. Linux 자체를 Type-1 하이퍼바이저로 변환한다.

+--------------------------------------------------+
|              Guest VM (VMLinux 프로세스)       |
|  +-----------+  +-----------+  +-----------+      |
|  | Guest OS  |  | Guest OS  |  | Guest OS  |      |
|  +-----------+  +-----------+  +-----------+      |
|  |   QEMU    |  |   QEMU    |  |   QEMU    |      |
|  | (userspace)|  | (userspace)|  | (userspace)|    |
+--------------------------------------------------+
|              Linux Kernel                         |
|  +------+  +-------+  +--------+  +---------+    |
|  | KVM  |  | sched |  | memory |  | network |    |
|  |module |  |       |  | mgmt   |  | stack   |    |
|  +------+  +-------+  +--------+  +---------+    |
+--------------------------------------------------+
|              Hardware                             |
|  +----------+  +-------+  +--------+             |
|  | CPU      |  | RAM   |  | NIC    |             |
|  | VT-x/SVM |  |       |  |        |             |
|  +----------+  +-------+  +--------+             |
+--------------------------------------------------+

동작 원리:

  1. KVM 커널 모듈(kvm.ko, kvm-intel.ko 또는 kvm-amd.ko)이 CPU의 하드웨어 가상화 확장(VT-x/AMD-V)을 활용
  2. 각 VM은 일반 Linux 프로세스로 실행 (QEMU 프로세스)
  3. vCPU는 Linux 스레드로 스케줄링
  4. QEMU가 디바이스 에뮬레이션(디스크, 네트워크, USB 등) 담당
# KVM 지원 확인
grep -E '(vmx|svm)' /proc/cpuinfo

# KVM 모듈 로드
sudo modprobe kvm
sudo modprobe kvm_intel  # Intel CPU
# sudo modprobe kvm_amd  # AMD CPU

# KVM 디바이스 확인
ls -la /dev/kvm

2.2 vCPU 핀닝과 NUMA 토폴로지

NUMA(Non-Uniform Memory Access) 아키텍처에서 CPU와 메모리의 물리적 위치가 성능에 큰 영향을 미친다.

# NUMA 토폴로지 확인
numactl --hardware
# node 0: cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
# node 0: size: 65536 MB
# node 1: cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
# node 1: size: 65536 MB

# lstopo로 시각화
lstopo --of png > topology.png

vCPU 핀닝 설정 (libvirt XML):

<vcpu placement='static'>8</vcpu>
<cputune>
  <vcpupin vcpu='0' cpuset='0'/>
  <vcpupin vcpu='1' cpuset='1'/>
  <vcpupin vcpu='2' cpuset='2'/>
  <vcpupin vcpu='3' cpuset='3'/>
  <vcpupin vcpu='4' cpuset='4'/>
  <vcpupin vcpu='5' cpuset='5'/>
  <vcpupin vcpu='6' cpuset='6'/>
  <vcpupin vcpu='7' cpuset='7'/>
  <emulatorpin cpuset='16-17'/>
</cputune>
<numatune>
  <memory mode='strict' nodeset='0'/>
</numatune>

2.3 virtio: 준가상화 I/O

virtio는 게스트와 호스트 간 고성능 I/O를 위한 표준 인터페이스다. 하드웨어 에뮬레이션 대신 최적화된 가상 드라이버를 사용한다.

virtio 디바이스용도에뮬레이션 대체 대상
virtio-net네트워크e1000, rtl8139
virtio-blk블록 스토리지IDE, SATA
virtio-scsiSCSI 스토리지LSI Logic
virtio-balloon메모리 조정-
virtio-rng난수 생성-
virtio-gpu그래픽QXL, VGA
virtio-fs호스트 파일 공유9p
# QEMU에서 virtio 사용
qemu-system-x86_64 \
  -drive file=disk.qcow2,if=virtio \
  -netdev tap,id=net0,ifname=tap0,script=no \
  -device virtio-net-pci,netdev=net0 \
  -m 4G \
  -smp 4 \
  -enable-kvm

2.4 메모리 관리

Balloon 드라이버:

게스트 내부에서 메모리를 동적으로 확장/축소한다. 호스트가 메모리를 회수할 수 있게 해준다.

# balloon 크기 조정 (virsh)
virsh qemu-monitor-command myvm --hmp 'balloon 2048'

KSM (Kernel Same-page Merging):

동일한 메모리 페이지를 가진 VM들의 페이지를 공유하여 메모리를 절약한다.

# KSM 활성화
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 20 > /sys/kernel/mm/ksm/sleep_millisecs

# KSM 상태 확인
cat /sys/kernel/mm/ksm/pages_shared
cat /sys/kernel/mm/ksm/pages_sharing

Hugepages:

기본 4KB 페이지 대신 2MB 또는 1GB 대형 페이지를 사용하여 TLB 미스를 줄인다.

# Hugepages 설정
echo 4096 > /proc/sys/vm/nr_hugepages  # 4096 x 2MB = 8GB

# /etc/default/grub에 추가
# GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=32 default_hugepagesz=1G"
<!-- libvirt XML에서 hugepages 설정 -->
<memoryBacking>
  <hugepages>
    <page size='1' unit='GiB'/>
  </hugepages>
</memoryBacking>

2.5 SR-IOV와 GPU 패스스루

SR-IOV (Single Root I/O Virtualization):

물리 NIC를 여러 가상 함수(VF)로 분할하여 VM에 직접 할당한다.

# SR-IOV VF 생성
echo 4 > /sys/class/net/enp3s0f0/device/sriov_numvfs

# VF 목록 확인
lspci | grep "Virtual Function"

# VM에 VF 할당 (libvirt XML)
<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x03' slot='0x10' function='0x0'/>
  </source>
</hostdev>

GPU 패스스루 (VFIO):

# IOMMU 활성화 (GRUB)
# Intel: intel_iommu=on iommu=pt
# AMD: amd_iommu=on iommu=pt

# GPU를 vfio-pci에 바인딩
echo "10de 2204" > /sys/bus/pci/drivers/vfio-pci/new_id

2.6 라이브 마이그레이션

실행 중인 VM을 다운타임 없이 다른 호스트로 이동한다.

Pre-copy 마이그레이션 흐름:
1. 전체 메모리를 대상 호스트로 전송
2. 변경된 더티 페이지를 반복 전송
3. 더티 페이지가 충분히 줄어들면 VM 일시 정지
4. 남은 더티 페이지 전송
5. 대상 호스트에서 VM 재개
# virsh 라이브 마이그레이션
virsh migrate --live --persistent --undefinesource \
  myvm qemu+ssh://dest-host/system

# 마이그레이션 속도 제한 (대역폭 MB/s)
virsh migrate-setspeed myvm 100

# 마이그레이션 상태 확인
virsh domjobinfo myvm

3. libvirt 관리

3.1 libvirt 아키텍처

libvirt는 다양한 하이퍼바이저를 통합 관리하는 API/데몬이다.

+--------------------------------------------------+
|  Management Tools                                 |
|  +--------+ +----------+ +---------+ +--------+  |
|  | virsh  | |virt-      | |OpenStack| |oVirt   |  |
|  |        | |manager   | |Nova     | |        |  |
|  +--------+ +----------+ +---------+ +--------+  |
+--------------------------------------------------+
|  libvirt API (C, Python, Go, Java bindings)       |
+--------------------------------------------------+
|  libvirtd daemon                                  |
+--------------------------------------------------+
|  Drivers                                          |
|  +-----+ +------+ +------+ +-------+ +--------+  |
|  | KVM | | Xen  | | LXC  | | VBox  | | VMware |  |
|  +-----+ +------+ +------+ +-------+ +--------+  |
+--------------------------------------------------+

3.2 virsh 핵심 명령어

# VM 생명주기 관리
virsh list --all                    # 모든 VM 목록
virsh start myvm                    # VM 시작
virsh shutdown myvm                 # 게스트 OS 정상 종료
virsh destroy myvm                  # 강제 종료 (전원 차단)
virsh reboot myvm                   # 재부팅
virsh suspend myvm                  # 일시 정지 (메모리 상태 유지)
virsh resume myvm                   # 재개

# VM 생성/삭제
virsh define vm.xml                 # XML로 VM 정의
virsh undefine myvm                 # VM 정의 제거
virsh undefine myvm --remove-all-storage  # 스토리지까지 제거

# 스냅샷 관리
virsh snapshot-create-as myvm snap1 "First snapshot"
virsh snapshot-list myvm
virsh snapshot-revert myvm snap1
virsh snapshot-delete myvm snap1

# 리소스 조정
virsh setvcpus myvm 4 --live        # vCPU 핫 추가
virsh setmem myvm 8G --live         # 메모리 조정

# 콘솔/디스플레이 접속
virsh console myvm                  # 시리얼 콘솔
virsh vncdisplay myvm               # VNC 포트 확인

3.3 XML 도메인 설정

<domain type='kvm'>
  <name>web-server-01</name>
  <uuid>auto-generated</uuid>
  <memory unit='GiB'>8</memory>
  <currentMemory unit='GiB'>8</currentMemory>
  <vcpu placement='static'>4</vcpu>

  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
    <boot dev='hd'/>
  </os>

  <features>
    <acpi/>
    <apic/>
  </features>

  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='4' threads='1'/>
  </cpu>

  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>

  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>

    <!-- virtio 디스크 -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>
      <source file='/var/lib/libvirt/images/web-server-01.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <!-- virtio 네트워크 -->
    <interface type='bridge'>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>

    <!-- VNC 디스플레이 -->
    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/>

    <!-- 시리얼 콘솔 -->
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
  </devices>
</domain>

3.4 스토리지 풀

# 디렉토리 기반 스토리지 풀
virsh pool-define-as default dir --target /var/lib/libvirt/images
virsh pool-build default
virsh pool-start default
virsh pool-autostart default

# LVM 스토리지 풀
virsh pool-define-as lvm-pool logical \
  --source-name vg_vms --target /dev/vg_vms

# Ceph RBD 스토리지 풀
virsh pool-define-as ceph-pool rbd \
  --source-host mon1.example.com \
  --source-name libvirt-pool \
  --auth-type ceph --auth-username libvirt

# 볼륨 관리
virsh vol-create-as default myvm.qcow2 50G --format qcow2
virsh vol-list default
virsh vol-delete myvm.qcow2 default

3.5 네트워크 설정

# NAT 네트워크 (기본)
virsh net-list --all

# 브릿지 네트워크 설정 (netplan 예시)
cat /etc/netplan/01-bridge.yaml
network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp3s0]
      addresses: [192.168.1.100/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

4. OpenStack 아키텍처 (전체 그림)

4.1 OpenStack 개요

OpenStack은 데이터센터의 컴퓨트, 스토리지, 네트워크 리소스를 풀(pool)로 관리하여 사용자에게 셀프서비스 API로 제공하는 클라우드 OS이다.

+------------------------------------------------------------+
|                    Horizon (Dashboard)                       |
+------------------------------------------------------------+
|                    OpenStack API Layer                       |
+------+-------+--------+--------+-------+--------+----------+
| Key- | Nova  |Neutron | Cinder | Glance| Swift  | Heat     |
|stone | Comp- | Net-   | Block  | Image | Object | Orches-  |
| Auth | ute   | work   | Store  |       | Store  | tration  |
+------+-------+--------+--------+-------+--------+----------+
|  RabbitMQ (Message Queue)  |  MariaDB/Galera (Database)    |
+------------------------------------------------------------+
|               Hypervisor (KVM/QEMU)                         |
+------------------------------------------------------------+
|               Physical Infrastructure                       |
+------------------------------------------------------------+

4.2 핵심 서비스 상세

Keystone (인증/인가):

기능:
- 토큰 기반 인증 (Fernet, JWT)
- RBAC (Role-Based Access Control)
- 멀티테넌시 (Project/Domain 격리)
- LDAP/AD 연동, SAML/OIDC Federation
- 서비스 카탈로그 (엔드포인트 레지스트리)
# Keystone 토큰 발급
openstack token issue

# 프로젝트/사용자 관리
openstack project create --domain default myproject
openstack user create --domain default --password-prompt myuser
openstack role add --project myproject --user myuser member

Nova (컴퓨트):

Nova 내부 구성:
- nova-api: REST API 엔드포인트
- nova-scheduler: VM 배치 알고리즘 (FilterScheduler)
- nova-conductor: DB 접근 프록시 (보안)
- nova-compute: 하이퍼바이저 드라이버 (libvirt)
- Placement: 리소스 추적 서비스
# 인스턴스 생성
openstack server create \
  --flavor m1.large \
  --image ubuntu-22.04 \
  --network internal-net \
  --security-group default \
  --key-name mykey \
  web-server-01

# flavor 관리
openstack flavor create --vcpus 4 --ram 8192 --disk 80 m1.large

# 인스턴스 관리
openstack server list
openstack server show web-server-01
openstack server resize web-server-01 m1.xlarge

Neutron (네트워킹):

Neutron 구성:
- neutron-server: API 서버
- ML2 Plugin: 모듈러 네트워크 드라이버
- OVS/OVN Agent: 가상 스위치 관리
- L3 Agent: 라우팅, NAT
- DHCP Agent: IP 할당
- Metadata Agent: 인스턴스 메타데이터
# 네트워크 생성
openstack network create internal-net
openstack subnet create --network internal-net \
  --subnet-range 10.0.1.0/24 \
  --gateway 10.0.1.1 \
  --dns-nameserver 8.8.8.8 \
  internal-subnet

# 라우터 생성
openstack router create main-router
openstack router set --external-gateway external-net main-router
openstack router add subnet main-router internal-subnet

# Floating IP 할당
openstack floating ip create external-net
openstack server add floating ip web-server-01 203.0.113.10

# 보안 그룹
openstack security group rule create --protocol tcp \
  --dst-port 80:80 --remote-ip 0.0.0.0/0 default
openstack security group rule create --protocol tcp \
  --dst-port 22:22 --remote-ip 10.0.0.0/8 default

Cinder (블록 스토리지):

# 볼륨 생성 및 연결
openstack volume create --size 100 data-vol
openstack server add volume web-server-01 data-vol

# 스냅샷
openstack volume snapshot create --volume data-vol snap-before-upgrade

# 볼륨 타입 (백엔드 지정)
openstack volume type create --property volume_backend_name=ceph-ssd fast-ssd
openstack volume create --size 50 --type fast-ssd fast-data

Glance (이미지 서비스):

# 이미지 업로드
openstack image create "ubuntu-22.04" \
  --file ubuntu-22.04-server-cloudimg-amd64.img \
  --disk-format qcow2 \
  --container-format bare \
  --public

# 이미지 목록
openstack image list

Heat (오케스트레이션):

# HOT (Heat Orchestration Template) 예시
heat_template_version: 2021-04-16

description: Web server stack

parameters:
  image:
    type: string
    default: ubuntu-22.04
  flavor:
    type: string
    default: m1.large

resources:
  web_server:
    type: OS::Nova::Server
    properties:
      name: web-server
      image: { get_param: image }
      flavor: { get_param: flavor }
      networks:
        - network: internal-net
      security_groups:
        - default

  web_port:
    type: OS::Neutron::Port
    properties:
      network: internal-net

  floating_ip:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network: external-net
      port_id: { get_resource: web_port }

outputs:
  server_ip:
    value: { get_attr: [floating_ip, floating_ip_address] }

4.3 추가 서비스

서비스프로젝트설명AWS 대응
컴퓨트NovaVM 관리EC2
네트워크NeutronSDNVPC
블록 스토리지Cinder디스크EBS
오브젝트 스토리지Swift분산 스토리지S3
이미지GlanceVM 이미지AMI
인증KeystoneIAMIAM
오케스트레이션Heat스택 관리CloudFormation
대시보드Horizon웹 UIConsole
베어메탈Ironic물리 서버-
DNSDesignateDNS 관리Route 53
로드밸런서OctaviaLBaaSELB
파일 스토리지Manila공유 파일시스템EFS
컨테이너MagnumK8s 클러스터EKS

5. OpenStack 배포

5.1 배포 방식 비교

방식용도복잡도프로덕션
DevStack개발/테스트낮음불가
Kolla-Ansible프로덕션중간권장
TripleO대규모 프로덕션높음가능
MicroStack (Snap)단일 노드 테스트매우 낮음불가
OpenStack-Ansible프로덕션중간가능

5.2 최소 하드웨어 요구사항

컨트롤러 노드 (3HA):
  - CPU: 8코어 이상
  - RAM: 32GB 이상
  - Disk: 500GB SSD (OS + DB)
  - NIC: 2이상 (관리 + 서비스)

컴퓨트 노드 (N):
  - CPU: 최대한 많은 코어 (VM 수에 비례)
  - RAM: 128GB+ (VM 메모리 합계 + 오버헤드)
  - Disk: SSD (로컬 에페메럴)
  - NIC: 2개 이상

스토리지 노드 (Ceph OSD, 3대 이상):
  - CPU: OSD1코어
  - RAM: OSD당 4GB
  - Disk: NVMe/SSD (OSD) + SSD (WAL/DB)
  - NIC: 10GbE 이상

5.3 Kolla-Ansible 배포

# 1. 준비
pip install kolla-ansible

# 2. 인벤토리 설정
cp /usr/share/kolla-ansible/ansible/inventory/multinode .
# 인벤토리 파일 편집

# 3. 전역 설정
cat /etc/kolla/globals.yml
# /etc/kolla/globals.yml
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "2024.2"

kolla_internal_vip_address: "10.0.0.100"
kolla_external_vip_address: "203.0.113.100"

network_interface: "eth0"
neutron_external_interface: "eth1"

enable_cinder: "yes"
enable_cinder_backend_lvm: "no"
enable_cinder_backend_ceph: "yes"

enable_heat: "yes"
enable_horizon: "yes"
enable_neutron_provider_networks: "yes"

ceph_cinder_user: "cinder"
ceph_cinder_pool_name: "volumes"
# 4. 패스워드 생성
kolla-genpwd

# 5. 부트스트랩
kolla-ansible -i multinode bootstrap-servers

# 6. 사전 검증
kolla-ansible -i multinode prechecks

# 7. 배포
kolla-ansible -i multinode deploy

# 8. 후처리 (OpenRC/clouds.yaml 생성)
kolla-ansible -i multinode post-deploy

# 9. 확인
source /etc/kolla/admin-openrc.sh
openstack service list
openstack compute service list
openstack network agent list

5.4 네트워크 아키텍처

+------------------------------------------------------------+
|  External Network (203.0.113.0/24)                          |
|                        |                                    |
|                  [External Router]                           |
|                        |                                    |
|  Management Network (10.0.0.0/24)                           |
|  +----------+  +----------+  +----------+                   |
|  |Controller|  |Controller|  |Controller|                   |
|  |   Node 1 |  |   Node 2 |  |   Node 3 |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Tunnel Network (10.0.1.0/24) - VXLAN                       |
|        |              |              |                       |
|  +----------+  +----------+  +----------+                   |
|  | Compute  |  | Compute  |  | Compute  |                   |
|  |  Node 1  |  |  Node 2  |  |  Node 3  |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Storage Network (10.0.2.0/24) - Ceph                       |
|        |              |              |                       |
|  +----------+  +----------+  +----------+                   |
|  |  Ceph    |  |  Ceph    |  |  Ceph    |                   |
|  |  OSD 1   |  |  OSD 2   |  |  OSD 3   |                   |
|  +----------+  +----------+  +----------+                   |
+------------------------------------------------------------+

6. 네트워킹 심층 분석

6.1 Provider vs Self-service 네트워크

Provider 네트워크:

  • 관리자가 생성, 물리 네트워크에 직접 매핑
  • VLAN 기반, 외부 라우팅 장비 사용
  • 단순하지만 유연성 부족

Self-service (Tenant) 네트워크:

  • 테넌트가 자유롭게 생성
  • VXLAN/GRE 터널링으로 격리
  • Neutron L3 에이전트가 라우팅 담당
  • Floating IP로 외부 접근

6.2 OVS vs OVN

Open vSwitch (OVS):
- 소프트웨어 가상 스위치
- neutron-openvswitch-agent가 관리
- 성숙하고 안정적
- 대규모에서 성능 저하 가능

OVN (Open Virtual Network):
- OVS 위에 구축된 SDN 솔루션
- 분산형 아키텍처 (중앙 에이전트 불필요)
- 네이티브 L3/NAT/DHCP/ACL 지원
- 대규모 환경에서 우수한 성능
- OpenStack 최신 권장 백엔드
# OVN 구성 확인
ovn-sbctl show
ovn-nbctl show

# 논리 스위치/라우터 확인
ovn-nbctl ls-list
ovn-nbctl lr-list

6.3 VXLAN 터널링

VXLAN (Virtual Extensible LAN):
- UDP 포트 4789L2 프레임을 L3 네트워크에 캡슐화
- 24비트 VNI로 최대 약 1,600만개 세그먼트 (VLAN4,096)
- 멀티테넌트 환경에 적합

패킷 구조:
+------+------+------+------+---------+------+------+
|Outer | Outer| Outer| VXLAN| Inner   |Inner |Inner |
|Ether | IP   | UDP  |Header| Ether   |  IP  |Payload|
+------+------+------+------+---------+------+------+

6.4 DVR (Distributed Virtual Router)

DVR은 라우팅을 각 컴퓨트 노드에 분산하여 네트워크 노드 병목을 해소한다.

DVR 없이 (Centralized):
  VM -> Compute Node -> [Network Node: L3 Agent] -> External

DVR 적용:
  VM -> Compute Node [Local L3 Agent] -> External
  (East-West 트래픽도 로컬에서 처리)

6.5 보안 그룹과 FWaaS

# 보안 그룹 생성
openstack security group create web-sg
openstack security group rule create \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 web-sg
openstack security group rule create \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 web-sg
openstack security group rule create \
  --protocol tcp --dst-port 22 --remote-ip 10.0.0.0/8 web-sg

7. 스토리지 아키텍처

7.1 스토리지 유형

+------------------------------------------------------------+
|  Ephemeral Storage                                          |
|  - VM 삭제 시 함께 삭제                                       |
|  - 로컬 디스크 (빠르지만 비영구)                                |
|  - 스냅샷으로 영구 이미지 변환 가능                              |
+------------------------------------------------------------+
|  Persistent Block Storage (Cinder)                          |
|  - VM과 독립적 생명주기                                       |
|  - 다른 VM에 재연결 가능                                      |
|  - 스냅샷, 복제, 암호화 지원                                   |
+------------------------------------------------------------+
|  Object Storage (Swift)                                     |
|  - REST API로 접근                                           |
|  - VM 이미지, 백업 데이터 저장                                 |
|  - 높은 내구성 (3중 복제)                                     |
+------------------------------------------------------------+
|  Shared File System (Manila)                                |
|  - NFS/CIFS 공유                                             |
|  - 여러 VM이 동시 접근                                        |
+------------------------------------------------------------+

7.2 Ceph 통합

Ceph는 OpenStack과 가장 잘 통합되는 분산 스토리지이다.

Ceph + OpenStack 매핑:
- Ceph RBD  -> Cinder (블록 스토리지)
- Ceph RBD  -> Nova (에페메럴 디스크, 라이브 마이그레이션)
- Ceph RBD  -> Glance (이미지 저장)
- Ceph RGW  -> Swift API 호환 (오브젝트 스토리지)
- CephFS    -> Manila (공유 파일시스템)
# Ceph 풀 생성 (OpenStack용)
ceph osd pool create volumes 128
ceph osd pool create images 64
ceph osd pool create vms 128
ceph osd pool create backups 64

# Ceph 인증 키 생성
ceph auth get-or-create client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images'

ceph auth get-or-create client.glance \
  mon 'profile rbd' \
  osd 'profile rbd pool=images'

7.3 스토리지 티어링

티어미디어용도지연시간
Tier 0NVMe SSD데이터베이스, 고성능 VM0.1ms 미만
Tier 1SATA SSD일반 VM, 웹 서버0.5ms 미만
Tier 2HDD (10K RPM)아카이브, 백업5ms 미만
Tier 3Object (S3)콜드 데이터수십 ms

8. 성능 최적화

8.1 CPU 최적화

# CPU 핀닝 + NUMA 인식 (nova.conf)
# [DEFAULT]
# vcpu_pin_set = 4-31
# reserved_host_cpus = 0-3
# cpu_allocation_ratio = 4.0

# [libvirt]
# cpu_mode = host-passthrough
<!-- 고성능 VM: CPU 핀닝 + Hugepages + NUMA -->
<domain type='kvm'>
  <vcpu placement='static'>16</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='5'/>
    <!-- ... -->
    <emulatorpin cpuset='0-1'/>
  </cputune>
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>
  <memoryBacking>
    <hugepages>
      <page size='1' unit='GiB'/>
    </hugepages>
  </memoryBacking>
  <cpu mode='host-passthrough'>
    <topology sockets='1' dies='1' cores='16' threads='1'/>
    <numa>
      <cell id='0' cpus='0-15' memory='32' unit='GiB'/>
    </numa>
  </cpu>
</domain>

8.2 네트워크 최적화

성능 순서 (낮음 -> 높음):
1. virtio-net (소프트웨어 가상화) - 약 10Gbps
2. vhost-net (커널 모드 데이터패스) - 약 15Gbps
3. DPDK (유저 스페이스 패킷 처리) - 약 40Gbps
4. SR-IOV (하드웨어 패스스루) - 네이티브에 근접 (100Gbps)

8.3 스토리지 I/O 최적화

# virtio-scsi (멀티큐 지원)
# virtio-blk보다 많은 디바이스 연결 가능, SCSI 명령 지원

# I/O 스케줄러 (NVMe에는 none 권장)
echo none > /sys/block/nvme0n1/queue/scheduler

# I/O 스레드 분리 (libvirt)
<iothreads>4</iothreads>
<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' cache='none' io='native' iothread='1'/>
  <source file='/var/lib/libvirt/images/vm.qcow2'/>
  <target dev='vda' bus='virtio'/>
</disk>

8.4 오버커밋 비율

리소스기본값권장값 (일반)권장값 (고성능)
CPU16:14:1 ~ 8:11:1 (핀닝)
RAM1.5:11:1 ~ 1.2:11:1 (Hugepages)
Disk1.0:12:1 (thin)1:1 (thick)

9. OpenStack vs VMware vs Proxmox

항목OpenStackVMware vSphereProxmox VE
라이선스오픈소스 (Apache 2.0)상용 (고가)오픈소스 (AGPL) + 상용 지원
하이퍼바이저KVM (기본)ESXiKVM + LXC
설치 난이도높음중간매우 낮음
학습 곡선매우 가파름가파름완만
확장성수천 노드수백 노드수십 노드
API/자동화강력한 REST APIvSphere API, PowerCLIREST API, CLI
멀티테넌시강력 (Project/Domain)제한적 (vCenter)기본적 (Pool/Permission)
SDNNeutron (OVS/OVN)NSX기본 Linux Bridge/OVS
스토리지Cinder + Ceph/NFS/iSCSIvSAN, VMFSZFS, Ceph, LVM
HAPacemaker, HAProxyvSphere HA, FT내장 HA
컨테이너 지원Magnum (K8s)Tanzu내장 LXC
상용 지원Red Hat, Canonical, SUSEVMware (Broadcom)Proxmox
총 소유 비용낮음 (운영 인력 필요)매우 높음매우 낮음
적합 규모대규모 클라우드엔터프라이즈중소규모

선택 가이드:

  • OpenStack: 대규모 프라이빗/퍼블릭 클라우드, 통신사, 연구기관, AWS 같은 셀프서비스가 필요할 때
  • VMware: 기존 엔터프라이즈 환경, Windows 중심, 벤더 지원 필수, 비용 여유
  • Proxmox: 중소기업, 홈랩, 간단한 가상화, 빠른 도입

10. 프로덕션 베스트 프랙티스

10.1 고가용성 (HA)

컨트롤 플레인 HA:
- 최소 3개 컨트롤러 노드
- HAProxy + Keepalived (VIP)
- Pacemaker/Corosync (클러스터 관리)
- Galera Cluster (MariaDB 동기 복제)
- RabbitMQ 미러링 큐

데이터 플레인 HA:
- Ceph (3중 복제, 노드 장애 자동 복구)
- Neutron DVR (네트워크 노드 SPOF 제거)
- Nova 인스턴스 HA (Masakari)
# HAProxy 상태 확인
echo "show stat" | socat stdio /var/run/haproxy/admin.sock

# Galera 클러스터 상태
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_status';"

# RabbitMQ 클러스터 상태
rabbitmqctl cluster_status

10.2 모니터링

# Prometheus + OpenStack Exporter 설정
# prometheus.yml
scrape_configs:
  - job_name: 'openstack'
    static_configs:
      - targets: ['openstack-exporter:9198']
    metrics_path: '/metrics'

  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph-mgr:9283']

  - job_name: 'libvirt'
    static_configs:
      - targets: ['compute1:9177', 'compute2:9177']

주요 모니터링 메트릭:

카테고리메트릭임계값
Nova활성 인스턴스 수용량 대비 80%
Nova스케줄링 실패율5% 이상 경고
NeutronFloating IP 사용률90% 경고
Cinder볼륨 생성 실패율1% 이상 경고
CephOSD 상태down OSD 1개 이상 경고
Ceph사용률70% 경고, 85% 위험
RabbitMQ큐 길이1000 이상 경고
MariaDB복제 지연1초 이상 경고

10.3 백업 전략

# OpenStack 데이터베이스 백업
mysqldump --all-databases --single-transaction \
  --routines --triggers > openstack-db-backup.sql

# Cinder 볼륨 백업 (Ceph)
rbd snap create volumes/volume-UUID@backup-20260325
rbd export volumes/volume-UUID@backup-20260325 volume-backup.raw

# Glance 이미지 백업
openstack image save --file ubuntu-backup.qcow2 ubuntu-22.04

# Nova 인스턴스 스냅샷
openstack server image create --name "web-server-backup" web-server-01

10.4 업그레이드 전략

Rolling Upgrade 절차:
1. 컨트롤러 노드를 하나씩 업그레이드
   - 서비스 중단 최소화
   - API 하위 호환성 활용
2. 데이터베이스 마이그레이션 실행
3. 컴퓨트 노드를 하나씩 업그레이드
   - VM 라이브 마이그레이션으로 빈 노드 업그레이드
4. Neutron 에이전트 업그레이드
5. 전체 서비스 검증

11. 퀴즈

Q1. KVM은 어떤 유형의 하이퍼바이저인가?

정답: Type-1 (Bare-Metal) 하이퍼바이저

KVM은 Linux 커널 모듈로 동작하며, Linux 커널 자체를 하이퍼바이저로 변환한다. 하드웨어 위에 직접 실행되는 호스트 OS(Linux)에 내장되어 있으므로 Type-1으로 분류된다. Intel VT-x/AMD-V 하드웨어 가상화 확장을 활용하여 높은 성능을 제공한다.

Q2. OpenStack에서 가상 네트워크, 서브넷, 라우터를 관리하는 서비스는?

정답: Neutron

Neutron은 OpenStack의 네트워크 서비스(Networking-as-a-Service)이다. ML2 플러그인, OVS/OVN 에이전트, L3 에이전트, DHCP 에이전트 등으로 구성되며, 가상 네트워크, 서브넷, 라우터, 보안 그룹, Floating IP 등을 관리한다. AWS의 VPC에 대응하는 서비스이다.

Q3. VXLAN 터널링이 VLAN 대비 가지는 핵심 장점은?

정답: 세그먼트 수 확장 (4,096개에서 약 1,600만개로)

VLAN은 12비트 VLAN ID로 최대 4,096개 세그먼트만 지원한다. 반면 VXLAN은 24비트 VNI(Virtual Network Identifier)를 사용하여 약 1,600만 개의 네트워크 세그먼트를 지원한다. 이는 대규모 멀티테넌트 클라우드 환경에서 필수적이다.

Q4. KSM(Kernel Same-page Merging)의 역할은?

정답: 동일한 메모리 페이지를 가진 VM들의 메모리를 공유하여 물리 메모리 사용량을 줄인다

KSM은 Linux 커널 기능으로, 여러 VM이 동일한 내용의 메모리 페이지를 가지고 있을 때 이를 하나의 물리 페이지로 병합(Copy-on-Write)한다. 동일한 OS 이미지를 사용하는 VM이 많을수록 효과가 크다. 단, 스캐닝 오버헤드가 있으므로 적절한 튜닝이 필요하다.

Q5. OpenStack 프로덕션 배포에서 Kolla-Ansible을 선호하는 이유는?

정답: 컨테이너화된 서비스 배포로 관리 용이성, 재현성, 업그레이드 편의성을 제공

Kolla-Ansible은 각 OpenStack 서비스를 Docker 컨테이너로 패키징하여 배포한다. 이는 환경 격리(의존성 충돌 방지), 빠른 롤백, 재현 가능한 배포, 서비스별 독립 업그레이드를 가능하게 한다. Ansible 기반이므로 자동화와 반복 배포가 용이하며, 프로덕션 HA 구성도 기본 지원한다.


12. 참고 자료

  1. OpenStack 공식 문서 - docs.openstack.org
  2. KVM 공식 사이트 - linux-kvm.org
  3. libvirt 공식 문서 - libvirt.org/docs.html
  4. QEMU 공식 문서 - qemu.org/documentation
  5. Kolla-Ansible 문서 - docs.openstack.org/kolla-ansible/latest
  6. Ceph 공식 문서 - docs.ceph.com
  7. Open vSwitch 문서 - docs.openvswitch.org
  8. OVN 아키텍처 - ovn.org
  9. Red Hat OpenStack Platform - access.redhat.com/documentation/en-us/red_hat_openstack_platform
  10. Proxmox VE 문서 - pve.proxmox.com/wiki/Main_Page
  11. VMware vSphere 문서 - docs.vmware.com
  12. OpenStack Foundation (OpenInfra) - openinfra.dev
  13. DPDK 문서 - doc.dpdk.org
  14. SR-IOV 가이드 - kernel.org/doc/html/latest/PCI/sriov-howto.html

OpenStack & KVM Virtualization Complete Guide 2025: Building and Operating Private Cloud Infrastructure

Table of Contents

1. Virtualization Fundamentals

1.1 What Is Virtualization and Why Does It Matter?

Virtualization is the technology of creating multiple isolated virtual environments on top of physical hardware. Born in the 1960s on IBM mainframes, it became the backbone of modern cloud computing with the popularization of x86 virtualization in the 2000s.

Why virtualization matters:

  • Server consolidation: Increase utilization from 10-15% to 60-80%
  • Cost reduction: Dramatically cut hardware, power, cooling, and space costs
  • Agility: Provision new servers in minutes (physical servers take weeks)
  • Isolation: Security isolation between workloads, fault isolation
  • Disaster recovery: Snapshots, live migration for fast recovery

1.2 Type-1 vs Type-2 Hypervisors

A hypervisor is the software layer that creates and manages virtual machines.

Type-1 (Bare-Metal) Hypervisors:

Installed directly on hardware without requiring a host OS. Lower overhead and better performance.

  • KVM: Linux kernel module. Linux itself becomes the hypervisor
  • VMware ESXi: Enterprise standard with the vSphere ecosystem
  • Xen: Original foundation of AWS EC2. Managed by Citrix
  • Microsoft Hyper-V: Built into Windows Server

Type-2 (Hosted) Hypervisors:

Installed as an application on top of an existing OS. Suitable for development and testing.

  • VirtualBox: Oracle's open-source cross-platform solution
  • VMware Workstation/Fusion: Desktop virtualization
  • Parallels Desktop: macOS only

1.3 Virtualization Approaches Compared

+--------------------------------------------------+
|    Virtualization Approaches Comparison            |
+--------------------------------------------------+
| Full Virtualization                                |
|   - No guest OS modification needed               |
|   - Binary Translation for privileged instructions |
|   - Performance overhead present                   |
+--------------------------------------------------+
| Para-virtualization                                |
|   - Requires guest OS kernel modification          |
|   - Xen is the primary example                    |
|   - Good performance but limited compatibility     |
+--------------------------------------------------+
| Hardware-Assisted Virtualization                   |
|   - Intel VT-x / AMD-V                            |
|   - No guest modification + high performance       |
|   - KVM leverages this approach                    |
+--------------------------------------------------+

1.4 Hypervisor Comparison Table

FeatureKVMVMware ESXiXenHyper-V
TypeType-1Type-1Type-1Type-1
LicenseOpen Source (GPL)Commercial (free edition)Open Source (GPL)Windows included
Host OSLinuxProprietary kernelProprietary kernelWindows Server
PerformanceExcellentExcellentExcellentGood
GPU PassthroughSupported (VFIO)Supported (vGPU)LimitedSupported (DDA)
Live MigrationSupportedvMotionSupportedLive Migration
Managementlibvirt, OpenStackvCenterXenCenterSCVMM
EcosystemVast (Linux)Largest enterpriseShrinkingWindows ecosystem
Edge DeploymentEasyHeavyPossibleLimited

1.5 Containers vs Virtual Machines

  Virtual Machines (VMs)            Containers
+------------------+           +------------------+
|   App A | App B  |           | App A  |  App B  |
+------------------+           +------------------+
| Guest  | Guest   |           | Bins/  | Bins/   |
|  OS    |  OS     |           | Libs   | Libs    |
+------------------+           +------------------+
|   Hypervisor     |           | Container Engine  |
+------------------+           +------------------+
|   Host OS        |           |   Host OS         |
+------------------+           +------------------+
|   Hardware       |           |   Hardware        |
+------------------+           +------------------+
FeatureVirtual MachinesContainers
Isolation LevelStrong (hardware-level)Weaker (shared kernel)
Startup TimeTens of seconds to minutesMilliseconds to seconds
Resource OverheadHigh (full OS per VM)Low (shared kernel)
Image SizeGB rangeMB range
Density10-50 VMs/server100-1000 containers/server
SecurityStrong isolationEnhanced with gVisor, Kata
Use CasesMulti-OS, legacy apps, high isolationMicroservices, CI/CD, scale-out

When to choose VMs:

  • Running different operating systems (Windows + Linux)
  • Strong security isolation required (multi-tenant)
  • Legacy application operations
  • Kernel-level customization needed

When to choose containers:

  • Many instances on the same OS
  • Fast scaling required
  • CI/CD pipelines
  • Microservices architecture

2. KVM/QEMU Deep Dive

2.1 KVM Architecture

KVM (Kernel-based Virtual Machine) is a hypervisor module included in the Linux kernel since version 2.6.20. It transforms Linux itself into a Type-1 hypervisor.

+--------------------------------------------------+
|          Guest VMs (each VM is a Linux process)    |
|  +-----------+  +-----------+  +-----------+      |
|  | Guest OS  |  | Guest OS  |  | Guest OS  |      |
|  +-----------+  +-----------+  +-----------+      |
|  |   QEMU    |  |   QEMU    |  |   QEMU    |      |
|  | (userspace)|  | (userspace)|  | (userspace)|    |
+--------------------------------------------------+
|              Linux Kernel                         |
|  +------+  +-------+  +--------+  +---------+    |
|  | KVM  |  | sched |  | memory |  | network |    |
|  |module |  |       |  | mgmt   |  | stack   |    |
|  +------+  +-------+  +--------+  +---------+    |
+--------------------------------------------------+
|              Hardware                             |
|  +----------+  +-------+  +--------+             |
|  | CPU      |  | RAM   |  | NIC    |             |
|  | VT-x/SVM |  |       |  |        |             |
|  +----------+  +-------+  +--------+             |
+--------------------------------------------------+

How it works:

  1. KVM kernel modules (kvm.ko, kvm-intel.ko or kvm-amd.ko) leverage CPU hardware virtualization extensions (VT-x/AMD-V)
  2. Each VM runs as a regular Linux process (QEMU process)
  3. vCPUs are scheduled as Linux threads
  4. QEMU handles device emulation (disk, network, USB, etc.)
# Check KVM support
grep -E '(vmx|svm)' /proc/cpuinfo

# Load KVM modules
sudo modprobe kvm
sudo modprobe kvm_intel  # Intel CPU
# sudo modprobe kvm_amd  # AMD CPU

# Verify KVM device
ls -la /dev/kvm

2.2 vCPU Pinning and NUMA Topology

In NUMA (Non-Uniform Memory Access) architecture, the physical location of CPUs and memory significantly impacts performance.

# Check NUMA topology
numactl --hardware
# node 0: cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
# node 0: size: 65536 MB
# node 1: cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
# node 1: size: 65536 MB

# Visualize with lstopo
lstopo --of png > topology.png

vCPU Pinning Configuration (libvirt XML):

<vcpu placement='static'>8</vcpu>
<cputune>
  <vcpupin vcpu='0' cpuset='0'/>
  <vcpupin vcpu='1' cpuset='1'/>
  <vcpupin vcpu='2' cpuset='2'/>
  <vcpupin vcpu='3' cpuset='3'/>
  <vcpupin vcpu='4' cpuset='4'/>
  <vcpupin vcpu='5' cpuset='5'/>
  <vcpupin vcpu='6' cpuset='6'/>
  <vcpupin vcpu='7' cpuset='7'/>
  <emulatorpin cpuset='16-17'/>
</cputune>
<numatune>
  <memory mode='strict' nodeset='0'/>
</numatune>

2.3 virtio: Para-virtualized I/O

virtio provides a standard interface for high-performance I/O between guest and host. Instead of hardware emulation, it uses optimized virtual drivers.

virtio DevicePurposeReplaces
virtio-netNetworkinge1000, rtl8139
virtio-blkBlock storageIDE, SATA
virtio-scsiSCSI storageLSI Logic
virtio-balloonMemory adjustment-
virtio-rngRandom number generation-
virtio-gpuGraphicsQXL, VGA
virtio-fsHost file sharing9p
# Using virtio with QEMU
qemu-system-x86_64 \
  -drive file=disk.qcow2,if=virtio \
  -netdev tap,id=net0,ifname=tap0,script=no \
  -device virtio-net-pci,netdev=net0 \
  -m 4G \
  -smp 4 \
  -enable-kvm

2.4 Memory Management

Balloon Driver:

Dynamically expands and shrinks memory inside the guest, allowing the host to reclaim memory.

# Adjust balloon size (virsh)
virsh qemu-monitor-command myvm --hmp 'balloon 2048'

KSM (Kernel Same-page Merging):

Shares identical memory pages across VMs to save physical memory.

# Enable KSM
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 20 > /sys/kernel/mm/ksm/sleep_millisecs

# Check KSM status
cat /sys/kernel/mm/ksm/pages_shared
cat /sys/kernel/mm/ksm/pages_sharing

Hugepages:

Use 2MB or 1GB large pages instead of the default 4KB pages to reduce TLB misses.

# Configure hugepages
echo 4096 > /proc/sys/vm/nr_hugepages  # 4096 x 2MB = 8GB

# Add to /etc/default/grub
# GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=32 default_hugepagesz=1G"
<!-- Hugepages in libvirt XML -->
<memoryBacking>
  <hugepages>
    <page size='1' unit='GiB'/>
  </hugepages>
</memoryBacking>

2.5 SR-IOV and GPU Passthrough

SR-IOV (Single Root I/O Virtualization):

Splits a physical NIC into multiple Virtual Functions (VFs) for direct assignment to VMs.

# Create SR-IOV VFs
echo 4 > /sys/class/net/enp3s0f0/device/sriov_numvfs

# List VFs
lspci | grep "Virtual Function"
<!-- Assign VF to VM (libvirt XML) -->
<hostdev mode='subsystem' type='pci' managed='yes'>
  <source>
    <address domain='0x0000' bus='0x03' slot='0x10' function='0x0'/>
  </source>
</hostdev>

GPU Passthrough (VFIO):

# Enable IOMMU (GRUB)
# Intel: intel_iommu=on iommu=pt
# AMD: amd_iommu=on iommu=pt

# Bind GPU to vfio-pci
echo "10de 2204" > /sys/bus/pci/drivers/vfio-pci/new_id

2.6 Live Migration

Move a running VM to another host with zero downtime.

Pre-copy Migration Flow:
1. Transfer entire memory to destination host
2. Iteratively send dirty pages
3. When dirty pages are small enough, pause VM
4. Transfer remaining dirty pages
5. Resume VM on destination host
# virsh live migration
virsh migrate --live --persistent --undefinesource \
  myvm qemu+ssh://dest-host/system

# Set migration bandwidth limit (MB/s)
virsh migrate-setspeed myvm 100

# Check migration status
virsh domjobinfo myvm

3. libvirt Management

3.1 libvirt Architecture

libvirt is a unified API and daemon for managing various hypervisors.

+--------------------------------------------------+
|  Management Tools                                 |
|  +--------+ +----------+ +---------+ +--------+  |
|  | virsh  | |virt-      | |OpenStack| |oVirt   |  |
|  |        | |manager   | |Nova     | |        |  |
|  +--------+ +----------+ +---------+ +--------+  |
+--------------------------------------------------+
|  libvirt API (C, Python, Go, Java bindings)       |
+--------------------------------------------------+
|  libvirtd daemon                                  |
+--------------------------------------------------+
|  Drivers                                          |
|  +-----+ +------+ +------+ +-------+ +--------+  |
|  | KVM | | Xen  | | LXC  | | VBox  | | VMware |  |
|  +-----+ +------+ +------+ +-------+ +--------+  |
+--------------------------------------------------+

3.2 Essential virsh Commands

# VM lifecycle management
virsh list --all                    # List all VMs
virsh start myvm                    # Start VM
virsh shutdown myvm                 # Graceful shutdown
virsh destroy myvm                  # Force stop (power off)
virsh reboot myvm                   # Reboot
virsh suspend myvm                  # Pause (preserve memory state)
virsh resume myvm                   # Resume

# VM creation/deletion
virsh define vm.xml                 # Define VM from XML
virsh undefine myvm                 # Remove VM definition
virsh undefine myvm --remove-all-storage  # Remove with storage

# Snapshot management
virsh snapshot-create-as myvm snap1 "First snapshot"
virsh snapshot-list myvm
virsh snapshot-revert myvm snap1
virsh snapshot-delete myvm snap1

# Resource adjustment
virsh setvcpus myvm 4 --live        # Hot-add vCPUs
virsh setmem myvm 8G --live         # Adjust memory

# Console/display access
virsh console myvm                  # Serial console
virsh vncdisplay myvm               # VNC port info

3.3 XML Domain Configuration

<domain type='kvm'>
  <name>web-server-01</name>
  <uuid>auto-generated</uuid>
  <memory unit='GiB'>8</memory>
  <currentMemory unit='GiB'>8</currentMemory>
  <vcpu placement='static'>4</vcpu>

  <os>
    <type arch='x86_64' machine='pc-q35-8.2'>hvm</type>
    <boot dev='hd'/>
  </os>

  <features>
    <acpi/>
    <apic/>
  </features>

  <cpu mode='host-passthrough' check='none' migratable='on'>
    <topology sockets='1' dies='1' cores='4' threads='1'/>
  </cpu>

  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>

    <!-- virtio disk -->
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' discard='unmap'/>
      <source file='/var/lib/libvirt/images/web-server-01.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>

    <!-- virtio network -->
    <interface type='bridge'>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>

    <!-- VNC display -->
    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'/>

    <!-- Serial console -->
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
  </devices>
</domain>

3.4 Storage Pools

# Directory-based storage pool
virsh pool-define-as default dir --target /var/lib/libvirt/images
virsh pool-build default
virsh pool-start default
virsh pool-autostart default

# LVM storage pool
virsh pool-define-as lvm-pool logical \
  --source-name vg_vms --target /dev/vg_vms

# Ceph RBD storage pool
virsh pool-define-as ceph-pool rbd \
  --source-host mon1.example.com \
  --source-name libvirt-pool \
  --auth-type ceph --auth-username libvirt

# Volume management
virsh vol-create-as default myvm.qcow2 50G --format qcow2
virsh vol-list default
virsh vol-delete myvm.qcow2 default

3.5 Network Configuration

# NAT network (default)
virsh net-list --all

# Bridge network setup (netplan example)
# /etc/netplan/01-bridge.yaml
network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp3s0]
      addresses: [192.168.1.100/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

4. OpenStack Architecture (The Big Picture)

4.1 OpenStack Overview

OpenStack manages compute, storage, and network resources in a data center as pools, exposing them to users through self-service APIs. It is essentially a cloud operating system.

+------------------------------------------------------------+
|                    Horizon (Dashboard)                       |
+------------------------------------------------------------+
|                    OpenStack API Layer                       |
+------+-------+--------+--------+-------+--------+----------+
| Key- | Nova  |Neutron | Cinder | Glance| Swift  | Heat     |
|stone | Comp- | Net-   | Block  | Image | Object | Orches-  |
| Auth | ute   | work   | Store  |       | Store  | tration  |
+------+-------+--------+--------+-------+--------+----------+
|  RabbitMQ (Message Queue)  |  MariaDB/Galera (Database)    |
+------------------------------------------------------------+
|               Hypervisor (KVM/QEMU)                         |
+------------------------------------------------------------+
|               Physical Infrastructure                       |
+------------------------------------------------------------+

4.2 Core Services in Detail

Keystone (Identity and Authentication):

Features:
- Token-based authentication (Fernet, JWT)
- RBAC (Role-Based Access Control)
- Multi-tenancy (Project/Domain isolation)
- LDAP/AD integration, SAML/OIDC Federation
- Service catalog (endpoint registry)
# Issue Keystone token
openstack token issue

# Project/user management
openstack project create --domain default myproject
openstack user create --domain default --password-prompt myuser
openstack role add --project myproject --user myuser member

Nova (Compute):

Nova Internal Components:
- nova-api: REST API endpoint
- nova-scheduler: VM placement algorithm (FilterScheduler)
- nova-conductor: DB access proxy (security)
- nova-compute: Hypervisor driver (libvirt)
- Placement: Resource tracking service
# Create instance
openstack server create \
  --flavor m1.large \
  --image ubuntu-22.04 \
  --network internal-net \
  --security-group default \
  --key-name mykey \
  web-server-01

# Flavor management
openstack flavor create --vcpus 4 --ram 8192 --disk 80 m1.large

# Instance management
openstack server list
openstack server show web-server-01
openstack server resize web-server-01 m1.xlarge

Neutron (Networking):

Neutron Components:
- neutron-server: API server
- ML2 Plugin: Modular network driver
- OVS/OVN Agent: Virtual switch management
- L3 Agent: Routing, NAT
- DHCP Agent: IP allocation
- Metadata Agent: Instance metadata
# Create network
openstack network create internal-net
openstack subnet create --network internal-net \
  --subnet-range 10.0.1.0/24 \
  --gateway 10.0.1.1 \
  --dns-nameserver 8.8.8.8 \
  internal-subnet

# Create router
openstack router create main-router
openstack router set --external-gateway external-net main-router
openstack router add subnet main-router internal-subnet

# Floating IP
openstack floating ip create external-net
openstack server add floating ip web-server-01 203.0.113.10

# Security groups
openstack security group rule create --protocol tcp \
  --dst-port 80:80 --remote-ip 0.0.0.0/0 default
openstack security group rule create --protocol tcp \
  --dst-port 22:22 --remote-ip 10.0.0.0/8 default

Cinder (Block Storage):

# Create and attach volume
openstack volume create --size 100 data-vol
openstack server add volume web-server-01 data-vol

# Snapshots
openstack volume snapshot create --volume data-vol snap-before-upgrade

# Volume types (backend selection)
openstack volume type create --property volume_backend_name=ceph-ssd fast-ssd
openstack volume create --size 50 --type fast-ssd fast-data

Heat (Orchestration):

# HOT (Heat Orchestration Template) example
heat_template_version: 2021-04-16

description: Web server stack

parameters:
  image:
    type: string
    default: ubuntu-22.04
  flavor:
    type: string
    default: m1.large

resources:
  web_server:
    type: OS::Nova::Server
    properties:
      name: web-server
      image: { get_param: image }
      flavor: { get_param: flavor }
      networks:
        - network: internal-net
      security_groups:
        - default

  web_port:
    type: OS::Neutron::Port
    properties:
      network: internal-net

  floating_ip:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network: external-net
      port_id: { get_resource: web_port }

outputs:
  server_ip:
    value: { get_attr: [floating_ip, floating_ip_address] }

4.3 Additional Services

ServiceProjectDescriptionAWS Equivalent
ComputeNovaVM managementEC2
NetworkingNeutronSDNVPC
Block StorageCinderDisksEBS
Object StorageSwiftDistributed storageS3
ImageGlanceVM imagesAMI
IdentityKeystoneIAMIAM
OrchestrationHeatStack managementCloudFormation
DashboardHorizonWeb UIConsole
Bare MetalIronicPhysical servers-
DNSDesignateDNS managementRoute 53
Load BalancerOctaviaLBaaSELB
File StorageManilaShared filesystemsEFS
ContainersMagnumK8s clustersEKS

5. OpenStack Deployment

5.1 Deployment Methods Compared

MethodPurposeComplexityProduction
DevStackDevelopment/TestingLowNot suitable
Kolla-AnsibleProductionMediumRecommended
TripleOLarge-scale productionHighYes
MicroStack (Snap)Single-node testingVery lowNot suitable
OpenStack-AnsibleProductionMediumYes

5.2 Minimum Hardware Requirements

Controller Nodes (3 for HA):
  - CPU: 8+ cores
  - RAM: 32GB+
  - Disk: 500GB SSD (OS + DB)
  - NIC: 2+ (management + service)

Compute Nodes (N nodes):
  - CPU: As many cores as possible (scales with VM count)
  - RAM: 128GB+ (sum of VM memory + overhead)
  - Disk: SSD (local ephemeral)
  - NIC: 2+

Storage Nodes (Ceph OSD, 3+ nodes):
  - CPU: 1 core per OSD
  - RAM: 4GB per OSD
  - Disk: NVMe/SSD (OSD) + SSD (WAL/DB)
  - NIC: 10GbE+

5.3 Kolla-Ansible Deployment

# 1. Preparation
pip install kolla-ansible

# 2. Inventory setup
cp /usr/share/kolla-ansible/ansible/inventory/multinode .
# Edit inventory file

# 3. Global configuration
# /etc/kolla/globals.yml
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "2024.2"

kolla_internal_vip_address: "10.0.0.100"
kolla_external_vip_address: "203.0.113.100"

network_interface: "eth0"
neutron_external_interface: "eth1"

enable_cinder: "yes"
enable_cinder_backend_lvm: "no"
enable_cinder_backend_ceph: "yes"

enable_heat: "yes"
enable_horizon: "yes"
enable_neutron_provider_networks: "yes"

ceph_cinder_user: "cinder"
ceph_cinder_pool_name: "volumes"
# 4. Generate passwords
kolla-genpwd

# 5. Bootstrap
kolla-ansible -i multinode bootstrap-servers

# 6. Pre-checks
kolla-ansible -i multinode prechecks

# 7. Deploy
kolla-ansible -i multinode deploy

# 8. Post-deploy (generate OpenRC/clouds.yaml)
kolla-ansible -i multinode post-deploy

# 9. Verify
source /etc/kolla/admin-openrc.sh
openstack service list
openstack compute service list
openstack network agent list

5.4 Network Architecture

+------------------------------------------------------------+
|  External Network (203.0.113.0/24)                          |
|                        |                                    |
|                  [External Router]                           |
|                        |                                    |
|  Management Network (10.0.0.0/24)                           |
|  +----------+  +----------+  +----------+                   |
|  |Controller|  |Controller|  |Controller|                   |
|  |   Node 1 |  |   Node 2 |  |   Node 3 |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Tunnel Network (10.0.1.0/24) - VXLAN                       |
|        |              |              |                       |
|  +----------+  +----------+  +----------+                   |
|  | Compute  |  | Compute  |  | Compute  |                   |
|  |  Node 1  |  |  Node 2  |  |  Node 3  |                   |
|  +----------+  +----------+  +----------+                   |
|        |              |              |                       |
|  Storage Network (10.0.2.0/24) - Ceph                       |
|        |              |              |                       |
|  +----------+  +----------+  +----------+                   |
|  |  Ceph    |  |  Ceph    |  |  Ceph    |                   |
|  |  OSD 1   |  |  OSD 2   |  |  OSD 3   |                   |
|  +----------+  +----------+  +----------+                   |
+------------------------------------------------------------+

6. Networking Deep Dive

6.1 Provider vs Self-service Networks

Provider Networks:

  • Created by administrators, mapped directly to physical networks
  • VLAN-based, uses external routing equipment
  • Simple but limited flexibility

Self-service (Tenant) Networks:

  • Tenants create freely
  • Isolated via VXLAN/GRE tunneling
  • Neutron L3 agent handles routing
  • Floating IPs for external access

6.2 OVS vs OVN

Open vSwitch (OVS):
- Software virtual switch
- Managed by neutron-openvswitch-agent
- Mature and stable
- Performance can degrade at scale

OVN (Open Virtual Network):
- SDN solution built on top of OVS
- Distributed architecture (no central agent needed)
- Native L3/NAT/DHCP/ACL support
- Superior performance at scale
- Recommended backend for modern OpenStack
# Check OVN configuration
ovn-sbctl show
ovn-nbctl show

# List logical switches/routers
ovn-nbctl ls-list
ovn-nbctl lr-list

6.3 VXLAN Tunneling

VXLAN (Virtual Extensible LAN):
- Encapsulates L2 frames over L3 via UDP port 4789
- 24-bit VNI allows ~16 million segments (VLAN: 4,096)
- Ideal for multi-tenant environments

Packet Structure:
+------+------+------+------+---------+------+------+
|Outer | Outer| Outer| VXLAN| Inner   |Inner |Inner |
|Ether | IP   | UDP  |Header| Ether   |  IP  |Payload|
+------+------+------+------+---------+------+------+

6.4 DVR (Distributed Virtual Router)

DVR distributes routing to each compute node, eliminating the network node bottleneck.

Without DVR (Centralized):
  VM -> Compute Node -> [Network Node: L3 Agent] -> External

With DVR:
  VM -> Compute Node [Local L3 Agent] -> External
  (East-West traffic also handled locally)

6.5 Security Groups and FWaaS

# Create security group
openstack security group create web-sg
openstack security group rule create \
  --protocol tcp --dst-port 80 --remote-ip 0.0.0.0/0 web-sg
openstack security group rule create \
  --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 web-sg
openstack security group rule create \
  --protocol tcp --dst-port 22 --remote-ip 10.0.0.0/8 web-sg

7. Storage Architecture

7.1 Storage Types

+------------------------------------------------------------+
|  Ephemeral Storage                                          |
|  - Deleted when VM is deleted                               |
|  - Local disk (fast but non-persistent)                     |
|  - Can convert to permanent image via snapshot              |
+------------------------------------------------------------+
|  Persistent Block Storage (Cinder)                          |
|  - Independent lifecycle from VM                            |
|  - Can be reattached to different VMs                       |
|  - Supports snapshots, clones, encryption                   |
+------------------------------------------------------------+
|  Object Storage (Swift)                                     |
|  - REST API access                                          |
|  - Stores VM images, backup data                            |
|  - High durability (triple replication)                     |
+------------------------------------------------------------+
|  Shared File System (Manila)                                |
|  - NFS/CIFS shares                                          |
|  - Multiple VMs access simultaneously                       |
+------------------------------------------------------------+

7.2 Ceph Integration

Ceph is the best-integrated distributed storage for OpenStack.

Ceph + OpenStack Mapping:
- Ceph RBD  -> Cinder (block storage)
- Ceph RBD  -> Nova (ephemeral disks, live migration)
- Ceph RBD  -> Glance (image storage)
- Ceph RGW  -> Swift API compatible (object storage)
- CephFS    -> Manila (shared file systems)
# Create Ceph pools for OpenStack
ceph osd pool create volumes 128
ceph osd pool create images 64
ceph osd pool create vms 128
ceph osd pool create backups 64

# Create Ceph auth keys
ceph auth get-or-create client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes, profile rbd pool=vms, profile rbd pool=images'

ceph auth get-or-create client.glance \
  mon 'profile rbd' \
  osd 'profile rbd pool=images'

7.3 Storage Tiering

TierMediaUse CaseLatency
Tier 0NVMe SSDDatabases, high-performance VMsSub 0.1ms
Tier 1SATA SSDGeneral VMs, web serversSub 0.5ms
Tier 2HDD (10K RPM)Archive, backupsSub 5ms
Tier 3Object (S3)Cold dataTens of ms

8. Performance Optimization

8.1 CPU Optimization

# CPU pinning + NUMA awareness (nova.conf)
# [DEFAULT]
# vcpu_pin_set = 4-31
# reserved_host_cpus = 0-3
# cpu_allocation_ratio = 4.0

# [libvirt]
# cpu_mode = host-passthrough
<!-- High-performance VM: CPU pinning + Hugepages + NUMA -->
<domain type='kvm'>
  <vcpu placement='static'>16</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='4'/>
    <vcpupin vcpu='1' cpuset='5'/>
    <!-- ... -->
    <emulatorpin cpuset='0-1'/>
  </cputune>
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>
  <memoryBacking>
    <hugepages>
      <page size='1' unit='GiB'/>
    </hugepages>
  </memoryBacking>
  <cpu mode='host-passthrough'>
    <topology sockets='1' dies='1' cores='16' threads='1'/>
    <numa>
      <cell id='0' cpus='0-15' memory='32' unit='GiB'/>
    </numa>
  </cpu>
</domain>

8.2 Network Optimization

Performance ranking (low -> high):
1. virtio-net (software virtualization) - ~10Gbps
2. vhost-net (kernel-mode datapath) - ~15Gbps
3. DPDK (userspace packet processing) - ~40Gbps
4. SR-IOV (hardware passthrough) - near-native (~100Gbps)

8.3 Storage I/O Optimization

# virtio-scsi (multi-queue support)
# Supports more devices than virtio-blk, SCSI command support

# I/O scheduler (none recommended for NVMe)
echo none > /sys/block/nvme0n1/queue/scheduler
<!-- I/O thread separation (libvirt) -->
<iothreads>4</iothreads>
<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2' cache='none' io='native' iothread='1'/>
  <source file='/var/lib/libvirt/images/vm.qcow2'/>
  <target dev='vda' bus='virtio'/>
</disk>

8.4 Overcommit Ratios

ResourceDefaultRecommended (General)Recommended (High-Perf)
CPU16:14:1 to 8:11:1 (pinned)
RAM1.5:11:1 to 1.2:11:1 (hugepages)
Disk1.0:12:1 (thin)1:1 (thick)

9. OpenStack vs VMware vs Proxmox

FeatureOpenStackVMware vSphereProxmox VE
LicenseOpen Source (Apache 2.0)Commercial (expensive)Open Source (AGPL) + commercial
HypervisorKVM (default)ESXiKVM + LXC
InstallationDifficultMediumVery easy
Learning CurveVery steepSteepGentle
ScalabilityThousands of nodesHundreds of nodesTens of nodes
API/AutomationPowerful REST APIvSphere API, PowerCLIREST API, CLI
Multi-tenancyStrong (Project/Domain)Limited (vCenter)Basic (Pool/Permission)
SDNNeutron (OVS/OVN)NSXLinux Bridge/OVS
StorageCinder + Ceph/NFS/iSCSIvSAN, VMFSZFS, Ceph, LVM
HAPacemaker, HAProxyvSphere HA, FTBuilt-in HA
Container SupportMagnum (K8s)TanzuBuilt-in LXC
Commercial SupportRed Hat, Canonical, SUSEVMware (Broadcom)Proxmox
TCOLow (ops staff needed)Very highVery low
Best ForLarge-scale cloudsEnterpriseSmall-medium

Selection Guide:

  • OpenStack: Large-scale private/public clouds, telcos, research institutions, when AWS-like self-service is needed
  • VMware: Existing enterprise environments, Windows-centric, vendor support required, budget available
  • Proxmox: SMBs, home labs, simple virtualization, rapid adoption

10. Production Best Practices

10.1 High Availability (HA)

Control Plane HA:
- Minimum 3 controller nodes
- HAProxy + Keepalived (VIP)
- Pacemaker/Corosync (cluster management)
- Galera Cluster (MariaDB synchronous replication)
- RabbitMQ mirrored queues

Data Plane HA:
- Ceph (triple replication, automatic node failure recovery)
- Neutron DVR (eliminates network node SPOF)
- Nova instance HA (Masakari)
# Check HAProxy status
echo "show stat" | socat stdio /var/run/haproxy/admin.sock

# Galera cluster status
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_status';"

# RabbitMQ cluster status
rabbitmqctl cluster_status

10.2 Monitoring

# Prometheus + OpenStack Exporter configuration
# prometheus.yml
scrape_configs:
  - job_name: 'openstack'
    static_configs:
      - targets: ['openstack-exporter:9198']
    metrics_path: '/metrics'

  - job_name: 'ceph'
    static_configs:
      - targets: ['ceph-mgr:9283']

  - job_name: 'libvirt'
    static_configs:
      - targets: ['compute1:9177', 'compute2:9177']

Key Monitoring Metrics:

CategoryMetricThreshold
NovaActive instance count80% of capacity
NovaScheduling failure rateAlert at 5%+
NeutronFloating IP utilizationAlert at 90%
CinderVolume creation failure rateAlert at 1%+
CephOSD statusAlert on 1+ down OSD
CephUtilizationWarning 70%, Critical 85%
RabbitMQQueue lengthAlert at 1000+
MariaDBReplication lagAlert at 1s+

10.3 Backup Strategies

# OpenStack database backup
mysqldump --all-databases --single-transaction \
  --routines --triggers > openstack-db-backup.sql

# Cinder volume backup (Ceph)
rbd snap create volumes/volume-UUID@backup-20260325
rbd export volumes/volume-UUID@backup-20260325 volume-backup.raw

# Glance image backup
openstack image save --file ubuntu-backup.qcow2 ubuntu-22.04

# Nova instance snapshot
openstack server image create --name "web-server-backup" web-server-01

10.4 Upgrade Strategy

Rolling Upgrade Procedure:
1. Upgrade controller nodes one at a time
   - Minimize service disruption
   - Leverage API backward compatibility
2. Run database migrations
3. Upgrade compute nodes one at a time
   - Live migrate VMs to create empty nodes for upgrade
4. Upgrade Neutron agents
5. Verify all services

11. Quiz

Q1. What type of hypervisor is KVM?

Answer: Type-1 (Bare-Metal) Hypervisor

KVM operates as a Linux kernel module, transforming the Linux kernel itself into a hypervisor. Since it is embedded in the host OS (Linux) that runs directly on hardware, it is classified as Type-1. It leverages Intel VT-x/AMD-V hardware virtualization extensions for high performance.

Q2. Which OpenStack service manages virtual networks, subnets, and routers?

Answer: Neutron

Neutron is the OpenStack Networking-as-a-Service component. It consists of the ML2 plugin, OVS/OVN agents, L3 agent, DHCP agent, and more. It manages virtual networks, subnets, routers, security groups, and Floating IPs. It is the equivalent of AWS VPC.

Q3. What is the key advantage of VXLAN tunneling over VLAN?

Answer: Segment count expansion (from 4,096 to approximately 16 million)

VLAN uses a 12-bit VLAN ID supporting a maximum of 4,096 segments. VXLAN uses a 24-bit VNI (Virtual Network Identifier), supporting approximately 16 million network segments. This is essential for large-scale multi-tenant cloud environments.

Q4. What does KSM (Kernel Same-page Merging) do?

Answer: Shares identical memory pages across VMs to reduce physical memory usage

KSM is a Linux kernel feature that merges identical memory pages from multiple VMs into a single physical page (Copy-on-Write). The more VMs running the same OS image, the greater the benefit. However, there is scanning overhead, so proper tuning is required.

Q5. Why is Kolla-Ansible the preferred method for OpenStack production deployment?

Answer: Containerized service deployment provides management ease, reproducibility, and upgrade convenience

Kolla-Ansible packages each OpenStack service as a Docker container for deployment. This enables environment isolation (no dependency conflicts), fast rollback, reproducible deployments, and independent per-service upgrades. Being Ansible-based makes automation and repeated deployments straightforward, with production HA configuration supported out of the box.


12. References

  1. OpenStack Official Documentation - docs.openstack.org
  2. KVM Official Site - linux-kvm.org
  3. libvirt Official Documentation - libvirt.org/docs.html
  4. QEMU Official Documentation - qemu.org/documentation
  5. Kolla-Ansible Documentation - docs.openstack.org/kolla-ansible/latest
  6. Ceph Official Documentation - docs.ceph.com
  7. Open vSwitch Documentation - docs.openvswitch.org
  8. OVN Architecture - ovn.org
  9. Red Hat OpenStack Platform - access.redhat.com/documentation/en-us/red_hat_openstack_platform
  10. Proxmox VE Documentation - pve.proxmox.com/wiki/Main_Page
  11. VMware vSphere Documentation - docs.vmware.com
  12. OpenStack Foundation (OpenInfra) - openinfra.dev
  13. DPDK Documentation - doc.dpdk.org
  14. SR-IOV Guide - kernel.org/doc/html/latest/PCI/sriov-howto.html