13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] VMware ESXi

  • [Proxmox] Proxmox VE vs VMware ESXi: 홈랩 환경 마이그레이션 1년 후기

    [Proxmox] Proxmox VE vs VMware ESXi: 홈랩 환경 마이그레이션 1년 후기

    목차

    Proxmox VE vs VMware ESXi: 홈랩 환경 마이그레이션 1년 후기

    Proxmox VE 마이그레이션을 고민하시는 분들이 요즘 꽤 많으시더라고요. 저도 홈랩(Home Lab, 집에서 운영하는 개인 실험실) 환경을 몇 년 동안 VMware ESXi로 굴리다가, 결국 Proxmox VE로 옮겨서 1년 정도 써봤습니다. 결론부터 말씀드리면, 홈랩 기준에서는 꽤 만족스러운 선택이었습니다. 물론 처음엔 익숙한 화면이 아니라서 좀 헤맸고, 네트워크 브리지(Bridge, 가상 스위치 역할)랑 스토리지(Storage, 저장소) 구조에서 삽질도 했습니다 ㅎㅎ 근데 실제로 써보니까 관리 흐름이 단순해지고, 실험용 VM(Virtual Machine, 가상 머신)과 LXC(Linux Container, 리눅스 컨테이너)까지 한 화면에서 다루는 점이 진짜 편하더라고요.

    이번 글은 제품 스펙 비교표만 나열하는 글은 아닙니다. VMware ESXi에서 Proxmox VE로 넘어가면서 무엇이 달라졌는지, 그리고 1년 동안 홈랩에서 굴려보니 어떤 점이 좋았고 어떤 점은 생각보다 불편했는지, 경험 위주로 정리해보겠습니다. 혹시 저처럼 “그냥 잘 돌아가던 걸 왜 굳이 바꾸지?”라는 생각이 드셨다면, 아마 도움이 되실 겁니다.

    Proxmox VE 마이그레이션을 위한 홈랩 가상화 환경 전체 아키텍처 이미지

    ESXi와 Proxmox VE가 각각 스토리지, 브리지 네트워크, 백업 저장소와 연결된 홈랩 전체 구조를 보여주는 이미지입니다.

    왜 VMware ESXi에서 Proxmox VE로 옮겼는가

    제가 ESXi를 오래 쓴 이유는 단순했습니다. 안정적이었고, 익숙했고, 기업 환경 감성이 있었거든요. 가상화 비교 관점에서도 ESXi는 오래 검증된 하이퍼바이저(Hypervisor, 가상화 계층)라서 믿음이 갔습니다. 실제로 VM 몇 대 올려서 NAS, 테스트용 쿠버네티스(Kubernetes), 모니터링 스택 정도 돌리는 데는 큰 문제가 없었습니다.

    근데 홈랩은 회사와 다르죠. 라이선스 정책, 관리 편의성, 백업 실험, 디스크 포맷 변경, 컨테이너 테스트 같은 자잘한 요구가 계속 생깁니다. 여기서부터 Proxmox VE가 조금씩 눈에 들어오기 시작했습니다. 쉽게 말해, ESXi는 깔끔하고 단단한 느낌이고, Proxmox VE는 좀 더 만지작거리기 좋은 실험실 스타일에 가깝습니다.

    • 웹 UI(Web User Interface, 웹 관리 화면)에서 VM과 컨테이너를 함께 관리할 수 있었습니다.
    • KVM(Kernel-based Virtual Machine, 리눅스 커널 기반 가상화)과 LXC를 같이 쓰는 구조가 홈랩에 잘 맞았습니다.
    • 스토리지 선택 폭이 넓어서 로컬 디스크, ZFS, NFS 같은 구성이 자연스러웠습니다.
    • 백업과 복원 흐름을 제가 원하는 방식으로 잡기 편했습니다.

    반대로, “무조건 Proxmox VE가 더 좋다”는 아닙니다. 기업 운영 기준으로 보면 VMware ESXi가 익숙한 팀도 많고, 기존 운영 절차와 잘 맞는 경우도 많습니다. 다만 홈랩이라면 이야기가 좀 달라집니다. 직접 만져보고 부숴보고 다시 올리는 과정이 잦기 때문에, 제 기준에서는 Proxmox VE 쪽이 손에 더 잘 붙었습니다.

    Proxmox VE와 VMware ESXi, 개념부터 쉽게 정리

    저도 처음엔 이게 뭔가 싶었는데, 막상 구조를 풀어보면 어렵지 않습니다. 쉽게 말해 두 제품 모두 “하드웨어 위에서 여러 운영체제를 동시에 돌리게 해주는 플랫폼”입니다. 다만 접근 방식이 조금 다릅니다.

    항목 VMware ESXi Proxmox VE
    기반 구조 전용 하이퍼바이저 중심 Debian 기반에 KVM/LXC 통합
    관리 감성 정돈된 기업형 유연한 홈랩형
    컨테이너 운영 별도 접근 필요 LXC를 기본 흐름 안에서 운영 가능
    스토리지 실험 보수적으로 운영하는 편 ZFS, 디렉터리, 네트워크 스토리지 연동이 편한 편
    학습 난이도 UI는 익숙하지만 생태계 의존이 있음 리눅스 감각이 있으면 확장성이 좋음

    여기서 중요한 포인트! Proxmox VE 마이그레이션은 단순히 하이퍼바이저를 갈아타는 작업이 아닙니다. 네트워크 구조, 백업 전략, 디스크 포맷, 운영 습관까지 같이 바뀝니다. 그래서 “성능이 더 좋냐”만 보면 판단이 틀어질 수 있습니다. 제가 직접 해보니, 체감 만족도는 성능보다도 운영 동선이 내 손에 맞느냐에서 갈리더라고요.

    마이그레이션 전에 꼭 점검한 것들

    실전 들어가기 전에 저는 체크리스트부터 만들었습니다. 이걸 안 하면 높은 확률로 중간에 멈춥니다. 특히 홈랩은 문서화가 느슨해서, 막상 옮기려 하면 “이 VM이 무슨 용도였지?”가 꼭 나오거든요.

    1. VM 인벤토리 정리: 어떤 VM이 항상 켜져 있어야 하는지, 테스트용인지, 폐기 가능한지 구분했습니다.
    2. 스토리지 구조 확인: VMDK(Virtual Machine Disk, VMware 디스크 포맷) 기준인지, 별도 NAS에 의존하는지 확인했습니다.
    3. 네트워크 의존성 파악: VLAN(Virtual LAN, 가상 분리 네트워크), 브리지, 고정 IP, 방화벽 규칙을 적어뒀습니다.
    4. 백업 선행: 마이그레이션 전에 무조건 백업부터 했습니다. 이건 진짜 중요합니다.
    5. 다운타임 허용 범위 확인: 홈 어시스턴트(Home Assistant), DNS, 리버스 프록시(Reverse Proxy, 역방향 프록시)처럼 끊기면 집안 전체가 불편한 서비스는 우선순위를 따로 잡았습니다.

    제 경우에는 특히 DNS와 리버스 프록시가 문제였습니다. 이 둘이 내려가면 나머지 서비스가 멀쩡해도 다 죽은 것처럼 보이거든요. 그래서 핵심 인프라 VM부터 옮기지 않고, 덜 중요한 워크로드부터 시험 이전을 했습니다. 이게 나중에 정신 건강에 정말 좋았습니다.

    실전: Proxmox VE 마이그레이션 진행 순서

    이제 본론입니다. 아래 순서는 제가 실제로 홈랩에서 썼던 흐름을 정리한 겁니다. 환경마다 조금 다르겠지만, 큰 틀은 비슷합니다.

    1. Proxmox VE 설치 후 기본 상태 확인

    설치 직후에는 무조건 현재 상태부터 확인했습니다. 특히 네트워크와 저장소가 정상인지 먼저 봐야 합니다.

    pveversion
ip a
pvesm status
qm list
pct list

    위 명령은 각각 버전 확인, 네트워크 인터페이스 확인, 스토리지 상태 확인, VM 목록, LXC 목록 확인입니다. 처음엔 별거 아닌 것 같았는데, 실제로 써보니까 여기서 꼬이면 뒤가 다 꼬이더라고요.

    2. 브리지 네트워크 구성 점검

    ESXi에서 vSwitch(가상 스위치) 개념에 익숙하셨다면, Proxmox VE에서는 Linux Bridge(리눅스 브리지) 설정을 먼저 이해하셔야 합니다. 저도 처음엔 이름만 다르고 비슷하겠지 했는데, 브리지에 IP를 어디에 붙이는지에서 잠깐 멈췄습니다.

    auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.10.20/24
    gateway 192.168.10.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

    핵심은 물리 NIC(Network Interface Card, 네트워크 인터페이스)는 보통 manual로 두고, 실제 IP는 브리지에 붙인다는 점입니다. 이 구조를 이해하면 VM NIC 연결이 훨씬 명확해집니다.

    Proxmox VE 마이그레이션 중 브리지 네트워크와 스토리지 구성 예시 이미지

    Proxmox VE 관리 화면에서 브리지 네트워크와 스토리지 상태를 함께 보여주는 설정 예시 이미지입니다.

    3. VMware 디스크를 옮기고 VM 재구성

    가장 신경 썼던 구간입니다. VMware ESXi에서 내보낸 디스크를 Proxmox VE 쪽에서 받아서 붙이는 흐름이죠. 제 경우에는 일부 VM은 새로 만들고 디스크만 붙였고, 일부는 애플리케이션 레벨에서 재설치했습니다. 후자가 귀찮긴 한데, 결과적으로 더 깔끔한 경우도 있었습니다.

    qemu-img info source-disk.vmdk
qemu-img convert -f vmdk -O qcow2 source-disk.vmdk vm-100-disk-0.qcow2

    그 다음 Proxmox VE에서 VM을 만들고 디스크를 연결했습니다. 여기서 CPU 타입, BIOS/UEFI, 디스크 버스 종류가 맞지 않으면 부팅이 안 될 수 있습니다. 저도 처음엔 이 부분에서 “왜 안 켜지지?” 하다가 한참 봤네요.

    qm create 100 --name ubuntu-test --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 100 vm-100-disk-0.qcow2 local-lvm
qm set 100 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-100-disk-0
qm set 100 --boot order=scsi0

    여기서 중요한 건 가져오기보다 검증입니다. VM이 켜진다고 끝이 아니고, 서비스가 정상 기동하는지, 네트워크 라우팅이 맞는지, 시간 동기화가 되는지까지 봐야 합니다.

    4. 백업 정책 다시 설계

    마이그레이션하면서 오히려 가장 만족했던 부분이 백업입니다. 예전에는 “일단 돌아가니까 됐지”였는데, Proxmox VE로 옮긴 뒤에는 스냅샷(Snapshot, 시점 복사)과 백업 작업을 좀 더 의식적으로 관리하게 됐습니다.

    vzdump 100 --mode snapshot --storage backup-nfs --compress zstd
vzdump 101 --mode snapshot --storage backup-nfs --compress zstd

    백업 이름 규칙과 보관 정책을 정리해두니 복원 테스트가 쉬워졌습니다. 홈랩에서 진짜 중요한 건 백업 “존재”보다도 복원이 실제로 되는지 확인하는 습관이더라고요.

    ⚠️ 실제로 겪었던 문제와 해결 과정

    이 섹션이 아마 제일 현실적일 겁니다. Proxmox VE 마이그레이션 자체는 어렵지 않은데, 중간중간 사소한 함정이 있습니다.

    네트워크 인터페이스 이름이 달라져서 부팅은 되는데 통신이 안 됨

    이거 진짜 흔합니다. ESXi에서 쓰던 VM을 옮기면 게스트 OS 안에서 NIC 이름이 바뀌는 경우가 있거든요. 예를 들어 `ens160`으로 잡히던 게 `ens18`처럼 바뀌면, OS는 켜졌는데 네트워크가 죽어 있습니다.

    해결은 단순했습니다. 게스트 OS 안에서 인터페이스 이름을 다시 확인하고, Netplan(넷플랜, 네트워크 설정 도구)이나 기존 네트워크 스크립트를 수정했습니다.

    ip a
ip route
ping -c 4 192.168.10.1

    디스크는 붙었는데 부팅 로더가 꼬임

    특히 오래된 VM일수록 BIOS/UEFI 설정 차이 때문에 부팅이 안 되는 경우가 있었습니다. 처음엔 디스크 손상인 줄 알고 식겁했는데, 실제로는 부팅 모드가 안 맞는 경우가 있더라고요. 이럴 때는 VM 하드웨어 옵션을 다시 보고, 디스크 버스나 부트 순서를 조정해보면 해결되는 경우가 많았습니다.

    성능 문제라기보다 스토리지 설계 문제였음

    처음엔 “Proxmox VE가 느린가?” 싶었던 순간이 있었는데, 나중에 보니 스토리지 캐시와 디스크 배치 이슈였습니다. 결국 하이퍼바이저보다도 디스크 I/O(Input/Output, 입출력) 설계가 체감 성능을 더 크게 좌우하더라고요. 이건 ESXi든 Proxmox VE든 비슷합니다.

    • 자주 쓰는 VM은 빠른 스토리지에 배치했습니다.
    • 백업 저장소는 운영 디스크와 분리했습니다.
    • 로그와 모니터링을 통해 병목이 CPU인지 디스크인지 먼저 확인했습니다.

    삽질 좀 했습니다 ㅎㅎ 그런데 이 과정을 거치고 나니까, 단순 제품 비교보다 내 홈랩 설계가 얼마나 정리돼 있는지를 더 많이 보게 되더라고요.

    Proxmox VE 마이그레이션 과정의 VM 디스크 변환과 문제 해결 흐름 이미지

    VMDK 변환, VM 재등록, 네트워크 점검까지 이어지는 실제 마이그레이션 작업 흐름을 시각화한 이미지입니다.

    1년 써보니 체감한 결과

    1년 정도 지나고 나서 보니, 저는 결국 Proxmox VE 환경에 완전히 적응했습니다. 오히려 다시 VMware ESXi로 돌아가라고 하면 좀 답답할 것 같더라고요. 이유는 성능 숫자 하나 때문이 아니라, 운영의 유연성 때문입니다.

    • VM과 LXC를 같이 다루는 흐름이 홈랩에 잘 맞았습니다.
    • 웹 UI와 CLI(Command Line Interface, 명령줄 인터페이스)를 오가며 관리하기 편했습니다.
    • 백업과 복원 테스트를 더 자주 하게 됐습니다.
    • 실험 환경 분리가 쉬워져서 새로운 서비스를 올리는 부담이 줄었습니다.

    특히 Kubernetes 노드 테스트, 리버스 프록시 교체, 모니터링 재구성 같은 작업이 훨씬 가벼워졌습니다. “망가지면 다시 만들면 되지”라는 감각이 생기니까, 홈랩이 훨씬 재미있어졌어요. 이건 숫자로 표현하기 어려운 장점이더라고요.

    물론 단점도 있습니다. 리눅스 기반이라서, ESXi 특유의 일체형 경험에 익숙한 분은 초반에 거부감이 있을 수 있습니다. 그리고 잘 모르는 상태에서 너무 많은 걸 한 번에 바꾸면 오히려 운영 난이도가 올라갑니다. 그래서 제 추천은 간단합니다. 한 번에 전체 이전하지 말고, 낮은 중요도의 VM부터 옮겨보세요.

    Proxmox VE 마이그레이션 1년 운영 결과와 안정화 상태를 보여주는 이미지

    가동 중인 VM과 컨테이너, 백업 상태, 스토리지 사용량이 안정적으로 보이는 운영 결과 이미지입니다.

    가상화 비교 관점에서 정리한 선택 기준

    독자분들이 제일 궁금해하실 부분이라 따로 정리해보겠습니다. 결국 중요한 건 “무엇이 더 우월하냐”가 아니라 “내 환경에 무엇이 더 맞느냐”입니다.

    이런 분께 추천 더 잘 맞는 방향 이유
    기업형 워크플로에 익숙함 VMware ESXi 유지 검토 기존 운영 습관과 절차가 익숙할 수 있음
    홈랩에서 실험을 자주 함 Proxmox VE 고려 VM/LXC 혼합 운영과 유연한 설정이 편함
    리눅스 CLI에 익숙함 Proxmox VE 유리 문제 분석과 확장이 자연스러움
    최소 변경을 선호함 현 환경 유지 마이그레이션 자체가 리스크이기 때문

    제가 직접 해보니, Proxmox VE 마이그레이션은 “최신이라서” 혹은 “남들이 많이 하니까”가 아니라, 내 홈랩 운영 방식과 맞아떨어질 때 가장 만족도가 높았습니다. 저처럼 NAS, DNS, 프록시, 개발용 VM, 테스트용 컨테이너를 뒤섞어 쓰는 분이면 특히 체감이 클 수 있습니다.

    자주 묻는 질문

    Q1. 기존 VMware ESXi VM을 전부 그대로 옮겨야 할까요?

    꼭 그렇지는 않습니다. 애플리케이션 구성이 단순한 서비스는 새로 만들고 데이터만 옮기는 편이 더 깔끔할 때도 많습니다. 오래된 VM일수록 찌꺼기가 많아서, 오히려 재구성이 관리에 도움이 됩니다.

    Q2. Proxmox VE 마이그레이션 후 바로 체감할 만한 장점이 있나요?

    홈랩 기준으로는 관리 편의성과 실험 자유도가 가장 먼저 느껴집니다. 성능보다도 운영 동선이 가벼워지는 느낌이 큽니다.

    Q3. 초보자도 괜찮을까요?

    가능은 합니다. 다만 네트워크 브리지와 스토리지 개념은 꼭 먼저 잡고 들어가시는 게 좋습니다. 저도 처음엔 헷갈렸는데, 이 두 가지만 이해하면 진입 장벽이 확 낮아집니다.

    VMware ESXi와 Proxmox VE의 가상화 비교 요약 이미지

    홈랩 사용자의 관점에서 ESXi와 Proxmox VE의 차이를 한눈에 요약한 비교 이미지입니다.

    마무리: 1년 후에도 유지한 이유

    정리해보면 이렇습니다. VMware ESXi는 여전히 좋은 플랫폼입니다. 다만 제 홈랩에서는 Proxmox VE가 더 손에 맞았습니다. 직접 써보니 “관리”, “실험”, “복원”, “재구성” 이 네 가지 흐름이 훨씬 자연스러웠거든요. 드디어 됐다! 싶었던 순간이 백업 복원 테스트까지 매끄럽게 끝났을 때였습니다.

    혹시 지금 Proxmox VE 마이그레이션을 고민 중이시라면, 한 번에 다 옮기지 마시고 덜 중요한 VM 하나만 먼저 이전해보세요. 그 과정에서 네트워크, 스토리지, 백업 철학이 같이 정리됩니다. 그게 진짜 핵심입니다. 다음 글에서는 홈랩 기준으로 Proxmox Backup Server를 어떻게 붙여서 백업 전략을 단순화했는지 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈 네트워크 분리 구성과 함께 보시면 더 이해가 잘 되실 겁니다.

    결국 가상화 비교의 답은 제품 소개 페이지에 있는 게 아니라, 내가 1년 뒤에도 불편 없이 계속 쓸 수 있느냐에 있더라고요. 제 경우 그 답은 Proxmox VE였습니다.

  • [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    목차

    [클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

    VMware OpenStack 마이그레이션을 고민하는 분들이 요즘 정말 많으시죠. 라이선스 정책 변화나 비용 구조, 그리고 운영 자동화 수준을 다시 점검해야 하는 시점이 오면 결국 한 번은 ESXi OpenStack 전환을 검토하게 되더라고요. 저도 처음엔 “하이퍼바이저(Hypervisor, 가상화 실행 계층)만 바꾸면 끝나는 거 아닌가?” 싶었는데, 실제로 해보니 전혀 아니었습니다. 컴퓨트(Compute), 네트워크(Network), 스토리지(Storage), 이미지(Image) 관리 방식이 다 바뀌거든요. 그래서 오늘은 제가 홈랩과 내부 테스트 환경에서 진행했던 흐름을 바탕으로, VMware 대안 OpenStack을 검토할 때 어디서 막히고 어떻게 풀어야 하는지 경험 위주로 정리해보겠습니다.

    특히 이 글은 “OpenStack이 좋아 보이는데 실제 전환은 어떻게 하지?”, “클라우드 마이그레이션 사례를 봐도 다 추상적이던데 실무 감각이 있는 글이 없네” 하셨던 분들께 맞춰 썼습니다. 숫자 뻥튀기나 과장 없이, 제가 직접 부딪히며 정리한 포인트만 담아볼게요.

    VMware OpenStack 마이그레이션 전체 아키텍처 다이어그램

    기존 ESXi 가상머신이 이미지 변환과 네트워크 재설계를 거쳐 OpenStack으로 이동하는 전체 흐름을 보여주는 개요 이미지입니다.

    왜 VMware ESXi에서 OpenStack으로 옮기게 될까요

    쉽게 말해서 ESXi는 가상화 플랫폼 중심의 운영 경험을 주고, OpenStack은 클라우드 운영체계에 가깝습니다. 둘 다 가상머신(VM, Virtual Machine)을 띄운다는 점은 같지만, 운영 철학이 꽤 다릅니다. VMware 환경은 관리 콘솔이 잘 정리되어 있고 초기 안정화가 쉬운 편이죠. 반면 OpenStack은 구성 요소가 많아서 처음엔 복잡해 보이지만, 자동화와 API(Application Programming Interface, 프로그램 제어 인터페이스) 중심 운영으로 넘어가면 확실히 강점이 있습니다.

    제가 전환을 결심했던 이유도 단순했습니다.

    • 비용 구조를 장기적으로 통제하고 싶었습니다.
    • API 기반 자동화를 더 강하게 가져가고 싶었습니다.
    • 네트워크를 더 세밀하게 분리하고 싶었습니다.
    • 벤더 종속성(Vendor lock-in, 특정 벤더 의존)을 줄이고 싶었습니다.

    다만 여기서 중요한 게 하나 있어요. VMware OpenStack 마이그레이션은 제품 교체가 아니라 운영 모델 전환이라는 점입니다. 이거 무시하면 중간에 꼭 한 번 크게 흔들려요. 저도 처음엔 VM만 잘 옮기면 될 줄 알았는데, 보안그룹(Security Group, 가상 방화벽), 네트워크 세그먼트, 스토리지 타입 설계에서 삽질 좀 했습니다 ㅎㅎ

    핵심 개념 정리: ESXi와 OpenStack은 무엇이 다를까

    이 부분은 꼭 짚고 넘어가야 해요. 독자분들이 제일 많이 헷갈려 하시는 부분이거든요.

    영역 VMware ESXi 중심 OpenStack 중심
    가상화 실행 ESXi 보통 KVM(Kernel-based Virtual Machine)
    관리 계층 vCenter OpenStack API와 Horizon
    이미지 관리 템플릿, OVA/OVF Glance(글랜스, 이미지 서비스)
    컴퓨트 제어 클러스터/호스트 중심 Nova(노바, 컴퓨트 서비스)
    네트워크 vSwitch, 포트 그룹 Neutron(뉴트론, 네트워크 서비스)
    블록 스토리지 데이터스토어 중심 Cinder(신더, 블록 스토리지)
    인증 vCenter 계정/연동 Keystone(키스톤, 인증 서비스)

    쉽게 말해서 VMware에서는 사람이 콘솔에서 정리해주는 느낌이 강했다면 OpenStack은 “정책과 API로 자원을 선언적으로 다룬다”는 느낌이 더 강합니다. 그래서 클라우드 마이그레이션 사례를 볼 때도 VM 파일 이동만 보면 안 되고, 네트워크와 접근제어를 같이 봐야 합니다.

    전환 전에 꼭 분류해야 할 워크로드

    1. 상태 저장형(Stateful)인지 확인합니다. 데이터베이스처럼 디스크 의존도가 높으면 더 신중해야 합니다.
    2. 정적 IP, MAC 의존성이 있는지 봅니다. 방화벽이나 라이선스 서버가 여기서 많이 걸립니다.
    3. 운영체제 부팅 방식이 BIOS인지 UEFI인지 점검합니다.
    4. 게스트 OS 안에 VMware Tools 의존 설정이 있는지 확인합니다.
    5. 백업/복구 체계가 OpenStack 쪽에서도 유지되는지 따져봅니다.

    제가 직접 해보니 이 분류 작업이 귀찮아 보여도 가장 중요했습니다. 이걸 대충 하면 나중에 전환 일정이 아니라 장애 대응 일정이 되어버립니다.

    사전 준비: VMware OpenStack 마이그레이션 체크리스트

    실전 들어가기 전에 제가 잡았던 기준은 아래와 같았습니다. 여기서 절반이 결정된다고 봐도 됩니다.

    • 대상 VM 목록: 운영, 스테이징, 개발을 분리합니다.
    • 종속성 매핑: DB, 외부 API, DNS, NTP, 라이선스 서버 연결을 정리합니다.
    • 네트워크 설계: OpenStack 테넌트 네트워크와 외부 네트워크를 미리 정의합니다.
    • 이미지 변환 절차: VMDK에서 QCOW2 또는 RAW로 갈지 정합니다.
    • 전환 방식: 빅뱅(Big Bang)보다 단계적 전환을 권장합니다.
    • 롤백 계획: 문제 생기면 다시 ESXi에서 기동할 수 있게 둡니다.

    저는 처음에 네트워크를 나중에 맞추면 되겠지 하고 넘어갔다가, OpenStack의 포트(Port)와 보안그룹 정책 때문에 통신 확인에 시간을 꽤 썼습니다. VM 부팅보다 통신 성공이 더 어렵더라고요.

    실전 구현 1: ESXi VM 추출과 디스크 변환

    이제 본론입니다. 제가 많이 썼던 흐름은 VM 종료 – 디스크 추출 – 이미지 변환 – OpenStack 업로드 – 테스트 부팅 순서였습니다. 무중단 전환이 절대적으로 필요한 서비스가 아니라면, 이 방식이 가장 단순하고 예측 가능했습니다.

    1. VMware 쪽 VM 상태 확인

    govc vm.info -vm /Datacenter/vm/app-server-01

    govc는 VMware vSphere 환경을 CLI(Command Line Interface, 명령행 인터페이스)로 다룰 때 꽤 유용합니다. 환경에 따라 vCenter를 쓰지 않고 직접 ESXi에서 파일을 꺼낼 수도 있습니다.

    2. OVF 또는 VMDK 형태로 추출

    ovftool vi://[email protected]@vcenter.example.local/Datacenter/vm/app-server-01 ./app-server-01

    환경에 따라 OVA/OVF 패키지로 받거나 VMDK만 직접 확보해도 됩니다. 저는 처음엔 OVA가 편해 보여서 그렇게 했는데, 실제로는 디스크 변환만 필요할 때 VMDK 직취득이 더 단순한 경우도 있었습니다.

    3. VMDK를 QCOW2로 변환

    qemu-img convert -p -f vmdk -O qcow2 app-server-01-disk1.vmdk app-server-01.qcow2
qemu-img info app-server-01.qcow2

    여기서 qemu-img는 거의 필수 도구라고 보시면 됩니다. 변환 후 qemu-img info로 포맷과 가상 크기를 꼭 확인하세요. 저는 한 번은 스냅샷 체인이 남은 VMDK를 잘못 잡아서 이미지가 이상하게 올라간 적이 있었습니다.

    VMware OpenStack 마이그레이션에서 VMDK를 QCOW2로 변환하는 작업 흐름 이미지

    VMDK 추출, qemu-img 변환, Glance 업로드로 이어지는 실제 작업 흐름을 설명하는 이미지입니다.

    실전 구현 2: OpenStack 이미지 업로드와 네트워크 구성

    OpenStack으로 넘어오면 이제부터는 이미지와 네트워크가 핵심입니다. 이 구간에서 “드디어 됐다!” 싶다가도 보안그룹 하나 빠뜨리면 SSH도 안 붙고, 웹도 안 열리고, 괜히 이미지 탓하게 됩니다.

    1. 이미지 등록

    openstack image create "app-server-01" \
  --file app-server-01.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --private

    OpenStack의 Glance는 이미지 저장소 역할을 합니다. 템플릿 개념과 비슷하지만, API 중심 운영에 더 잘 녹아 있습니다.

    2. 네트워크와 서브넷 준비

    openstack network create prod-net
openstack subnet create prod-subnet \
  --network prod-net \
  --subnet-range 192.168.100.0/24 \
  --dns-nameserver 8.8.8.8

    물론 실무에서는 외부 DNS를 그대로 넣기보다 내부 DNS 체계를 맞추는 경우가 많습니다. 여기서는 예시만 단순하게 보여드리는 거예요.

    3. 보안그룹 생성

    openstack security group create web-sec
openstack security group rule create --protocol tcp --dst-port 22 web-sec
openstack security group rule create --protocol tcp --dst-port 80 web-sec
openstack security group rule create --protocol tcp --dst-port 443 web-sec

    여기서 중요한 포인트! VMware 쪽에서는 포트 그룹과 상위 방화벽 정책으로 어느 정도 익숙하게 처리되던 것이, OpenStack에서는 인스턴스 단위 정책으로 체감될 때가 있습니다. 처음엔 이게 뭔가 싶었는데, 익숙해지면 오히려 훨씬 명확합니다.

    4. 인스턴스 기동

    openstack server create app-server-01 \
  --flavor m1.medium \
  --image app-server-01 \
  --network prod-net \
  --security-group web-sec

    이후 Floating IP(Floating IP, 외부 접근용 유동 IP)가 필요한 구조라면 외부 네트워크에 붙여줘야 합니다.

    openstack floating ip create public-net
openstack server add floating ip app-server-01 203.0.113.10

    ⚠️ 실제로 많이 막히는 문제들: ESXi OpenStack 전환 트러블슈팅

    여기가 제일 중요합니다. 성공 사례는 대부분 결과만 보여주는데, 실무에서는 이 구간이 진짜 본게임입니다.

    1. 부팅은 되는데 네트워크가 안 붙는 경우

    원인은 보통 세 가지였습니다.

    • 게스트 OS 안에 VMware 네트워크 인터페이스 설정이 남아 있는 경우
    • udev 규칙 때문에 NIC 이름이 바뀌는 경우
    • OpenStack 보안그룹에서 필요한 포트가 안 열린 경우

    리눅스는 부팅 후 인터페이스 이름을 먼저 확인했습니다.

    ip addr
ip route
journalctl -b | grep -i network

    특히 CentOS나 Ubuntu 구버전 계열은 예전 NIC 정보 때문에 인터페이스가 달라지는 일이 종종 있었습니다. 저는 이 문제를 몇 번 겪고 나서는 이미지 올리기 전에 네트워크 설정 파일을 먼저 정리하는 습관이 생겼습니다.

    2. 디스크는 붙었는데 부팅이 불안정한 경우

    이건 VirtIO(Virtual I/O, 가상 장치 고속 드라이버) 드라이버나 부팅 로더 문제일 때가 많았습니다. 윈도우 게스트는 VirtIO 드라이버 준비 여부를 꼭 점검하셔야 하고, 리눅스는 initramfs 안에 필요한 드라이버가 포함됐는지 보는 게 좋습니다.

    3. 시간이 틀어지거나 애플리케이션이 이상 동작하는 경우

    NTP(Network Time Protocol, 시간 동기화)와 DNS는 가볍게 보면 안 됩니다. OpenStack 쪽 인스턴스가 올라오고 서비스는 떠 있는데, 인증이나 토큰 검증이 계속 실패하면 시간 동기화부터 보셔야 합니다. 이거 진짜 자주 놓칩니다.

    4. 스냅샷 의존 운영 습관

    VMware에서 스냅샷을 임시 안전장치처럼 쓰던 습관이 있으면 OpenStack으로 넘어와서 운영 방식 자체를 다시 잡아야 합니다. 인스턴스 스냅샷, 볼륨 스냅샷, 이미지 버전 관리, 백업 정책을 분리해서 생각해야 하거든요. 저도 처음엔 “스냅샷 느낌이 왜 다르지?” 싶었는데, 클라우드식 운영으로 사고방식을 바꾸니까 정리가 되더라고요.

    ESXi OpenStack 전환 시 OpenStack 네트워크와 보안그룹 구성 다이어그램

    테넌트 네트워크, 라우터, 보안그룹, 플로팅 IP 관계와 함께 통신 장애 포인트를 표시하는 설명 이미지입니다.

    검증 방법: 클라우드 마이그레이션 사례에서 놓치면 안 되는 체크

    전환이 끝났다고 바로 운영으로 넘기면 안 됩니다. 저는 아래 순서로 검증했습니다.

    1. 인스턴스 상태 확인: ACTIVE 상태인지, 콘솔 로그에 에러가 없는지 봅니다.
    2. 네트워크 점검: 내부 통신, 외부 통신, DNS 해석을 확인합니다.
    3. 애플리케이션 점검: 웹, API, 배치 작업, 데이터 연결을 확인합니다.
    4. 성능 비교: 최소한 부팅 시간, 응답성, 디스크 지연 체감은 체크합니다.
    5. 운영 도구 점검: 백업, 모니터링, 로그 수집이 붙는지 확인합니다.
    openstack server list
openstack console log show app-server-01
ping -c 4 192.168.100.10
curl -I http://192.168.100.10

    여기서 제가 제일 강조하고 싶은 건, VM이 떠 있는 것과 서비스가 정상인 것은 다르다는 점입니다. 실제로는 애플리케이션 레벨 체크가 마지막 문턱이었습니다.

    클라우드 마이그레이션 사례 검증을 위한 OpenStack 인스턴스 상태 대시보드

    마이그레이션 이후 인스턴스 상태, 네트워크 연결, 서비스 응답을 한눈에 확인하는 검증 대시보드 이미지입니다.

    전환 결과: 제가 얻은 것과 예상 밖의 변화

    결론부터 말씀드리면, 제 경우엔 VMware OpenStack 마이그레이션 자체는 성공이었습니다. 특히 개발/스테이징 계열 워크로드에서는 OpenStack의 장점이 빨리 보였습니다. API로 인스턴스를 만들고, 네트워크를 분리하고, 이미지 기반으로 재현 가능한 환경을 만드는 흐름이 아주 좋았거든요.

    반대로 예상보다 시간이 더 걸린 부분도 있었습니다.

    • 운영팀의 사고방식 전환: 가상머신 관리에서 클라우드 자원 관리로 바뀝니다.
    • 네트워크 설계: OpenStack Neutron 이해도가 없으면 초반에 막힙니다.
    • 표준 이미지 전략: 아무 VM이나 옮기는 방식은 오래 못 갑니다.

    즉, VMware 대안 OpenStack은 충분히 현실적인 선택지이지만, “기존 VM을 그냥 다른 데 올린다”는 접근으로는 만족도가 떨어질 수 있습니다. 반대로 이미지 표준화, 자동화, 셀프서비스 포털, IaC(Infrastructure as Code, 코드형 인프라)까지 연결하면 진가가 나옵니다.

    정리와 다음 단계: 이런 순서로 접근하면 덜 흔들립니다

    혹시 지금 전환을 검토 중이시라면, 제가 추천하는 순서는 이렇습니다.

    1. 가장 덜 중요한 개발 VM부터 파일럿으로 옮깁니다.
    2. 이미지 변환 절차를 문서화합니다.
    3. 네트워크와 보안그룹 템플릿을 먼저 만듭니다.
    4. 백업, 모니터링, 로그 수집을 붙인 뒤 운영계로 확장합니다.
    5. 마지막에 표준 이미지와 자동 배포 흐름까지 정리합니다.

    사실 저도 처음엔 OpenStack이 너무 많은 조각으로 보였는데, 하나씩 이해하고 나니 왜 다들 클라우드 운영체계라고 부르는지 알겠더라고요. 반대로 VMware에서 익숙했던 편의 기능이 사라진 듯 느껴지는 순간도 있었는데, 그건 “없다”기보다 “다른 방식으로 설계해야 한다”에 가까웠습니다.

    이전 글에서 다뤘던 가상화 스토리지 설계 내용과도 연결되는 부분이 있고, 다음 글에서는 OpenStack에서 표준 이미지와 cloud-init(cloud-init, 초기 부팅 자동 설정)를 묶어 운영하는 방법도 다뤄볼 예정입니다. 여기까지 정리해보니, 결국 성공 포인트는 기술 하나가 아니라 운영 모델의 재설계였습니다.

    VMware 대안 OpenStack 전환 포인트 비교 인포그래픽

    운영 모델, 네트워크, 스토리지, 자동화 관점에서 VMware와 OpenStack의 차이를 요약한 마무리 인포그래픽입니다.

    자주 묻는 질문

    Q1. ESXi에서 OpenStack으로 무중단 전환이 가능한가요?

    가능 여부는 애플리케이션 구조에 달려 있습니다. 일반적인 단일 VM 서비스는 점검 시간을 잡고 이미지 기반으로 옮기는 편이 더 현실적이었습니다.

    Q2. 모든 VMware VM이 그대로 OpenStack에서 잘 동작하나요?

    아닙니다. 네트워크 설정, 드라이버, 부팅 방식, 에이전트 의존성에 따라 손봐야 할 부분이 꽤 있습니다. 특히 오래된 VM일수록 사전 점검이 중요합니다.

    Q3. OpenStack이 무조건 비용 절감으로 이어지나요?

    단순히 플랫폼만 바꾼다고 바로 그렇진 않습니다. 운영 역량, 자동화 수준, 표준화 정도가 함께 따라와야 의미 있는 효과가 납니다.

    Q4. 가장 먼저 테스트할 워크로드는 무엇이 좋을까요?

    개발 또는 스테이징 환경의 웹 애플리케이션부터 권장합니다. 네트워크와 이미지 변환 절차를 검증하기에 적당하고, 실패했을 때 영향도 상대적으로 적습니다.

  • [Proxmox] Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    [Proxmox] Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    홈랩 서버실 | Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    안녕하세요, 13년차의 서버실입니다. 홈랩을 운영하면서 여러 하이퍼바이저(Hypervisor)를 오가다 보면, 언젠가 한 번쯤은 겪게 되는 고민이 있어요. 바로 기존 가상머신(Virtual Machine, VM)을 새로운 플랫폼으로 옮기는 마이그레이션(Migration)입니다. 특히 스마트 홈의 핵심인 Home Assistant OS(HAOS) 같은 친구들은 안정성이 중요해서 마이그레이션할 때 더욱 신중해지죠. 저도 최근에 오랫동안 잘 써오던 VMware ESXi 환경에서 Proxmox VE로 HAOS를 안전하게 이전하면서 꽤 삽질을 했거든요. 오늘은 그 경험을 바탕으로 여러분께 자세히 알려드리려고 합니다.

    혹시 여러분도 ESXi의 라이선스 정책 변화나, Proxmox VE의 유연한 기능들, 혹은 단순히 새로운 환경에 대한 호기심 때문에 마이그레이션을 고민하고 계신가요? 그렇다면 이 글이 큰 도움이 될 겁니다. 제가 직접 겪었던 시행착오와 해결 과정을 솔직하게 공유하면서, 여러분의 Proxmox HAOS 마이그레이션 여정을 조금 더 부드럽게 만들어 드릴게요. 자, 그럼 시작해 볼까요?

    VMware ESXi에서 Proxmox VE로 Home Assistant OS 마이그레이션 전체 개요

    VMware ESXi에서 Proxmox VE로 Home Assistant OS 마이그레이션 전체 개요 다이어그램입니다.

    1. 왜 VMware ESXi에서 Proxmox VE로 옮겨야 할까요?

    사실 VMware ESXi는 오랫동안 안정적인 가상화 플랫폼의 대명사였어요. 특히 엔터프라이즈 환경에서는 거의 표준이라고 할 수 있었죠. 저도 덕분에 많은 프로젝트를 ESXi 위에서 진행했었고요. 하지만 홈랩(Home Lab) 환경에서는 몇 가지 고민이 생기더라고요.

    • 라이선스 정책 변화: ESXi 무료 버전의 기능 제한이 점점 심해지고 있습니다. 특히 vSphere API 접근 제한은 백업이나 관리 자동화에 큰 걸림돌이 되죠.
    • 오픈소스의 유연성: Proxmox VE(Virtual Environment)는 완벽한 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers)를 모두 지원해서 VM과 컨테이너를 한 곳에서 관리할 수 있다는 점이 정말 매력적이더라고요.
    • 커뮤니티와 학습: Proxmox는 활발한 커뮤니티와 방대한 자료 덕분에 새로운 기술을 익히고 실험하기에 좋은 환경을 제공합니다. 저처럼 이것저것 만져보는 걸 좋아하는 사람에게는 최고의 놀이터죠.

    이런 이유들로 저는 Proxmox VE로의 전환을 결심했고, 그 첫 타자로 홈랩의 심장인 Home Assistant OS를 옮겨보기로 했습니다.

    2. 개념 설명: Proxmox VE와 Home Assistant OS 간략히

    마이그레이션에 앞서, 핵심 개념들을 간단히 짚고 넘어갈까요?

    • Proxmox VE (Virtual Environment): 쉽게 말해, 서버 한 대에서 여러 개의 가상 서버를 돌릴 수 있게 해주는 운영체제라고 생각하시면 됩니다. VMware ESXi와 비슷한 역할을 하지만, 오픈소스라는 점이 가장 큰 차이점이에요. 웹 기반 인터페이스를 제공해서 관리도 편리하고요.
    • Home Assistant OS (HAOS): 스마트 홈 기기들을 한곳에 모아 관리하고 자동화할 수 있게 해주는 오픈소스 플랫폼입니다. 전용 OS 형태로 제공되어 가상머신 위에 설치하는 경우가 많죠. 저도 Z-Wave, Zigbee 동글(dongle)을 연결해서 사용하고 있습니다.
    • 마이그레이션 (Migration): 기존에 잘 돌아가던 가상머신을 다른 가상화 환경으로 옮기는 과정입니다. 단순히 파일을 복사하는 것 이상으로, 새로운 환경에 맞게 설정들을 조정해줘야 하죠.

    3. 실전 구현: VMware ESXi에서 HAOS VM 내보내기

    자, 이제 본론입니다. 제가 직접 해보니 몇 가지 포인트만 잘 지키면 생각보다 어렵지 않더라고요.

    3.1. Home Assistant OS VM 백업 및 종료

    가장 먼저 할 일은 HAOS VM을 백업하는 것입니다. 혹시 모를 상황에 대비해서 꼭 스냅샷(Snapshot)을 찍어두거나, Home Assistant 자체의 백업 기능을 활용해서 전체 백업 파일을 받아두세요. 그리고 VM을 정상적으로 종료(Shut Down)해야 합니다. 전원 끄기(Power Off) 말고, 반드시 OS 내부에서 종료 명령을 내려주세요. 데이터 무결성(Data Integrity)을 위해 아주 중요하거든요.

    3.2. OVF/OVA 형식으로 내보내기

    VMware ESXi에서 가상머신을 다른 환경으로 옮길 때 가장 일반적인 방법은 OVF(Open Virtualization Format) 또는 OVA(Open Virtual Appliance) 형식으로 내보내는 것입니다. OVA는 OVF 파일과 관련 디스크 이미지를 하나의 파일로 묶어둔 아카이브(Archive) 형태라고 보시면 돼요. 저는 OVA로 내보냈습니다.

    1. vSphere Client 또는 ESXi 웹 UI에 접속합니다.
    2. 내보낼 Home Assistant OS VM을 선택하고 마우스 오른쪽 버튼을 클릭합니다.
    3. ‘템플릿(Template)’ > ‘OVF 템플릿 내보내기(Export OVF Template…)’를 선택합니다.
    4. 저장할 위치와 파일명을 지정하고 ‘확인’을 누르면 내보내기가 시작됩니다. 시간이 좀 걸릴 수 있어요.
    VMware ESXi에서 Home Assistant OS 가상 머신을 OVF/OVA 형식으로 내보내는 과정

    VMware ESXi 웹 UI에서 Home Assistant OS 가상 머신을 OVF/OVA 형식으로 내보내는 화면입니다.

    3.3. 디스크 이미지 변환 (VMDK → QCOW2)

    Proxmox VE는 일반적으로 QCOW2나 RAW 형식의 디스크 이미지를 사용합니다. ESXi에서 내보낸 OVA 파일 안에는 VMDK 형식의 디스크 이미지가 들어있죠. 이걸 Proxmox에서 사용할 수 있는 형식으로 변환해야 합니다. 저는 Proxmox 서버에서 직접 변환하는 방법을 선택했어요. 이게 가장 빠르고 편하더라고요.

    1. 내보낸 OVA 파일을 Proxmox VE 서버의 특정 디렉토리(예: /var/lib/vz/template/iso/)로 옮깁니다. scp 명령어를 사용하면 편리합니다.
    2. Proxmox VE 서버에 SSH로 접속합니다.
    3. OVA 파일 압축을 해제합니다. OVA는 사실 .tar 아카이브 파일이에요.
    cd /var/lib/vz/template/iso/
tar -xvf homeassistant.ova

    압축을 풀면 .ovf 파일과 .vmdk 파일이 보일 겁니다.

    1. qemu-img 도구를 사용하여 VMDK 파일을 QCOW2로 변환합니다.
    qemu-img convert -f vmdk homeassistant-disk1.vmdk -O qcow2 homeassistant-disk1.qcow2

    이 명령어가 성공적으로 실행되면, homeassistant-disk1.qcow2 파일이 생성됩니다. 이 파일이 Proxmox VE에서 사용할 디스크 이미지예요.

    4. 실전 구현: Proxmox VE로 HAOS VM 가져오기

    이제 변환된 디스크 이미지를 Proxmox VE에 VM으로 등록할 차례입니다.

    4.1. 새 가상머신 생성 (디스크 없이)

    Proxmox VE 웹 UI에서 새로운 VM을 생성합니다. 이때 ‘하드 디스크(Hard Disk)’ 단계에서는 디스크를 추가하지 않고 넘어가는 것이 중요해요. 나중에 변환한 디스크를 직접 연결할 거거든요.

    1. Proxmox VE 웹 UI에 접속합니다.
    2. 우측 상단 ‘VM 생성(Create VM)’ 버튼을 클릭합니다.
    3. ‘일반(General)’ 탭에서 이름과 VM ID를 지정합니다. (예: homeassistant-new, ID 100)
    4. ‘OS’ 탭에서 ‘미디어 사용 안 함(Do not use any media)’을 선택합니다.
    5. ‘시스템(System)’ 탭에서 기본값으로 두거나 필요한 경우 수정합니다. (저는 VMWare에서 사용하던 BIOS 대신 UEFI를 선택했어요.)
    6. ‘디스크(Disks)’ 탭에서 ‘디스크를 추가하지 않음(Do not add a disk)’을 선택하고 다음으로 넘어갑니다.
    7. ‘CPU’ 및 ‘메모리(Memory)’를 적절히 설정합니다. HAOS는 2코어, 4GB RAM 정도면 충분해요.
    8. ‘네트워크(Network)’ 탭에서 원하는 브리지(Bridge)를 선택합니다. (일반적으로 vmbr0)
    9. 마지막 ‘확인(Confirm)’ 단계에서 설정을 다시 확인하고 ‘완료(Finish)’를 클릭합니다.

    4.2. 변환된 디스크 이미지 임포트

    생성된 VM에 아까 변환했던 .qcow2 디스크 이미지를 연결합니다.

    1. Proxmox VE 서버에 SSH로 접속합니다.
    2. 다음 명령어를 사용하여 디스크 이미지를 생성한 VM (예: ID 100)으로 임포트합니다. local-lvm은 디스크 이미지를 저장할 스토리지 풀 이름입니다. 여러분의 환경에 맞게 변경해주세요.
    qm importdisk 100 /var/lib/vz/template/iso/homeassistant-disk1.qcow2 local-lvm

    이 명령어가 완료되면, Proxmox VE 웹 UI의 VM 하드웨어 설정에 ‘사용하지 않는 디스크(Unused Disk)’로 추가된 것을 볼 수 있어요.

    4.3. 임포트된 디스크 연결 및 부팅 순서 설정

    1. Proxmox VE 웹 UI에서 생성한 VM (ID 100)을 선택하고 ‘하드웨어(Hardware)’ 탭으로 이동합니다.
    2. ‘사용하지 않는 디스크(Unused Disk)’를 더블클릭하거나 선택 후 ‘편집(Edit)’ 버튼을 눌러 디스크를 VM에 연결합니다. ‘버스/장치(Bus/Device)’는 ‘SATA’나 ‘VirtIO Block’ 중 선택하는데, 저는 일반적으로 성능이 좋은 VirtIO Block을 선호해요. ‘캐시(Cache)’ 설정도 필요에 따라 조정해주세요.
    3. ‘옵션(Options)’ 탭으로 이동하여 ‘부팅 순서(Boot Order)’를 편집합니다. 방금 연결한 디스크를 첫 번째 부팅 장치로 설정하고 ‘확인(OK)’을 클릭합니다.
    Proxmox VE에서 새로운 가상 머신 생성 후 Home Assistant OS 디스크 이미지를 임포트하는 과정

    Proxmox VE 웹 UI에서 새로운 VM을 생성하고, SSH 터미널에서 qm importdisk 명령어를 통해 Home Assistant OS 디스크 이미지를 임포트하는 과정입니다.

    5. 주의사항 및 트러블슈팅 ⚠️ (삽질 경험 공유)

    제가 이 과정에서 겪었던 몇 가지 ‘삽질’과 그 해결 방법을 공유합니다. 여러분은 저 같은 실수를 하지 않으시길 바랍니다! ㅎㅎ

    • 네트워크 인터페이스 문제: 마이그레이션 후 HAOS가 네트워크를 잡지 못하는 경우가 있어요. ESXi와 Proxmox는 가상 네트워크 카드 드라이버가 다를 수 있거든요. HAOS는 보통 eth0을 사용하지만, Proxmox에서 VirtIO 네트워크 카드를 사용하면 이름이 바뀌거나 설정이 꼬일 수 있습니다.

      • 해결책: Proxmox VM 설정에서 네트워크 카드를 VirtIO 대신 E1000으로 변경해보세요. 또는 HAOS 콘솔에 접속해서 네트워크 설정을 수동으로 확인하고 network update 명령어를 통해 DHCP를 다시 시도해볼 수 있습니다.

    • VMware Tools 잔재: ESXi에서 설치했던 VMware Tools는 Proxmox에서는 필요 없어요. 이게 남아있으면 불필요한 리소스를 잡아먹거나 충돌을 일으킬 수도 있습니다. 사실 HAOS는 자체적으로 VM Tools 같은 걸 설치하지 않아서 크게 문제가 되지는 않지만, 다른 Linux VM을 마이그레이션할 때는 꼭 확인해주세요.

      • 해결책: 마이그레이션 전 ESXi에서 VM Tools를 제거하거나, Proxmox로 옮긴 후 해당 VM에 접속해서 제거하는 것이 좋습니다.

    • USB 패스스루(USB Passthrough): Zigbee나 Z-Wave 동글을 사용하신다면, Proxmox에서 USB 패스스루 설정을 새로 해줘야 합니다. ESXi에서 사용하던 설정이 그대로 넘어오지 않거든요.

      • 해결책: Proxmox 웹 UI에서 VM 하드웨어 설정에 들어가 ‘추가(Add)’ > ‘USB 장치(USB Device)’를 선택하고, ‘벤더/제품 ID 사용(Use vendor/product ID)’ 또는 ‘USB 포트 사용(Use USB Port)’을 통해 해당 동글을 연결해줍니다.

    • 디스크 용량 문제: HAOS VMDK 파일이 크면 변환 및 임포트 과정에서 시간이 오래 걸리고, 스토리지 용량을 충분히 확보해야 합니다. 저도 한 번은 Proxmox 서버의 /tmp 디렉토리 용량이 부족해서 변환이 실패한 적이 있었어요. 😅

      • 해결책: 변환 파일을 저장할 디렉토리에 충분한 여유 공간이 있는지 미리 확인하세요.

    6. 검증 및 결과 🎉 (드디어 새로운 둥지에서 HAOS 가 움직인다!)

    모든 설정이 끝나고 VM을 부팅하면, 이제 HAOS가 Proxmox VE 위에서 새로운 시작을 알릴 겁니다. 저는 부팅 후 다음 사항들을 꼼꼼히 확인했어요.

    1. HAOS 웹 인터페이스 접속: 가장 먼저 HAOS의 웹 UI에 접속해서 대시보드가 정상적으로 로드되는지 확인합니다.
    2. 네트워크 연결 상태: ‘설정(Settings)’ > ‘시스템(System)’ > ‘네트워크(Network)’에서 IP 주소와 게이트웨이(Gateway) 설정이 올바른지 확인합니다.
    3. 통합(Integrations) 작동 여부: 스마트 기기 연동(예: Philips Hue, SmartThings, Zigbee/Z-Wave 동글)이 제대로 작동하는지 하나씩 테스트해봅니다.
    4. 애드온(Add-ons) 상태: 설치했던 애드온들이 모두 정상적으로 실행되는지 확인해요.
    5. 리소스 사용량: Proxmox VE 웹 UI에서 VM의 CPU, 메모리, 디스크 I/O 사용량을 모니터링하여 ESXi 때와 비교해봅니다. 보통 Proxmox가 더 효율적인 경우가 많더라고요.

    이 모든 과정이 끝나고 HAOS 대시보드가 완벽하게 작동하는 것을 보니, 그동안의 삽질이 싹 잊히는 기분이었어요. 드디어 성공했구나! 하는 성취감이 밀려오더라고요. 🥳

    Proxmox VE에서 성공적으로 마이그레이션되어 작동 중인 Home Assistant OS 대시보드

    Proxmox VE 위에서 성공적으로 마이그레이션되어 작동 중인 Home Assistant OS 대시보드 화면입니다.

    7. 마무리: 배운 점과 다음 단계

    VMware ESXi에서 Proxmox VE로 Home Assistant OS를 마이그레이션하는 과정은 단순히 파일을 옮기는 것을 넘어, 새로운 가상화 환경에 대한 이해와 트러블슈팅 능력을 길러주는 좋은 경험이었습니다. 제가 얻은 몇 가지 교훈은 이렇습니다.

    • 사전 백업의 중요성: 아무리 강조해도 지나치지 않아요.
    • 문서화의 습관화: 제가 어떤 설정을 했는지, 어떤 삽질을 했는지 기록해두면 다음번에 훨씬 수월합니다.
    • 오픈소스 커뮤니티의 힘: 막히는 부분이 있을 때 Proxmox 포럼이나 Home Assistant 커뮤니티에서 많은 도움을 받을 수 있었어요.

    이제 여러분의 Home Assistant OS는 Proxmox VE라는 새로운 환경에서 더욱 안정적이고 유연하게 동작할 겁니다. 다음 단계로는 Proxmox VE의 강력한 백업 기능(Proxmox Backup Server와 연동)을 활용하여 HAOS 백업 전략을 수립하거나, VM에 GPU 패스스루를 설정하여 미디어 서버 등 다른 서비스를 구축하는 것도 좋은 아이디어가 될 수 있겠죠. 물론 이 부분은 다음 글에서 자세히 다룰 예정입니다. 😉

    오늘도 제 글이 여러분의 홈랩 운영에 작은 도움이 되었기를 바라며, 궁금한 점은 언제든 댓글로 남겨주세요! 13년차의 서버실은 언제나 여러분의 삽질을 응원합니다. 감사합니다!

  • [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    목차

    TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어들이 한 번쯤 고민해봤을 주제, VMware ESXi 가상머신(Virtual Machine, VM)을 TrueNAS iSCSI 스토리지로 마이그레이션(Migration, 이전)하는 성공 사례를 들려드리려고 합니다. 저도 홈랩을 운영하면서 스토리지 확장의 필요성을 절감했고, 이 과정에서 꽤나 삽질을 했거든요. 하지만 결국 성공했고, 그 경험을 여러분과 나누고 싶습니다. 💡

    기존에 사용하던 로컬 스토리지의 용량이 부족해지거나, 더 나은 성능과 유연성을 위해 중앙 집중식 스토리지로 옮겨야 할 때가 있죠. 특히 ESXi 스토리지 이전은 단순히 데이터 복사 이상의 복잡한 과정이 필요합니다. 이때 TrueNAS iSCSI는 비용 효율적이면서도 강력한 대안이 될 수 있습니다. iSCSI VM 마이그레이션을 고민 중이라면, 오늘 이야기가 큰 도움이 될 겁니다.

    ESXi와 TrueNAS iSCSI 스토리지를 활용한 가상머신 마이그레이션 전체 구성도입니다.

    1. 핵심 개념 이해: ESXi, TrueNAS, 그리고 iSCSI

    본격적인 마이그레이션에 앞서, 핵심 기술들이 무엇인지 간단히 짚고 넘어갈게요. “아, 이건 또 뭐야?” 싶으실 수도 있지만, 기본을 알아야 삽질을 줄일 수 있거든요. 😉

    • VMware ESXi (이엑스아이): VMware에서 개발한 베어메탈(Bare-metal) 하이퍼바이저(Hypervisor)입니다. 쉽게 말해, 물리 서버 위에 직접 설치되어 여러 가상머신을 효율적으로 운영할 수 있게 해주는 소프트웨어죠. 저희 서버실의 모든 가상머신은 ESXi 위에서 돌아가고 있습니다.
    • TrueNAS (트루나스): 오픈소스 네트워크 스토리지(Network Attached Storage, NAS) 운영체제입니다. 강력한 ZFS 파일 시스템을 기반으로 데이터 무결성과 유연성을 제공하며, 파일 공유는 물론 iSCSI와 같은 블록 스토리지 서비스도 지원합니다. 저의 홈랩에서는 TrueNAS Core 버전을 사용하고 있습니다.
    • iSCSI (아이 스카시, Internet Small Computer System Interface): IP 네트워크를 통해 SCSI(Small Computer System Interface) 명령을 전송하는 기술 표준입니다. 원격 서버에 마치 로컬 디스크처럼 블록 스토리지(Block Storage)를 연결할 수 있게 해줍니다. NAS iSCSI 설정은 ESXi가 TrueNAS의 스토리지를 마치 물리 디스크처럼 인식하게 만드는 핵심 단계라고 할 수 있죠.

    2. TrueNAS iSCSI 타겟 설정: 스토리지 준비하기

    이제 TrueNAS에서 ESXi가 사용할 iSCSI 스토리지를 만들어볼 차례입니다. “어렵지 않을까?” 걱정 마세요. 제가 직접 해보니 몇 가지 단계만 잘 따라가면 됩니다.

    단계별 TrueNAS iSCSI 설정

    1. ZFS 데이터셋(Dataset) 생성: 먼저 iSCSI 타겟으로 사용할 ZFS 데이터셋을 만듭니다. 저는 pool01/iscsi-vm이라는 데이터셋을 만들었어요.
    2. iSCSI 서비스 활성화: TrueNAS 웹 GUI에서 Services -> iSCSI로 이동하여 서비스를 활성화하고, Start Automatically를 체크해줍니다.
    3. 포털(Portal) 생성: iSCSI 통신에 사용할 IP 주소와 포트를 지정합니다. Sharing -> Block Shares (iSCSI) -> Portals 탭에서 Add를 클릭하고 TrueNAS의 IP 주소를 입력합니다.
    4. 이니시에이터(Initiator) 및 인증 설정 (선택 사항): 보안을 위해 특정 ESXi 호스트만 접근하도록 제한하거나, CHAP(Challenge-Handshake Authentication Protocol) 인증을 설정할 수 있습니다. 저는 홈랩이라 간단히 모든 이니시에이터(ALL Initiators)를 허용했지만, 프로덕션 환경에서는 반드시 제한해야 합니다.
    5. 익스텐트(Extent, LUN) 생성: 실제 스토리지 공간을 정의합니다. Extents 탭에서 Add를 클릭하고, 이전에 생성한 ZFS 데이터셋을 경로로 지정합니다. 이 익스텐트가 ESXi에 LUN(Logical Unit Number)으로 보이게 됩니다.
    6. 타겟(Target) 생성 및 연결: 마지막으로 익스텐트와 포털을 연결하여 타겟을 만듭니다. Targets 탭에서 Add를 클릭하고, 이름을 지정한 후 생성한 포털과 익스텐트를 연결합니다.

    이렇게 하면 TrueNAS에서 iSCSI 타겟 설정이 완료됩니다. 생각보다 간단하죠? ✅

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 화면

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 모습입니다.

    3. ESXi iSCSI 이니시에이터 설정: 서버 연결하기

    이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 인식하도록 설정해야 합니다. vSphere Client를 이용하면 GUI 환경에서 쉽게 설정할 수 있습니다.

    단계별 ESXi 설정

    1. iSCSI 소프트웨어 어댑터 활성화: vSphere Client에서 ESXi 호스트를 선택하고 Configure -> Storage Adapters로 이동합니다. Add Software Adapter를 클릭하여 Software iSCSI 어댑터를 추가합니다.
    2. 동적 검색(Dynamic Discovery) 설정: 새로 추가된 iSCSI 어댑터를 선택하고 Adapters 탭에서 Dynamic Discovery를 클릭, Add를 눌러 TrueNAS의 iSCSI 포털 IP 주소를 입력합니다.
    3. 네트워크 리스캔(Rescan): Storage Adapters 뷰로 돌아와 Rescan Adapters를 클릭합니다. 잠시 후 TrueNAS의 iSCSI LUN이 새로운 디바이스로 나타나는 걸 확인할 수 있어요.
    4. 새로운 데이터스토어(Datastore) 생성: Storage -> Datastores 탭으로 이동하여 New Datastore를 클릭합니다. VMFS 타입을 선택하고, 방금 검색된 TrueNAS iSCSI LUN을 선택하여 데이터스토어를 생성합니다. 원하는 이름을 지정하고 VMFS 버전을 선택하면 됩니다.

    자, 이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 사용할 준비가 끝났습니다. “진짜 되는 거야?” 싶으시겠지만, 여기까지 잘 오셨다면 거의 다 된 겁니다! 🎉

    4. 가상머신 마이그레이션: iSCSI 스토리지 이전의 핵심

    가장 중요한 단계, 가상머신 마이그레이션입니다. ESXi 환경에서는 Storage vMotion(스토리지 v모션)이라는 멋진 기능 덕분에 가상머신을 끄지 않고도 스토리지를 이전할 수 있습니다. 하지만 vCenter Server가 없는 홈랩 환경에서는 콜드 마이그레이션(Cold Migration, VM 종료 후 이전)을 해야 할 수도 있어요.

    Storage vMotion을 이용한 마이그레이션 (vCenter Server 환경)

    1. vSphere Client에서 마이그레이션할 가상머신을 선택합니다.
    2. 가상머신을 오른쪽 클릭하고 Migrate를 선택합니다.
    3. Change storage only 옵션을 선택한 후 Next를 클릭합니다.
    4. 대상 데이터스토어로 TrueNAS iSCSI를 통해 생성한 새 데이터스토어를 선택합니다.
    5. 설정을 확인하고 Finish를 클릭하면 마이그레이션이 시작됩니다.

    콜드 마이그레이션을 이용한 마이그레이션 (vCenter Server 없는 환경)

    1. 마이그레이션할 가상머신을 종료(Power Off)합니다.
    2. vSphere Client에서 가상머신을 선택하고 Migrate를 선택합니다.
    3. Change storage only 또는 Change compute resource and storage 옵션을 선택합니다. (호스트도 변경할 경우)
    4. 대상 데이터스토어로 TrueNAS iSCSI 데이터스토어를 선택하고 마이그레이션을 진행합니다.

    마이그레이션 진행 상황은 vSphere Client의 Recent Tasks에서 확인할 수 있습니다. 저도 처음엔 “이게 진짜 되는 건가?” 반신반의했는데, 진행률이 올라가는 걸 보니 너무 뿌듯하더라고요. 😊

    VMware vSphere Client에서 가상머신 스토리지 마이그레이션이 진행되는 화면입니다.

    5. iSCSI 마이그레이션 중 겪었던 문제들과 해결법 ⚠️

    “13년차 엔지니어도 삽질을 하나요?” 네, 물론이죠! 저도 이 과정에서 몇 번의 난관에 부딪혔고, 덕분에 많은 것을 배웠습니다. 😅

    • 네트워크 설정 문제: 처음에는 마이그레이션 속도가 너무 느려서 답답했어요. 알고 보니 ESXi의 iSCSI 전용 VMkernel 어댑터에 점보 프레임(Jumbo Frames)을 설정하지 않았더라고요. MTU(Maximum Transmission Unit) 값을 9000으로 올리니 속도가 훨씬 빨라졌습니다. TrueNAS와 ESXi 양쪽 모두 설정해야 한다는 점을 잊지 마세요! 💡

      \n# ESXi CLI에서 MTU 설정 예시 (vmnic0이 iSCSI용 NIC일 경우)\nesxcli network ip interface set -i vmkX -m 9000\n
    • iSCSI 타겟/이니시에이터 불일치: TrueNAS에서 설정한 iSCSI ACL(Access Control List)이나 CHAP 인증 정보가 ESXi와 일치하지 않아 연결이 안 되는 경우가 있었습니다. “왜 안 되는 거야!” 하며 몇 시간을 헤맸는데, 결국 사소한 오타 때문이었죠. 설정값을 꼼꼼히 확인하는 것이 정말 중요합니다.
    • TrueNAS 방화벽: 간혹 TrueNAS의 내장 방화벽이 iSCSI 트래픽을 막는 경우가 있어요. iSCSI 기본 포트(3260)가 열려 있는지 확인하거나, ESXi 호스트의 IP를 허용 목록에 추가해야 합니다.

    이런 문제들을 해결하면서 “아, 이래서 경험이 중요하구나” 싶더라고요. 멘토처럼 알려드리는 제 글이 여러분의 삽질을 조금이나마 줄여주기를 바랍니다.

    6. iSCSI 마이그레이션 검증: 드디어 성공했습니다! 🎉

    모든 설정과 마이그레이션이 끝나고, 이제 결과를 확인할 차례입니다. “잘 작동하는지”를 보는 건 엔지니어의 가장 큰 기쁨이죠.

    1. vSphere Client에서 확인: 마이그레이션된 가상머신의 Summary 탭을 확인하면 스토리지가 새로운 TrueNAS iSCSI 데이터스토어로 변경된 것을 볼 수 있어요. 가상머신을 구동해보세요!
    2. TrueNAS 대시보드 확인: TrueNAS 웹 GUI의 Reporting 또는 Dashboard에서 iSCSI 서비스의 활성화 여부, 연결된 이니시에이터 수, 그리고 스토리지 I/O(Input/Output) 성능 그래프를 통해 실제 데이터 통신이 이루어지고 있는지 확인할 수 있습니다.
    3. 성능 모니터링: 가상머신 내부에서 디스크 I/O 벤치마크 툴(예: CrystalDiskMark, fio)을 사용하여 성능이 예상대로 나오는지 확인해보는 것도 좋습니다.

    제가 직접 확인해보니, 기존 로컬 스토리지 대비 디스크 I/O 성능이 크게 개선된 것을 체감할 수 있었습니다. 특히 여러 가상머신이 동시에 디스크를 사용하는 환경에서 더욱 빛을 발하더라고요. iSCSI VM 마이그레이션은 정말 성공적인 선택이었습니다!

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 대시보드

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 모습입니다.

    7. 마무리: ESXi iSCSI 마이그레이션 과정에서 얻은 교훈

    VMware ESXi 가상머신을 TrueNAS iSCSI 스토리지로 마이그레이션하는 과정은 쉽지 않았지만, 그만큼 얻은 것도 많습니다. 유연한 스토리지 확장, 향상된 성능, 그리고 무엇보다 “내가 해냈다!”는 성취감이 가장 큰 소득이었죠.

    이 경험을 통해 저는 다음과 같은 교훈을 얻었습니다.

    • 사전 계획의 중요성: 네트워크 구성, IP 주소 할당, 인증 방식 등 모든 설정을 미리 계획하는 것이 삽질을 줄이는 지름길입니다.
    • 문서화의 생활화: 삽질 과정을 기록하고 해결책을 문서화하면 다음번에 비슷한 문제가 발생했을 때 시간을 크게 절약할 수 있습니다. (사실 저도 이 글을 쓰면서 다시 한번 정리하는 거거든요 ㅎㅎ)
    • 오픈소스의 힘: TrueNAS 같은 오픈소스 솔루션은 상용 제품 못지않은 강력한 기능을 제공하며, 홈랩 환경에서 다양한 실험을 가능하게 합니다.

    혹시 여러분도 가상머신 스토리지 마이그레이션을 고민하고 계셨다면, TrueNAS iSCSI를 한 번 고려해보세요. 물론 처음엔 헷갈릴 수 있지만, 제 경험담이 여러분의 길을 밝혀주는 작은 등불이 되기를 바랍니다. 다음번에는 ESXi와 TrueNAS를 활용한 고가용성(High Availability) 구성에 대해서도 다뤄볼 예정이니 기대해주세요! 👍