한 대의 서버에서 여러 운영체제를 실행할 수 있는 이유는 CPU와 메모리를 운영체제마다 물리적으로 나눠 끼웠기 때문이 아니다. 하이퍼바이저가 각 가상머신에 독립적인 컴퓨터처럼 보이는 실행 환경을 제공하고, 실제 하드웨어를 사용하는 순서와 범위를 조정하기 때문이다.
가상머신에 CPU와 메모리를 지정하는 작업은 물리 자원을 새로 만드는 작업이 아니다. 하이퍼바이저의 원리를 이해하려면 화면에 표시되는 자원과 실제로 사용할 수 있는 자원을 구분해야 한다.
가상머신에는 운영체제가 있고, 하이퍼바이저는 실행 경계를 관리
가상머신(VM)은 가상 CPU, 메모리, 디스크, 네트워크 장치를 제공받고 그 위에서 자체 운영체제와 애플리케이션을 실행한다. 물리 서버를 호스트, VM 안의 운영체제를 게스트 운영체제라고 부른다.
하이퍼바이저의 핵심 역할은 자원 접근을 중재하고 실행 환경을 격리하는 것이다. VM 생성 화면이나 관리 콘솔은 이 기능을 설정하는 도구이며, 화면 자체가 하이퍼바이저인 것은 아니다. Linux 커널의 KVM API 문서도 VM 생성, 가상 CPU 생성, 메모리 영역 설정, 가상 CPU 실행을 별도 작업으로 구분한다. Linux 커널 — KVM API
이 구분은 장애 분석에서도 유용하다. 관리 화면에 접속되지 않는 문제와 이미 실행 중인 VM이 멈추는 문제는 원인과 영향 범위가 다를 수 있다. 관리 도구, 실행 계층, 물리 장비를 하나의 구성 요소처럼 취급하면 확인해야 할 지점을 놓치기 쉽다.
Type 1과 Type 2 하드웨어 접근 구조 차이
Type 1은 하드웨어 위에서 게스트 실행을 제어하는 방식이고, Type 2는 일반적인 호스트 운영체제 위에서 가상화 소프트웨어가 동작하는 방식이다. Red Hat은 KVM과 Hyper-V를 Type 1, VirtualBox와 VMware Workstation을 Type 2의 예로 설명한다. Red Hat — 하이퍼바이저의 유형
다만 Type 1을 운영체제나 드라이버가 전혀 없는 구조로 이해하면 부정확하다. Hyper-V는 하이퍼바이저 외에 Windows가 실행되는 루트 파티션을 두며, 이곳에서 관리 기능과 장치 드라이버를 처리한다. 따라서 Windows 화면에서 VM을 관리한다는 이유만으로 Type 2라고 판단할 수 없다. Microsoft — Hyper-V Architecture
실무적으로는 유형 이름보다 운영 목적을 먼저 확인하는 편이 낫다. 개발자의 PC에서 테스트 환경을 실행하는 경우와 여러 업무 서버를 통합하는 경우에는 관리 체계, 장비 지원, 점검 방식이 다르다. Type 1이라는 분류만으로 성능이나 안정성이 자동으로 보장되지는 않는다.
CPU는 명령을 실행, 하이퍼바이저는 실행 기회를 조정
가상 CPU(vCPU)는 게스트가 CPU로 인식하는 실행 단위다. 일반적인 공유 구성에서는 vCPU 하나가 물리 코어 하나를 항상 독점하지 않는다. 실행 가능한 vCPU에 물리 CPU 시간을 배정하는 스케줄링이 필요하다. 전용 할당이나 CPU 고정 같은 별도 설정은 제품과 구성에 따라 달라진다.
하드웨어 지원 가상화에서는 많은 게스트 명령이 실제 CPU에서 실행된다. 모든 명령을 소프트웨어가 하나씩 해석하는 방식으로 이해할 필요는 없다. 대신 가상화 계층의 처리가 필요한 특정 명령이나 이벤트가 발생하면 제어가 전환된다. Oracle 문서는 Intel VT-x에서 게스트 실행으로 들어가는 전환을 VM entry, 빠져나오는 전환을 VM exit로 설명한다. Oracle — Hardware Virtualization
이 원리에서 도출되는 운영상의 판단은 명확하다. VM에 vCPU를 더 지정해도 물리 CPU의 총 처리 능력이 늘어나지는 않는다. 여러 VM이 동시에 바빠지면 실행 대기가 생길 수 있으므로, 성능 저하를 분석할 때는 게스트 CPU 사용률과 호스트의 자원 경합을 함께 확인해야 한다. vCPU 증설은 작업의 병렬 처리 가능성과 실제 병목을 확인한 뒤 결정하는 것이 합리적이다.
메모리는 게스트의 주소와 실제 저장 위치를 연결
게스트 운영체제는 자신에게 제공된 메모리를 기준으로 프로그램과 데이터를 관리한다. 그러나 게스트가 물리 메모리라고 인식하는 주소는 호스트의 실제 메모리 주소와 같지 않을 수 있다. 가상화 계층은 이 관계를 관리하며, 하드웨어의 주소 변환 기능이 이를 보조한다.
일반적인 가상화 메모리 구조에서는 프로그램의 가상 주소가 게스트 물리 주소로, 다시 호스트 물리 주소로 연결된다. 게스트가 보는 메모리 공간과 실제 메모리를 구분하는 것이 핵심이다. Hyper-V 공식 문서 역시 게스트별 메모리 영역과 주소 변환 지원을 설명한다. Microsoft — 메모리 처리 구조
운영 관점에서는 VM에 표시된 메모리 용량의 합만 보고 여유를 판단하기 어렵다. 동적 메모리 조정이나 과할당의 지원 여부와 동작은 제품마다 다르며, 호스트에도 관리용 메모리가 필요하다. 업무가 동시에 몰리는 시간대의 실제 사용량과 메모리 회수·스와핑 여부를 확인해야 한다. 평균 사용량이 낮다는 이유만으로 최대 부하에서도 충분하다고 판단해서는 안 된다.
디스크와 네트워크 요청은 가상 장치에서 실제 장치로 연계
게스트가 파일을 저장하면 게스트 운영체제는 가상 디스크 장치에 요청을 보낸다. 일반적인 소프트웨어 중재 방식에서는 가상화 입출력 계층이 이를 처리하고, 호스트의 저장장치 접근으로 연결한다. 가상 디스크는 호스트의 이미지 파일로 구현될 수 있지만 모든 환경에서 파일 형태만 사용하는 것은 아니다.
입출력 처리 방식도 하나로 고정되지 않는다. 실제 장치를 흉내 내는 에뮬레이션 방식과 가상화 환경을 인식하는 드라이버를 사용하는 방식은 처리 경로가 다르다. Hyper-V의 합성 장치와 VMBus는 후자의 구체적인 예다. 장치 직접 할당처럼 일부 경로를 우회하는 구성도 있어, 모든 요청이 동일한 단계를 통과한다고 일반화하면 안 된다. Microsoft — VMBus와 가상화 인식 입출력
실무자 관점에서 보면 VM 내부의 디스크 여유 공간과 호스트 저장소의 여유 공간은 별도로 확인해야 한다. 여러 가상 디스크가 같은 저장장치를 사용한다면 한 VM의 대량 읽기·쓰기가 다른 VM의 응답 지연과 함께 나타날 수 있다. 이는 VM이 독립적인 컴퓨터처럼 보여도 물리적인 처리 경로는 공유할 수 있기 때문이다. 가상 네트워크 역시 게스트 설정과 실제 연결 경로를 함께 살펴야 한다.
격리된 VM도 공통 기반의 장애와 관리 위험을 공유
VM 간 격리는 중요한 기능이지만 무조건적인 보안 보장은 아니다. NIST SP 800-125A Rev. 1은 서버 기반 하이퍼바이저 플랫폼의 보안을 다루며, 실행 격리와 가상화 기반에 대한 통제를 함께 검토한다. 게스트 운영체제의 보안 조치만으로 하이퍼바이저와 관리 계층까지 보호되는 것은 아니다. NIST — 하이퍼바이저 플랫폼 보안 권고
공통 기반을 공유한다는 사실에서 몇 가지 운영 과제가 나온다. 호스트 장애가 발생하면 그 호스트에 의존하는 여러 VM이 함께 영향을 받을 수 있다. VM을 많이 만든 것만으로 이중화가 완성되지는 않는다. 관리 계정의 권한, 관리망 접근 범위, 호스트 패치와 점검 일정도 게스트 운영체제 관리와 별도로 정해야 한다.
도입 전에는 세 가지를 구체적으로 확인할 필요가 있다. 첫째, 최대 부하에서 CPU·메모리·저장장치가 감당할 수 있는 VM 구성을 검증한다. 둘째, 호스트 한 대를 점검하거나 사용할 수 없게 됐을 때 업무를 유지할 방안을 정한다. 셋째, VM의 복구 절차뿐 아니라 가상화 플랫폼의 설정과 관리 접근을 복구할 절차까지 확인한다.
하이퍼바이저를 선택하는 기준은 실행 가능한 VM 개수만으로 정하기 어렵다. 자원이 부족할 때의 동작, 입출력 경로, 장애 영향 범위, 관리 책임을 설명할 수 있는 구성이 실제 운영에 적합한 구성이다.