들어가며: VM 이전, 그다음의 운영
VMware를 대신할 플랫폼을 검토할 때는 기존 VM과 애플리케이션을 어디까지 유지할 수 있는지부터 살펴보게 됩니다. VM을 옮긴 뒤에도 생성 요청과 권한 관리, 패치와 장애 대응은 계속됩니다. 플랫폼이 바뀌면 이 일을 처리하는 도구와 담당 팀의 역할도 달라집니다.
VM을 옮긴 다음의 운영도 전환 계획에 포함해야 합니다. 스토리지와 네트워크가 새 환경에 맞는지, 애플리케이션 지원과 백업·복구 체계를 이어갈 수 있는지를 함께 살펴야 합니다. 이 글에서는 운영 통합부터 VMware 이전, PoC 검증까지 OpenShift Virtualization 도입에 필요한 조건을 정리합니다.
읽기 전에: 기준 환경
OpenShift Container Platform 4.22, OpenShift Virtualization 4.22, Migration Toolkit for Virtualization(MTV) 2.12 문서를 기준으로 2026년 10월 6일 확인했습니다. 유지보수 설명은 x86-64 다중 노드 환경을 전제로 합니다.
OpenShift Virtualization 4.22는 OpenShift Container Platform 4.22 클러스터에서 지원됩니다. 확인 시점의 최신 z-stream은 4.22.6이며, OpenShift Virtualization의 최신 z-stream을 쓰려면 OpenShift Container Platform을 먼저 업그레이드해야 합니다. 지원 클러스터 버전
실제 도입 시에는 설치할 패치 버전과 하드웨어·게스트 OS·스토리지의 지원 조합을 다시 확인해야 합니다.
OpenShift Virtualization이란?
OpenShift Virtualization은 VM을 OpenShift에서 배포하고 관리하는 가상화 기능입니다. 애플리케이션을 VM으로 유지하면서 OpenShift의 API와 운영 체계를 사용할 수 있습니다. 컨테이너로 전환할 예정인 시스템과 앞으로도 VM으로 운영할 시스템을 함께 검토할 수 있는 선택지입니다.
VM은 남기고, 운전석을 바꾼다. 애플리케이션의 실행 형태를 유지하면서 관리 인터페이스를 바꾸는 전환입니다. 그에 맞춰 운영 책임과 복구 절차도 다시 정리하게 됩니다.
1. VM과 컨테이너의 운영 통합
VM과 컨테이너를 서로 다른 플랫폼에서 운영하다 보면 하나의 서비스도 여러 팀을 거칩니다. VM 생성은 가상화 팀에, 배포 권한은 플랫폼 팀에 요청하고 장애 분석은 또 다른 팀과 진행할 수 있습니다. 계정과 권한을 각각 관리하는 만큼 감사 자료도 여러 도구에서 모으게 됩니다.
OpenShift Virtualization을 사용하면 VM과 컨테이너를 같은 플랫폼의 API와 권한 체계로 관리할 수 있습니다. 기존 VM을 유지하면서 배포 요청과 승인, 변경 이력을 공통 절차로 정리할 여지가 생깁니다. 이렇게 통합한 절차에서 도구를 오가며 반복하던 일을 줄일 수 있는지 살펴봐야 합니다.
운영 부담을 줄이려면 업무 절차도 함께 정리해야 합니다. 승인 경로와 팀 사이의 티켓 전달 방식이 그대로라면 관리 도구만 바뀌고 운영자의 일은 줄지 않을 수 있습니다.
PoC(Proof of Concept, 개념 검증)에서는 VM 생성 시간과 함께 권한 처리의 중복 작업, 장애 티켓이 팀 사이를 오간 횟수, 감사 자료를 모으는 데 걸린 시간도 비교합니다. 이런 지표가 있어야 운영 절차의 통합이 실제로 도움이 됐는지 판단할 수 있습니다.
Windows나 Active Directory와 연동된 업무 시스템도 VM 형태를 유지하는 방안을 검토할 수 있습니다. 다만 이전 후에도 업무가 정상 동작하는지는 별개의 문제입니다. 인증과 DNS, 시간 동기화부터 에이전트, 라이선스, 백업까지 살펴보고, 업무 담당자의 서비스 검증을 거쳐야 합니다.
애플리케이션 벤더의 지원 범위도 도입 판단에 영향을 줍니다. 확인 시점의 Red Hat 공개 안내에 따르면, SAP는 OpenShift Virtualization 환경의 SAP HANA와 SAP 비즈니스 애플리케이션을 지원하지 않습니다. VM을 실행할 수 있는지와 벤더의 지원을 받을 수 있는지는 각각 판단할 사안입니다. SAP 지원 안내
어떤 OpenShift 제품을 선택하느냐에 따라서도 운영 범위가 달라집니다. OpenShift Virtualization Engine은 VM 중심의 제품으로, 플랫폼 운영에 필요한 인프라 서비스용 컨테이너를 지원합니다. 일반 애플리케이션 컨테이너까지 함께 운영하려면 그 범위를 지원하는 OpenShift 제품과 구독을 선택해야 합니다. Virtualization Engine 개요
비용 비교 역시 구독료에서 끝나지 않습니다. 교육과 운영 절차 재설계, 네트워크·스토리지 구성, 이전 작업에 더해 두 플랫폼을 함께 운영하는 기간까지 포함해야 전체 비용을 볼 수 있습니다.
OpenShift 클러스터 자체를 vSphere 위에서 운영하고 있다면 업무 VM뿐 아니라 클러스터의 기반 인프라를 어떻게 전환할지도 계획에 담아야 합니다.
2. 관리 방식과 운영자의 역할
OpenShift Virtualization은 KubeVirt를 기반으로 VM을 Kubernetes 리소스로 관리합니다. VirtualMachine(VM)은 원하는 구성과 실행 정책을 담고, VirtualMachineInstance(VMI)는 실행 중인 인스턴스를 나타냅니다.
그림 2. 리소스와 실행 구성요소의 관계를 단순화한 그림입니다. QEMU는 virt-launcher Pod 안에서 실행되고, KVM은 노드 커널에 있습니다. 화살표는 패킷이나 디스크 데이터의 이동 경로를 뜻하지 않습니다.
VM 생성과 전원 관리, 디스크 연결, 네트워크 설정, 백업과 복구처럼 운영자에게 익숙한 작업은 그대로 필요합니다. 다만 작업을 요청하고 상태를 살피는 창구가 달라집니다. vCenter에서 처리하던 작업의 일부를 OpenShift 콘솔과 API, 선언적 구성으로 다루게 됩니다.
VMware의 기능과 비교할 때는 이름보다 적용 조건을 살펴보는 편이 정확합니다. vMotion과 라이브 마이그레이션은 실행 중인 VM을 옮긴다는 목적이 비슷하지만 전제 조건이 다릅니다. DRS를 스케줄러 하나로, NSX 정책을 NetworkPolicy 하나로 대체할 수 있다고 단정하기도 어렵습니다. 배치 정책과 네트워크 연결, 트래픽 제어를 실제 요구사항별로 검증해야 합니다.
외부 VLAN에 연결하는 VM을 예로 들면, 호스트 네트워크 구성과 VM의 추가 인터페이스 연결을 함께 설계하게 됩니다. Multus와 NetworkAttachmentDefinition(NAD)은 이 추가 연결에 사용하는 구성요소입니다. 이때 연결을 누가 만들고 변경할지, 장애가 나면 어느 팀이 대응할지도 정해 두어야 합니다.
담당 팀의 역할도 작업 단위에 맞춰 정할 수 있습니다. 예를 들어 다음처럼 나눌 수 있습니다.
•
가상화 운영자: VM 구성과 게스트 OS를 담당합니다.
•
플랫폼 운영자: 노드·스토리지·네트워크와 Operator 상태를 담당합니다.
•
업무 담당자: 이전 후 애플리케이션의 정상 동작을 판단합니다.
역할을 정한 뒤에는 작업 절차와 연락 경로에도 반영해야 합니다. 그래야 장애가 났을 때 여러 팀이 같은 점검을 반복하는 일을 줄일 수 있습니다.
권한도 이 역할에 맞춰 나눕니다. OpenShift Virtualization 4.19부터는 네임스페이스 관리자에게도 라이브 마이그레이션 권한이 기본으로 주어지지 않습니다. 마이그레이션 요청(VirtualMachineInstanceMigration)을 만들 사용자나 그룹에는 kubevirt.io:migrate 클러스터 롤을 별도로 바인딩합니다. 라이브 마이그레이션 권한
VM이 켜지지 않을 때는 VMI의 이벤트와 virt-launcher Pod 상태, PVC의 바인딩과 스토리지 상태를 함께 살펴야 합니다. PVC(PersistentVolumeClaim)는 VM이 사용할 저장 공간을 요청하는 리소스입니다.
OpenShift에 로그인한 oc 클라이언트에서는 다음 명령으로 상태를 조회할 수 있습니다. legacy-vms, rhel9-app01, rhel9-app01-disk는 예시 이름이므로 실제 namespace·VM·PVC 이름으로 바꾸고 조회 권한을 확인합니다. PVC 이름은 VM 이름만으로 추정하지 말고 실제 연결 정보를 기준으로 선택합니다. 세 번째 명령이 VM에 연결된 PVC와 DataVolume 이름을 보여 줍니다.
# 해당 VM의 virt-launcher Pod 상태
oc get pod -n legacy-vms -l vm.kubevirt.io/name=rhel9-app01
# VMI 이벤트와 상태
oc describe vmi rhel9-app01 -n legacy-vms
# VM이 실제로 연결한 PVC/DataVolume 이름
oc get vm rhel9-app01 -n legacy-vms \
-o jsonpath='{range .spec.template.spec.volumes[*]}{.name}{"\t"}{.persistentVolumeClaim.claimName}{.dataVolume.name}{"\n"}{end}'
# 위에서 확인한 PVC의 바인딩 상태
oc describe pvc rhel9-app01-disk -n legacy-vms
Bash
복사
Pod의 실행 상태, VMI 이벤트의 오류 내용, PVC가 볼륨에 정상적으로 연결됐는지를 함께 확인합니다.
3. 유지보수와 장애 복구의 차이
라이브 마이그레이션은 실행 중인 VM을 다른 노드로 옮기는 기능으로, 노드 유지보수나 업그레이드 때 유용합니다. 다만 모든 VM에 적용할 수 있는 기능은 아닙니다. VM의 이동이 가능하더라도 애플리케이션의 무중단까지 보장되는지는 따로 검증해야 합니다.
① 계획된 유지보수와 라이브 마이그레이션
이 글의 기준 환경에서 라이브 마이그레이션을 사용하려면 VM 디스크의 RWX(ReadWriteMany) 접근이 필요합니다. 대상 노드의 여유 메모리와 네트워크 대역폭, CPU 호환성과 배치 조건도 갖춰야 합니다. RWO(ReadWriteOnce) 스토리지나 GPU 같은 passthrough 장치를 사용하는 VM은 대상에서 제외됩니다. 라이브 마이그레이션 조건, 스토리지와 passthrough 제한
RWX는 여러 노드에서 볼륨에 접근하는 방식이고, Block은 볼륨의 표현 방식입니다. 서로 다른 설정 항목이므로 하나의 의미로 이해하면 안 됩니다. Red Hat은 VM 디스크에 RWX와 Block 조합을 권장합니다. 실제 성능과 지원 여부는 사용하는 스토리지 드라이버와 백엔드를 기준으로 판단해야 합니다.
여유 자원은 숫자로 잡아 둡니다. Red Hat 문서는 drain에 필요한 여유 메모리를 '동시에 drain할 수 있는 노드 수 × 노드별 VM 메모리 요청 합계의 최댓값'으로 계산하도록 안내합니다. 동시에 진행되는 마이그레이션은 기본값으로 클러스터 전체 5개, 노드당 송신 2개로 제한되며, HyperConverged CR의 liveMigrationConfig에서 조정합니다. 마이그레이션 한도와 여유 메모리
노드를 유지보수할 때는 먼저 새 워크로드가 배치되지 않도록 한 뒤, drain으로 해당 노드의 워크로드를 비웁니다. 같은 노드의 다른 Pod도 영향을 받으므로, VM의 이동 가능 여부와 대상 노드의 수용 여유뿐 아니라 다른 워크로드의 중단 허용 범위까지 살펴야 합니다.
이동할 수 없는 VM은 drain 전에 따로 처리합니다. 다중 노드 클러스터의 기본 eviction strategy는 LiveMigrate입니다. 이동할 수 없는 VM에 이 값이 남아 있으면 VM이 노드에서 빠지지 않아 drain과 클러스터 업그레이드가 멈춥니다. Red Hat은 이런 VM의 evictionStrategy를 LiveMigrateIfPossible 또는 None으로 바꾸도록 안내하며, 변경 내용은 VM을 재시작한 뒤 적용됩니다. None은 노드 재부팅 때 VM을 종료하므로 업무 중단 일정과 함께 정합니다. eviction strategy
# drain 전에 이동 불가 VM 확인 (LiveMigratable 상태)
oc get vmi -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.status.conditions[?(@.type=="LiveMigratable")].status}{"\n"}{end}'
# 노드 유지보수와 이동 진행 확인
oc adm cordon <node_name>
oc adm drain <node_name> --ignore-daemonsets --delete-emptydir-data
oc get vmim -A
Bash
복사
작업이 끝나면 VM의 이동 결과와 현재 실행 노드, 애플리케이션 응답을 확인합니다. VM 안의 게스트 OS 패치는 노드 유지보수와 별도의 절차로 다룹니다.
노드의 운영체제 버전에 따라 지원 범위도 달라집니다. 4.22에서 RHCOS(Red Hat Enterprise Linux CoreOS) 10.x 워커 노드가 출발지나 목적지인 라이브 마이그레이션은 Technology Preview(기술 프리뷰)로 제공됩니다. 이 환경에서는 마이그레이션 정책에 allowPostCopy: true를 쓰면 마이그레이션이 완료되지 않는 알려진 제한도 있습니다. 운영 지원 범위를 정식 지원 기능과 구분해 검토해야 합니다. RHCOS 10.x의 마이그레이션 지원 범위
② 돌발 장애와 VM 재실행
노드가 갑자기 응답하지 않는 상황에서는 복구 방식이 달라집니다. 원본 노드와 통신할 수 없으므로 정상적인 라이브 마이그레이션을 시작할 수 없습니다. 다른 노드에서 VM을 다시 실행하는 경로가 필요하고, 부팅과 서비스 복구에 걸리는 시간도 중단 시간에 포함됩니다.
그림 3. 라이브 마이그레이션은 실행 상태를 옮기고, 노드 장애 복구는 원본 노드의 실행·쓰기를 차단한 뒤 VM을 다시 실행합니다.
다른 노드에서 VM을 다시 실행하기 전에는 원본 노드가 VM을 실행하거나 디스크에 쓰지 못하도록 차단해야 합니다. 이 절차가 fencing입니다. 원본 VM이 계속 실행될 가능성이 남아 있으면 두 인스턴스가 같은 데이터에 접근할 수 있기 때문입니다.
서비스 중단 시간은 장애 감지와 fencing부터 재배치, 부팅, 애플리케이션 복구까지 모두 포함해 측정합니다.
runStrategy: Always 설정만으로 노드 장애 시 자동 복구가 완성되지는 않습니다. Red Hat 문서가 설명하는 자동 재배치는 installer-provisioned infrastructure(IPI)로 설치하고 MachineHealthCheck(MHC)를 쓰는 클러스터 기준입니다. MHC가 없으면 runStrategy: Always인 VM도 정상 노드로 옮겨지지 않습니다. 이때는 장애 노드의 전원을 먼저 내린 뒤 Node 객체를 수동으로 삭제해야 VM이 다른 노드에서 다시 실행됩니다. 노드가 응답하지 않아도 공유 스토리지에 계속 쓰고 있을 수 있기 때문입니다.
4. VMware 이전과 롤백 계획
Migration Toolkit for Virtualization(MTV)은 소스와 대상 환경을 연결하고, 네트워크와 스토리지를 매핑해 VM을 이전하는 도구입니다. 운영자는 Provider, NetworkMap, StorageMap, Plan 등의 리소스로 이전 구성을 정의합니다. 복사와 변환은 도구가 수행하지만, 업무 중단 승인과 서비스 검증, 롤백 판단은 운영자가 이전 계획에 담아야 합니다.
그림 4. 소스와 대상, MTV의 관리 관계를 표현한 개념도입니다. vCenter가 모든 디스크 데이터의 전송을 중계한다는 의미는 아닙니다.
① Cold와 Warm, 어느 구간에서 멈추는가
VMware에서 VM을 이전할 때 사용하는 Cold와 Warm은 데이터 복사를 시작하는 시점과 서비스가 멈추는 구간이 다릅니다.
구분 | Cold migration | Warm migration |
초기 데이터 복사 | 소스 VM을 종료한 상태에서 복사합니다. | 소스 VM을 실행하면서 사전 복사합니다. |
최종 전환 | 복사와 변환 후 대상 VM을 기동합니다. | cutover에서 소스 VM을 종료하고 마지막 변경분을 복사한 뒤 대상 VM을 기동합니다. |
중단 시간에 포함할 작업 | 데이터 복사, 게스트 변환, 부팅, 서비스 확인 | 최종 변경분 복사, 게스트 변환, 부팅, 서비스 확인 |
선택할 때 확인할 조건 | 전체 작업 시간 동안의 중단을 허용할 수 있는지 | CBT와 VMware Tools 등 사전 조건을 충족하고 전환 구간의 중단을 허용할 수 있는지 |
Warm migration은 디스크를 미리 복사해 최종 전환 때 남는 작업을 줄이는 방식입니다. 실행 중인 VM의 메모리 상태를 이어받지는 않으며, 대상 VM은 새로 부팅합니다. 이 점에서 OpenShift 내부의 라이브 마이그레이션과 동작이 다릅니다. 대상 기동 방식에 따라 운영자가 전원을 켜는 단계도 계획에 포함해야 합니다. Cold와 Warm migration
프리카피 기간도 계획에 넣습니다. MTV 2.12는 기본 1시간 간격으로 CBT 스냅샷을 만들어 변경분을 복사하고, VM 하나가 가질 수 있는 CBT 스냅샷은 28개까지입니다. 소스 VM에 스냅샷이 이미 많아 새 스냅샷을 만들 수 없으면 Warm migration이 실패할 수 있습니다. cutover에 걸리는 시간은 마지막 스냅샷 이후 바뀐 데이터 양에 따라 달라지므로, 변경이 적은 시간대에 전환 일정을 잡습니다.
Warm migration을 선택했다면 VMware Tools와 VM·디스크 단위의 CBT(Changed Block Tracking) 설정부터 살펴야 합니다. 이전 중 외부 백업이 스냅샷을 만들거나 vMotion·Storage vMotion이 소스 위치를 바꾸면 데이터 복사에 영향을 줄 수 있습니다. 복사 도중 실패하는 일을 막으려면 기존 백업 일정과 운영 자동화를 이전 작업에 맞춰 조정해야 합니다. VMware 사전 조건, 이전 중 주의사항
② 업무 검증에서 롤백까지
대상 VM이 켜졌다는 사실만으로 이전을 마칠 수는 없습니다. 게스트 드라이버와 QEMU guest agent, 네트워크와 IP·DNS, 시간 동기화, 서비스 시작 순서, 데이터 정합성까지 살펴야 합니다. Windows의 보안 설정과 가상 TPM(vTPM)에 의존하는 구성, 라이선스와 인증도 점검 대상입니다. 최종적으로 업무 담당자가 서비스의 정상 동작을 확인해야 해당 이전 묶음을 마무리할 수 있습니다.
QEMU guest agent는 설치 여부부터 확인합니다. MTV 2.12 문서에 따르면 VMware에서 Cold migration을 할 때 첫 부팅 중 패키지 매니저를 쓸 수 없으면 MTV가 qemu-guest-agent를 설치하지 않습니다. 인터넷이나 미러 저장소에 접근할 수 없는 폐쇄망이 이런 경우에 해당할 수 있습니다. 기본 VM 동작은 유지되지만 5장에서 다루는 스냅샷 일관성에 영향을 주므로, 이전 후 별도 절차로 설치합니다. Cold migration과 guest agent
대량 이전은 대표 VM으로 파일럿을 진행하고, 그 결과를 바탕으로 범위를 넓힙니다. 이전 묶음은 VM 수뿐 아니라 애플리케이션 의존성과 중단 허용 시간을 기준으로 구성합니다. 동시에 이전할 수 있는 VM 수도 디스크 수와 ESXi의 디스크 복사 서비스(NFC), 소스·대상 스토리지와 네트워크 성능에 따라 달라집니다.
규모를 가늠할 참고 사례로는 Red Hat이 소개한 Emirates NBD가 있습니다. 덜 중요한 업무부터 이전해 하룻밤 최대 140대까지 처리량을 늘렸고, 현재 약 9,000대의 VM을 이 플랫폼에서 운영한다는 사례입니다. 다만 이 수치를 다른 환경의 예상 처리량으로 바로 적용하기는 어렵습니다. 이전 묶음의 크기는 자체 PoC에서 측정한 복사 속도와 업무 검증 시간을 바탕으로 정해야 합니다. Emirates NBD 사례
롤백 계획은 대상 환경에서 업무 데이터가 변경되기 시작하는 시점을 기준으로 세워야 합니다. 그때부터 소스와 대상의 데이터가 달라지므로, 복사 방향을 바꾸는 것만으로는 원래 상태로 돌아갈 수 없습니다. 롤백을 결정할 시점과 승인자, 허용할 데이터 손실, 변경분의 정합성을 맞추는 방법을 미리 합의해야 합니다. IP·DNS를 전환하는 절차와 한쪽에서만 서비스를 제공하도록 통제하는 방법도 함께 정합니다.
5. PoC의 검증 항목과 도입 기준
PoC에서는 VM 부팅부터 유지보수와 장애 대응까지 실제 운영 상황을 시험합니다. 이전하기 쉬운 VM만 고르면 운영 환경의 제약을 놓칠 수 있습니다. Windows와 Linux, 상태를 저장하는 서비스, 큰 디스크, 특수 장치 등 환경을 대표하는 대상을 포함합니다. 지원 조건을 충족하지 못하는 대상은 별도로 분류해 도입 범위를 판단합니다.
① 성능과 복구 목표를 합격 기준으로
시험 결과를 비교하려면 현재 환경의 성능과 업무 허용 기준부터 기록해야 합니다. 서비스 지연과 오류율, 허용 중단 시간에 더해 복구 시간 목표(RTO)와 복구 시점 목표(RPO)를 정합니다. RPO는 복구 시 허용할 데이터 손실 범위를 나타냅니다. 이 기준으로 각 시험의 결과를 판단합니다.
검증 영역 | 완료를 판단할 근거 |
유지보수 | 노드 drain 중 VM 이동 완료 시간, 서비스 응답과 실패 요청 수를 기록합니다. 중단 시간이 합의한 범위 안인지 확인하고, 이동할 수 없는 VM의 eviction strategy와 처리 절차를 정합니다. |
장애 복구 | 장애 감지부터 fencing, 재배치, 부팅, 서비스 복구까지 걸린 시간을 측정합니다. 합의한 RTO를 충족하고 중복 실행·동시 쓰기가 없는지 확인합니다. |
네트워크·스토리지 | 같은 부하에서 이전 전후의 서비스 지연·처리량·패킷 손실과 스토리지 성능을 비교합니다. 필요한 통신과 차단 정책이 유지되는지도 확인합니다. |
이전과 롤백 | Cold·Warm 전환과 업무 검증 시간을 측정합니다. 대상에서 데이터를 변경한 뒤 롤백을 시험하고, 데이터 정합성과 중복 서비스 여부를 확인합니다. |
백업과 복원 | 복원한 VM에서 업무 데이터와 서비스를 확인하고, 합의한 RPO·RTO 충족 여부를 판단합니다. |
운영 인수 | VM 요청부터 제공까지의 시간, 중복 입력, 승인·티켓 전달 횟수와 감사 자료 수집 시간을 비교합니다. 담당 팀이 작업 절차서로 장애를 진단하고 복구할 수 있는지도 시험합니다. |
② 복원한 데이터로 서비스를 확인하기
백업은 복원한 VM에서 서비스를 다시 운영할 수 있는지까지 검증해야 합니다. 스냅샷 생성에 성공했다는 사실만으로는 충분하지 않습니다. QEMU guest agent가 실행 중인 VM의 파일시스템을 freeze·thaw하더라도, 애플리케이션의 데이터 정합성을 확보하려면 해당 애플리케이션의 준비 절차가 필요합니다. Linux의 애플리케이션 훅이나 Windows VSS 구성을 살펴보고, 복원한 데이터로 서비스가 정상 동작하는지 검사해야 합니다.
스냅샷이 실제로 어떤 조건에서 만들어졌는지는 indications 값으로 확인합니다. GuestAgent는 guest agent가 파일시스템을 정지(quiesce)한 경우, NoGuestAgent는 에이전트가 없거나 준비되지 않아 crash-consistent 스냅샷이 된 경우, QuiesceFailed는 정지에 실패한 경우입니다. Windows VM은 부팅 직후 guest agent와 VSS가 아직 준비되지 않아 freeze·thaw가 시간 초과로 실패할 수 있습니다.
oc get vmsnapshot <snapshot_name> -n legacy-vms -o jsonpath='{.status.indications}'
Bash
복사
스냅샷에서 복원하려면 대상 VM을 먼저 정지합니다. 정지부터 복원 완료, 재기동까지의 시간을 RTO 측정에 포함합니다.
복원할 디스크와 장치도 점검 대상입니다. 실행 중에 추가 연결(hot-plug)했지만 VM 구성에 반영하지 않은 디스크는 스냅샷에 포함되지 않습니다. vTPM이 연결된 VM은 복제하거나 스냅샷으로 새 VM을 만드는 방식이 지원되지 않습니다. 이 제한과 기존 VM에 대한 복원은 구분해야 합니다. 스냅샷과 애플리케이션 일관성·복원 제한
같은 스토리지에만 스냅샷을 남기면 그 스토리지 전체가 손실됐을 때 복구할 수 있다고 보장하기 어렵습니다. 백업의 보관 위치를 원본 스토리지의 장애 범위와 분리하고, 사용할 백업 제품과 스토리지 드라이버, 버전 조합으로 복원을 시험해야 합니다. OADP를 쓴다면 Red Hat이 OpenShift Virtualization에 대해 지원하는 방식은 CSI 백업과 CSI DataMover 백업이며, 파일시스템 백업은 지원 범위에서 제외됩니다.
지원 조건과 복구 목표를 충족하고 운영 절차까지 인수할 수 있다면 도입 범위를 넓힐 수 있습니다. 특정 업무나 장치, 백업 방식에 제약이 남아 있다면 조건을 충족한 VM부터 이전합니다. 필수 조건을 맞추지 못했다면 도입을 보류하고 현재 환경을 유지하면서 제약을 해결합니다.
마치며
OpenShift Virtualization은 기존 애플리케이션을 VM으로 유지하면서 운영 체계를 통합할 수 있는 선택지입니다. 실제 도입 범위는 대표 업무의 이전과 유지보수, 장애 복구, 백업 복원을 검증한 결과로 정해야 합니다.
검증한 VM부터 이전하고, 담당 팀이 작업 절차와 복구 방법을 인수할 수 있는 범위에서 전환을 진행합니다. VM의 실행 여부에 더해 서비스의 연속성과 운영자의 대응 능력이 도입 판단의 근거가 됩니다.
참고 자료
•
•
•
•
백업과 복원: 스냅샷·애플리케이션 일관성·OADP
•
•
고객 사례: Emirates NBD
유재전 프로 / 오픈소스기술팀
Red Hat 제품 기술 지원 업무를 담당하고 있어요 