13년차의 서버실

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

[태그:] 가상머신 마이그레이션

  • [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    안녕하세요, 13년차의 서버실입니다. 제가 13년 동안 서버실을 지키면서 참 많은 가상화 솔루션을 만나보고 또 직접 구축하고 운영해봤는데요. 그중에서도 VMware ESXi는 오랫동안 업계 표준처럼 여겨져 왔죠. 저도 수많은 프로젝트에서 VMware를 사용해왔습니다. 근데 최근 들어 이런저런 이유로 VMware ESXi를 대체할 솔루션을 고민하시는 분들이 부쩍 늘었더라고요. 특히 홈랩을 운영하는 분들이나 중소기업 환경에서는 비용 부담 때문에 오픈소스 솔루션으로 눈을 돌리는 경우가 많더라고요.

    저도 최근에 홈랩의 일부 워크로드를 VMware ESXi에서 Proxmox VE로 마이그레이션(Migration)하는 삽질을 좀 했습니다. 처음엔 이거 뭐 그냥 옮기면 되는 거 아니야? 싶었는데, 막상 해보니 생각보다 고려해야 할 점들이 많더군요. 특히 기존 VMware 가상머신(Virtual Machine, VM)을 Proxmox 환경으로 가져올 때 포맷 변환부터 드라이버 문제까지, 하나하나 짚어가면서 해결해야 할 숙제들이 있었습니다. 오늘은 제가 직접 겪었던 경험을 바탕으로 VMware 마이그레이션을 Proxmox로 전환할 때 어떤 점들을 고려해야 하고, 어떻게 하면 성공적으로 마이그레이션할 수 있는지 그 전략들을 함께 알아보는 시간을 가지려고 합니다. 저처럼 삽질하실 분들을 위해 핵심만 콕콕 짚어드릴게요!

    VMware ESXi에서 Proxmox VE로의 가상머신 마이그레이션 전체 흐름을 보여주는 다이어그램

    VMware ESXi에서 Proxmox VE로의 가상머신 마이그레이션 전체 흐름을 보여주는 다이어그램입니다. 각 단계별로 어떤 작업이 필요한지 한눈에 파악할 수 있어요.

    Proxmox VE, 과연 VMware의 좋은 대안일까요?

    먼저, Proxmox VE (Virtual Environment)가 뭔지 간단하게 짚고 넘어갈게요. Proxmox VE는 오픈소스 기반의 완전한 가상화 관리 플랫폼이에요. 쉽게 말해, VMware ESXi처럼 서버 한 대에 여러 개의 가상머신을 돌릴 수 있게 해주는 하이퍼바이저(Hypervisor)인 셈이죠. 근데 Proxmox는 단순히 가상머신(KVM)만 지원하는 게 아니라, 컨테이너(LXC)까지 통합해서 관리할 수 있다는 점이 정말 좋더라고요. 게다가 웹 기반의 깔끔한 관리 인터페이스를 제공해서 초보자도 쉽게 접근할 수 있고요. Ceph (분산 스토리지)나 HA (High Availability, 고가용성) 클러스터링 기능까지 기본으로 제공하니, 엔터프라이즈급 기능들을 오픈소스로 무료로 사용할 수 있다는 게 정말 신선했어요.

    제가 Proxmox를 홈랩에 도입해보고 느낀 건, “이거 진짜 물건이네?” 였습니다. 특히 기존 VMware ESXi 환경에서 익숙했던 기능들이 Proxmox에도 대부분 존재하고, 오히려 더 유연하게 설정할 수 있는 부분들도 많더라고요. 물론 상용 솔루션만큼의 완벽한 기능이나 기술 지원을 기대하긴 어렵지만, 커뮤니티가 활성화되어 있어서 웬만한 문제는 검색만으로도 해결할 수 있었습니다.

    VMware에서 Proxmox로 가상머신 마이그레이션 실전 전략

    자, 그럼 이제 본격적으로 VMware ESXi에 있던 가상머신을 Proxmox VE로 옮기는 방법을 알아볼까요? 제가 직접 해보니 몇 가지 핵심 단계가 있더라고요.

    1. VMware VM 내보내기 (Exporting VMware Virtual Machines)

    가장 먼저 할 일은 VMware ESXi에 있는 가상머신을 내보내는 겁니다. 보통 OVF (Open Virtualization Format)나 OVA (Open Virtual Appliance) 파일 형식으로 내보내게 되죠. vSphere Client나 OVF Tool을 사용해서 쉽게 내보낼 수 있어요. 저는 주로 vSphere Client를 사용했는데요, 간단히 VM을 우클릭해서 ‘템플릿’ → ‘OVF 템플릿 내보내기’를 선택하면 됩니다. 이때 모든 디스크를 하나로 묶을지, 아니면 개별로 분리할지 선택할 수 있어요. 나중에 Proxmox에서 작업하기 훨씬 편하니까, 개별 파일로 내보내는 걸 추천해요.

    # OVF Tool을 사용하여 VM 내보내기 (예시)
    # OVF Tool은 VMware에서 제공하는 CLI 도구입니다.
    # 'vi://:@/' 형식으로 원본 VM을 지정합니다.
    # --targetDiskFormat: thin, thick, monolithicSparse, monolithicFlat 등
    # --noImageFiles: 디스크 이미지를 제외하고 OVF 파일만 내보낼 때 사용
    
    # 예시: vSphere ESXi 호스트에서 'MyVM'이라는 가상머신을 로컬 디렉토리로 내보내기
    # ovftool "vi://root:[email protected]/MyVM" "/path/to/save/MyVM.ovf"
    
    # 주의: OVF Tool은 설치와 사용법이 다소 복잡할 수 있어, vSphere Client GUI가 더 편리할 수 있습니다.
    

    2. 가상 디스크 포맷 변환 (Converting Virtual Disk Format)

    VMware에서 내보낸 가상 디스크 파일은 주로 VMDK (.vmdk) 포맷입니다. 그런데 Proxmox VE는 KVM 기반이라 QCOW2 (.qcow2) 포맷이 더 일반적이고 성능도 좋거든요. 그래서 이 VMDK 파일을 QCOW2로 변환해줘야 하는데요. 이때 사용하는 강력한 도구가 바로 qemu-img입니다. Proxmox 서버나 별도의 Linux 서버에서 이 작업을 할 수 있어요.

    제가 가장 많이 삽질했던 부분 중 하나가 바로 이 포맷 변환이었습니다. 변환 옵션을 잘못 주거나, 원본 파일이 손상되어 있으면 부팅이 안 되는 불상사가 발생하더라고요. 원본 VMDK 파일은 꼭 백업해두고 작업하세요!

    # Proxmox 서버나 Linux 터미널에서 실행
    # VMDK 파일을 QCOW2 포맷으로 변환
    # -f: 원본 파일 형식 (from format)
    # -O: 대상 파일 형식 (to format)
    
    qemu-img convert -f vmdk -O qcow2 /path/to/your/vmware_vm.vmdk /path/to/your/proxmox_vm.qcow2
    
    # 만약 변환 중 문제가 발생한다면, 원본 VMDK 파일의 무결성을 확인하거나
    # 다른 변환 옵션 (예: -o cluster_size=2M)을 시도해볼 수 있어요.
    # 스냅샷이 포함된 VMDK 파일은 더 복잡할 수 있습니다.
    
    VMDK 파일을 QCOW2 포맷으로 변환하는 qemu-img convert 명령어 실행 화면

    qemu-img convert 명령어를 통해 VMDK 파일을 QCOW2 포맷으로 변환하는 과정을 터미널에서 보여주는 화면입니다. 이 과정은 마이그레이션의 핵심 단계 중 하나입니다.

    3. Proxmox VE로 가져오기 및 VM 생성 (Importing to Proxmox VE and Creating VM)

    변환된 QCOW2 파일을 Proxmox VE 서버의 적절한 스토리지 경로로 옮긴 다음, 새로운 가상머신을 생성하고 이 디스크를 연결해줘야 합니다.

    1. QCOW2 파일 업로드/이동: Proxmox 서버의 `/var/lib/vz/images/` 경로 아래에 새 VM ID 폴더를 만들고 그 안에 QCOW2 파일을 복사해요. 또는 Proxmox 웹 UI의 ‘스토리지’에서 ‘콘텐츠’ 업로드 기능을 사용할 수도 있어요.
    2. 새 가상머신 생성: Proxmox 웹 UI에서 ‘VM 생성’ 버튼을 누르고, 운영체제는 ‘미디어 사용 안 함’을 선택해요. CPU, 메모리, 네트워크 등은 기존 VMware VM과 비슷하게 설정하면 됩니다.
    3. 기본 디스크 분리: 새로 생성된 VM에는 기본적으로 작은 디스크가 하나 붙어있을 겁니다. 이 디스크는 ‘하드웨어’ 탭에서 선택 후 ‘분리’하면 됩니다.
    4. 변환된 디스크 연결: ‘하드웨어’ 탭에서 ‘추가’ → ‘하드 디스크’를 선택해요. ‘저장소’는 QCOW2 파일이 있는 스토리지를 선택하고, ‘디스크 이미지’는 앞서 복사해둔 QCOW2 파일을 선택합니다. 버스/장치는 SCSI 또는 VirtIO Block을 선택하는 게 성능상 유리해요. 컨트롤러는 VirtIO SCSI Single을 추천합니다.
    5. 부팅 순서 설정: ‘옵션’ 탭에서 ‘부팅 순서’를 변경하여 새로 연결한 디스크로 부팅하도록 설정합니다.

    4. 게스트 에이전트 설치 및 네트워크 설정 (Installing Guest Agent and Network Configuration)

    여기서 또 한 번의 삽질이 기다리고 있을 수 있어요. VM이 성공적으로 부팅되었다고 끝이 아니거든요! 성능 최적화와 안정적인 관리를 위해 몇 가지 추가 작업이 필요합니다.

    • QEMU Guest Agent 설치: VMware Tools처럼, Proxmox 환경에서는 QEMU Guest Agent를 설치해야 해요. 이걸 설치해야 Proxmox 웹 UI에서 VM의 IP 주소나 게스트 OS 상태를 정확하게 확인할 수 있고, 깔끔한 종료(shutdown)나 재부팅(reboot) 명령도 정상적으로 동작합니다.
    # Debian/Ubuntu 기반 게스트 OS에서 QEMU Guest Agent 설치
    sudo apt update
    sudo apt install qemu-guest-agent
    sudo systemctl start qemu-guest-agent
    sudo systemctl enable qemu-guest-agent
    
    # CentOS/RHEL 기반 게스트 OS에서 QEMU Guest Agent 설치
    sudo yum install qemu-guest-agent
    sudo systemctl start qemu-guest-agent
    sudo systemctl enable qemu-guest-agent
    
    • 네트워크 드라이버 설정: VMware에서 사용하던 E1000이나 VMXNET3 드라이버가 Proxmox 환경에서는 제대로 작동하지 않을 수 있습니다. Proxmox에서는 VirtIO (Virtio network device) 드라이버를 사용하는 게 성능상 훨씬 유리해요. VM 설정에서 네트워크 장치를 VirtIO로 변경하고, 게스트 OS 내부에서 네트워크 설정을 다시 해줘야 할 수 있습니다.

    ⚠️ 마이그레이션 중 겪었던 주의사항 및 트러블슈팅

    저도 마이그레이션을 하면서 몇 번의 좌절을 겪었습니다. 특히 이런 문제들이 자주 발생하더라고요.

    • 부팅 문제 (Boot Issues): VMDK를 QCOW2로 변환 후 부팅이 안 되는 경우가 있어요. 대부분 디스크 컨트롤러 타입 문제인데요. Proxmox VM 생성 시 디스크 컨트롤러를 VirtIO SCSI로 설정하고, 게스트 OS에 VirtIO 드라이버가 없으면 부팅이 안 될 수 있습니다. Windows OS의 경우 VirtIO 드라이버 ISO를 연결하여 드라이버를 수동으로 설치해야 할 수도 있어요.
    • 네트워크 연결 불가: 위에서 언급했듯이, 네트워크 장치를 VirtIO로 변경하면 기존 드라이버가 없어서 네트워크가 안 잡힐 수 있습니다. 게스트 OS에 접속해서 네트워크 인터페이스 설정 파일(예: Linux의 /etc/network/interfaces나 /etc/sysconfig/network-scripts/)을 수정하거나, Windows의 경우 장치 관리자에서 드라이버를 업데이트해야 합니다.
    • 스냅샷 문제: VMware VM에 스냅샷이 많다면 마이그레이션이 복잡해질 수 있어요. 가급적 스냅샷을 모두 제거하고 베이스 디스크만 내보내는 것을 권장합니다.
    • 성능 저하: 마이그레이션 후 VM 성능이 기대 이하라면, 디스크와 네트워크 장치를 모두 VirtIO로 설정했는지, QEMU Guest Agent가 설치되어 잘 작동하는지 꼭 확인해봐요. CPU 타입도 ‘host’로 설정하는 게 최적의 성능을 낼 수 있습니다.

    🎉 마이그레이션 결과 확인 및 검증

    모든 과정을 거쳐 VM이 정상적으로 부팅되고 작동한다면, 이제 마이그레이션이 성공적으로 완료된 거예요. Proxmox 웹 UI에서 VM의 상태를 확인하고, 게스트 OS 내부에서 네트워크 연결, 서비스 동작 여부 등을 꼼꼼히 검증해야 합니다.

    • Proxmox 웹 UI 확인: VM의 CPU, 메모리 사용량, 네트워크 트래픽 등이 정상적으로 표시되는지 확인해요. QEMU Guest Agent가 활성화되어 있다면, IP 주소도 보일 겁니다.
    • 게스트 OS 내부 확인: SSH나 콘솔로 접속하여 주요 서비스(웹 서버, DB 등)가 제대로 시작되었는지, 파일 시스템은 정상인지, 네트워크 연결은 원활한지 테스트해요. ping, ifconfig (또는 ip a), df -h 등의 명령어를 활용하면 좋겠죠.

    Proxmox VE 웹 인터페이스에서 성공적으로 마이그레이션된 가상머신의 개요 대시보드 화면입니다. VM의 상태, 리소스 사용량, 네트워크 정보 등을 한눈에 확인할 수 있습니다.

    마무리하며: Proxmox, 새로운 시작을 위한 현명한 선택

    솔직히 처음엔 VMware ESXi에 너무 익숙해서 Proxmox VE로 넘어가는 게 번거롭지 않을까 걱정했었습니다. 하지만 직접 마이그레이션을 해보고 몇 주간 운영해보니, Proxmox VE는 충분히 강력하고 유연한 대안이라는 걸 깨달았어요. 물론 중간중간 삽질도 좀 했지만, 그 과정에서 얻은 경험은 정말 값지다고 생각합니다.

    특히 비용 문제로 고민이 많으셨던 분들이나, 홈랩에서 다양한 기술을 자유롭게 실험해보고 싶으신 분들에게 Proxmox VE는 아주 좋은 선택이 될 거예요. 이번 글이 VMware 마이그레이션을 Proxmox로 전환하려는 분들에게 조금이나마 도움이 되었으면 좋겠네요. 다음번에는 Proxmox VE 클러스터링이나 Ceph 스토리지 구성에 대한 저의 삽질 경험을 공유해드릴게요!

    VMware ESXi와 Proxmox VE의 핵심 기능을 비교하는 인포그래픽 표

    VMware ESXi와 Proxmox VE의 주요 특징들을 비교하여 보여주는 인포그래픽 표입니다. 각 솔루션의 장단점을 파악하는 데 도움이 될 것입니다.

  • [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) 구성에 대해서도 다뤄볼 예정이니 기대해주세요! 👍