Paravirtualization vs Full Virtualization

Paravirtualization vs Full Virtualization

Paravirtualization

Paravirtualization 에서 Guest OS 는 Hypervisor와 직접 통신을 할 수 있도록 설정된다. 이때 Hypervisor을 거쳐서 Hypercall을 사용해 Host OS 와 직접 접속한다.

기본적으로 OS 는 하드웨어에서 직접 실행되도록 설계되어 있다. 하지만 VM 환경에서는 하드웨어에서 OS 가 직접 실행될 수가 없고 Hypervisor 를 거쳐야 한다.

예를 들어서 OS 가 CPU 를 제어하는 명령어를 실행하면 Hypervisor 없이 실행할 경우 - > 진짜 CPU 가 이 명령을 실행해서 (물리적인 CPU 를 조작하게 된다)

하지만 이처럼 Guest OS 가 CPU 명령어를 실행하면 문제가 되는 데, 왜냐면 VM 은 기본적으로 여러 개의 Guest OS 가 실행될 수 있는 데, 각 Guest  OS 가 물리적인 CPU를 독점하거나 다른 VM 을 방해할 수 있기 때문이다.

예를 들어 CR3 레지스터가 페이지 테이블의 주소를 저장하는 레지스터라고 했을 때 Guest OS 가 CR3를 직접 바꾸게 되면 여러 VM 이 서로의 변경 사항을 덮어쓰기가 가능하게 되면서 서로 다른 VM 이 영향을 받게 된다.

그래서 반가상화에서는 Hypercall 을 사용하여 CR3 와 Guest OS 의 변경 사항 요청을 Hypervisor 에 전달하게 된다.

그러면 Hypervisor 는 해당 요청을 받아서 VM 별로 CR3 를 가상화하여 관리하게 된다. 

다른 예시: 디스크 I/O, 네트워크 장치

여러 VM이 디스크를 사용할려고 하면 Virtual Disk 를 통해서 Hypervisor 가 순차적으로 물리적인 Disk 를 사용하게 만듬.

네트워크 장치도 Hypervisor 가 Virtual Network Interface 를 생성해서 하 VM이 Physical Network Interface를 독점하기 못하게 만들었다.

 

 

 

Hypercall 이란??

Guestion OS 가 직접 하드웨어를 제어하는 대신 Hypervisor 에게 요청을 보내는 데 이 과정을 Hypercall 이라고 한다.

Hypercall 은 OS 가 하드웨어 접근이 필요할 경우 Hypervisor 를 통해 대신 처리하도록 요청하는 툭수한 호출이다. (함수 호출과 비슷한)

원래 기존 OS 에서는 사용자 프로그램 -> OS 커널로 요청을 할 때 System Call 을 사용한다. 하지만 가상화 환경에서는 Guest OS -> Hypervisor 로 요청할 때 Hypercall 을 사용한다.

 

반가상화에서 게스트 OS 를 수정한다는 것은?

OS 의 주요 기능 중에서 하드웨어와 직접적으로 연관되는 부분들을 수정한다는 것이다.

ex)

1. 메모리 관리 - 하드웨어 레지스터 CR3, TLB 등의 직접적인 변경을  -> Hypercall 로 사용하게 변경

2. 디스크 I/O를 직접적인 디스크 접근에서 Hypercall 을 통한 요청으로 변경

3. 네트워크 요청을 할때 물리적인 네트워크 카드의 직접적인 사용을 막고 -> Hypervisor 의 Virtual Network Driver 을 사용하게 하는 것이다.

실제로 Xen Hypervisor 에서는 Linux Kernel 을

Xen-aware Kernel 로 수정하여 사용하고

Xen의 Hypercall API 를 추가하여 메모리 관리, 디스크 접근 등을 하이퍼바이저를 통해 수행하도록 변경했다. 

 

Full Virtualization

Guest OS 는 Hypervisor의 존재를 모른다. 그렇기 때문에 Guest OS 가 기존의 물리적인 하드웨어에 요청을 보내는 것과 동일한 작업을 수행하여 Guest OS 가 자신이 실제 하드웨어를 제어한다고 착각하게 된다.

어떻게 착각하게 하는 걸까?

Hypervisor 가 Virtual Hardware를 제공한다.

예를 들어 Guest OS 가 cp 명령어로 파일을 복사하게 되면 Guest OS 는 실제 디스크에서 파일을 복사한 것으로 인지하겠지만 실제로는 Hypervisor 가 이 요청을 받아서 Virtual Disk 에서 복사한 것처럼 처리하게 된다.

이를 가능하게 하기 위해서 Hypervisor 가 모든 명령을 가로채고 변환하여 실행한다. 이때 가짜 하드웨어 환경을 Guest OS 에게 제공한다.

반가상화와 다르게 Hypercall 이 없어도 기존의 OS 를 그대로 사용할 수 있는 것이다.

 

 

특히 Privileged Instructions(특권 명령)을 Binary Translation (명령어 변환)을 통해 처리한다.

Privileged Instructions 란??

OS에서 CPU, Memory, I/O 처리를 직접 제어하는 명령어를 의미한다. 하지만 앞서 살펴봤듯이 VM 환경에서는 Guest OS 가 직접 Prvileged Instructions 을 실행하는 것은 VM들 간의 충돌이 발생할 수 있기 때문에 Hypervisor 가 이러한 명령들을 가로채서 변환 후 실행하는 방식인 Binary Translation 으로 해결하는 것이다.

Binary Translation 은 Guest OS 가 물리적인 CPU를 직접 제어하려는 명령를 실행했을 때 Hypervisor 가 해당 명령을 가로채서 안전하게 실행할 수 있도록 변환 후 실행하는 과정을 의미한다.

ex)

- 디스크 I/O 요청

Guest OS가 write() 라는 system call 을 실행한다.

원래라면 OS 내부에서는 Disk Drive 가 실행되면서 물리적인 I / O 명령을 실행하게 된다.

하지만 Hypervisor 가 해당 요청을 가로채고 Virtual Disk File 인 (.vmdk .qcow2) 등에 데이터를 작성한다.

Guest OS는 디스크에 write() system call을 통해 데이터가 저장되었다고 인식하지만 실제로는 Hypervisor 가 Virtual Disk File 에 기록한 것이기 때문에 물리적인 Hardware에 저장되지 않았다.

 

- 네트워크 패킷 전송

Guest OS가 네트워크 패킷을 보내려고 send() system call 을 실행한다.

OS는 실제 network card(eth0 등)을 사용하려고 한다.

하지만 Guest OS는 실제 네트워크 카드를 제어할 수 없게 Hypervisor 가 해당 요청을 가로채고 Virtual NIC 를 통해서 데이터를 전달한다.

실제로는 Hypervisor가 이 데이터를 받아 Host OS 의 Network Card에서 전송한다.

결과적으로 Guest OS는 자신이 직접 네트워크 패킷을 보냈다고 착각하게 되고 Hypervisor는 해당 네트워크 요청을 가로채서 Virtual Network Interface 에서 처리한 것이 된다.

 

그렇다면 Paravirtualization 에서 사용하는 Hypercall 이 필요없는 이유가 뭘까??

Hypervisor 가 모든 Privileged Instructions 를 가로채서 Binary Translation 으로 변환하고 있기 때문이다.

그래서 Guest OS 를 요청 방식을 수정할 필요가 없고 Hypercall 등의 방식이 필요없는 것이다.

---

"가상화로 관리한다" 는 것 어떤 방식일까?

Hypervisor 는 두 가지 방식으로 Resource를 관리한다.

1) 파일 시스템을 이용한 Virtual Disk (Image File 방식)

각 VM 마다 가상 디스크 파일 

ex) .vmdk .qcow2 .img 같은 파일을 생성한다.

VM은 이 파일을 진짜 디스크인 것처럼 사용하지만 실제로는 Hypervisor 가 관리하는 파일일뿐이다. (가상 디스크)

ex) KVM (QEMU)에서는 .qcow2 같은 image 파일을 사용함

VMware는 .vmdk 파일을 사용한다.

VirtualBox는 .vdi 파일을 사용한다.

결국 이러한 방식은 각 VM이 독립적인 디스크를 가지고 있는 것ㅊ럼 보이게 하는 방식이다. (일종의 트릭)

 

2) 테이블 방식 (VM별 Resource 할당 관리)

Hypervisor 가 VM 마다 CPU, 메모리, 네트워크, 디스크 등의 할당량을 관리하는 Table 을 유지한다.

테이블을 기반으로 VM이 요청하는 자원을 공정하게 스케줄링하여 배분한다.

ex)
VM1이 CPU를 요청하면, 하이퍼바이저는 "VM1에게 2초 동안 실행 기회를 주자" 같은 식으로 스케줄링.
VM2가 디스크 I/O 요청을 하면, "VM1이 디스크 쓰기 중이니까 VM2는 1초 기다려라" 같은 식으로 처리.

Hypervisor 는 "File System 방식" 과 "Table 방식" 을 병행하여 자원을 가상화하고 관리한다.

 

결국 Paravirtualization vs Full Virtualization 둘 다 모든 요청이 Hypervisor 를 거쳐야만 자원을 사용할 수 있다.

차이점은 Guest OS 가 Hypervisor 의 존재를 아는 지 모르는 지가 가장 큰 차이점이며, 이에 따라 OS의 코드가 수정되는 지의 여부가 차이점이다.

 

Demon 의 역할???

Hypervisor 환경에서는 Guest OS가 직접 하드웨어를 제어할 수 없기 때문에 Background 에서 실행되는 Daemon이 Guest OS의 요청을 감지하고 이를 실제 물리적 하드웨어 실행하도록 중재하는 역할을 하게 된다.

Demon은 일종의 "중재자"역할을 하는 Hypervisor의 Service Process 라고 볼 수 있다.

위 과정에서 Daemon의 가장 중요한 역할은 Background 에서 지속적으로 실행되면서 Guest OS의 요청을 감지하고 처리하는 것이다.

 

- 네트워크 요청 처리

Virtual Machine Network 를 사용할 때, 어떻게 물리적인 네트워크 카드와 연결될까?

 VM 내부에서 'ping google.com' 과 같은 네트워크 요청을 하면??

 VM은 자신이 물리적인 네트워크 카드 (eth0 등)을 사용하고 있다고 생각하고 네트워크 요청을 보낸다.

하지만 실제로는 물리적인 네트워크 카드가 아니라 Virtual NIC 와 연결되어있기 때문에 Daemon 이 Virtual Network Request 를 받아서 물리적인 네트워크 장치와 연결해준다.

ex) 네트워크 요청 과정 (KVM/QEMU 환경)

1) VM이 네트워크 요청을 보낸다 (ping google.com)

2) Virtual Network Card (VirtlO-Net, e1000 등 br0)가 해당 요청을 전달한다.

3) Hypervisor의 Network Daemon (qemu-bridge-helper, libvirtd) 이 해당 요청을 감지한다.

4) Host Machine의 실제 네트워크 카드(eth0 등)을 통해 패킷을 전송한다.

5) 외부 인터넷과 연결되며 VM이 인터넷 사용이 가능해진다.