[Lecture 24] Virtualization

#"가상 시스템"의 정의

• 하드웨어가 아닌 소프트웨어로 구현된 시스템
• 컴퓨터처럼 작동하는 독립적인 환경
• 컴퓨팅 디바이스(명령어 세트 등)에 대한 추상적인 사양
• (언어 기반) 가상 시스템
  • 명령 집합은 일반적으로 기존 아키텍처와 유사하지 않다
  • Java VM, .Net CLR 등등
• virtual machine monitors (VMM)
  • 실제 아키텍처에서 완전히 또는 부분적으로 가져온 명령 집합

#Java Bytecode 예제

Compiled from "h.java"
public class h {
 public h();
 Code:
 0: aload_0
 1: invokespecial #8 // Method java/lang/Object."<init>":()V
 4: return
 
 public static void main(java.lang.String[]);
 Code:
 0: getstatic #13 // Field java/lang/System.out:Ljava/io/PrintStream;
 3: ldc #19 // String Hello, World
 5: invokevirtual #21 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
 8: return
}

public class h
{
 public static void main(String []av) {
 System.out.println("Hello, World");
 }
}

#Virtual Machines 사용

• 응용 프로그램 테스트
• 프로그램/디버깅 OS; 결함 주입
• 애플리케이션 + OS 번들("가상 어플라이언스")
• Monitor for intrusions
• 리소스 공유/호스트 '클라우드 컴퓨팅'
• Migration
• Replication
• 네트워크 시뮬레이션

#CPU 가상화

• 기본 모드: 직접 실행
• Deprivileging 요구
  • (Code designed to run in supervisor mode will be run in user mode)
• 하드웨어 대 소프트웨어 가상화
  • 하드웨어: “trap-and-emulate”
    • Intel/VT 및 AMD/Pacifica가 출시되기 전에는 x86에서 사용할 수 없음
  • 소프트웨어: 
    • 안전한 deprivileging을 위해 트랩에 의존하지 않도록 게스트의 협조가 필요
    • 또는 수정되지 않은 게스트 OS 코드 실행을 방지하기 위한 이진 변환 필요 (binary translation)

#가상 시스템 유형

Type I

Type II

#VMM 분류

#Binary translation vs trap-and-emulate

• 잠깐 역사를 알아보면:
  • IBM/360(70년대) 트랩 앤 에뮬레이트 사용
  • 90년대 후반: x86에는 이진 변환이 필요.
  • 초기 00: x86은 완전한 트랩 및 에뮬레이션을 위한 하드웨어를 추가.
    
  • 2000년대 후반: 주로 하드웨어 기반 가상화 + guest accommodation
• 이진 변환이 트랩 앤 에뮬레이트보다 느릴까?
  • 사실 이진 변환 (binary translation)이 더 빠르다
    • 이진 변환이 고도로 최적화되었다
      • 대부분의 명령어는 IDENT(identical)로 번역되어 대부분의 컴파일러 최적화를 유지하고 코드 크기를 약간 증가시킨다
      • 이진 변환은 적응적일 수 있다: 만약 우리가 명령이 트랩될 것을 안다면, 모든 트랩 핸들러의 부분을 인라인 하면된다. 실제로 trapping보다 훨씬 저렴하다
  • 이러한 트레이드오프는 마이크로코드 지원과 같은 하드웨어 지원이 향상됨에 따라 변화하고 있다

#Virtualizing Memory: MMU

• 게스트 OS 프로그램 페이지 테이블 매핑 virtual → physical
  • 하이퍼바이저가 게스트의 "물리적"을 시스템 주소에 매핑해야 함
• 접근법
  • 섀도 페이지 테이블(ESX): 하이퍼바이저가 페이지 테이블의 복사본을 만들고 MMU에 복사본을 설치한다
  • 반가상화: 게스트의 협조를 얻어 적절한 가상 → 하드웨어 페이지 테이블(Xen)을 생성
  • 하드웨어 지원: 중첩된 페이지 테이블: 하드웨어에서 추가 변환 단계 수행

#Address Translation & TLB

#Shadow Page Tables vs. Paravirtualization vs. Nested Page Tables

Paravirtualized MMU

Shadow Page Table

#ESX의 메모리 관리

• 지금까지 VMM이 적절한 translation을 통해 isolation을 달성하는 방법에 대해 알아봤다
• 그러나 VMM은 리소스 관리 결정도 내려야 한다
  • 어떤 게스트가 어떤 메모리를 얼마 동안 사용할 수 있는지
• Challenges
  
  • 일반적으로 (물리적 메모리를) 꺼내거나 넣도록 설계되지 않은 OS
  • 물리적 메모리가 0에서 시작한다고 가정
  • 모든 물리적 메모리를 항상 무료로 사용할 수 있다고 가정(파일 캐싱 등을 위해)
  • 다른 게스트와 실제 기기를 공유할 수 있다는 사실을 알지 못함
  • 이러한 가정에 따라 프로세스에 대한 페이지 교체를 이미 수행

#가상 메모리의 목표

• 성능
  • 성능이 굉장히 중요하다
    • avg access = hit rate * hit latency + miss rate * miss penalty
    • 가상메모리의 경우 miss penalty가 굉장히 크다
• Overcommiting
  • 전체적으로 게스트에게 더 많은 물리적 메모리를 줄려고함
  • page replacement policy 필요
• Sharing
  • 게스트가 동일한 코드/OS를 실행하거나 동일한 데이터를 처리하는 경우 복사본 하나를 보관하고 Copy-on-Write를 사용

#Page Replacement

• 게스트 페이지를 디스크로 스왑할 수 있어야 함
  • 여기서 질문은, 어떤 것을 스왑해야 할까?
  • VMM은 게스트 내부에서 무슨 일이 일어나고 있는지에 대한 지식이 거의 없다. 예를 들어 게스트의 내부 LRU 목록(예: Linux 페이지 캐시)을 알지 못한다
• 잠재적인 문제: 이중 페이징
  • VMM 스왑 페이지 출력(하드웨어 액세스 비트 기반일 수 있음)
  • 게스트(동일한 사실 확인) - 또한 "교환"을 원할 경우 VMM은 게스트가 페이지를 기록할 수 있도록 디스크에서 페이지를 가져와야 한다
• 더 나은 솔루션 필요

#Ballooning

• 게스트를 속여 메모리 설치 공간을 줄일 수 있다면 어떨까?
• 게스트 커널에 Balloon 드라이버 다운로드
  • Balloon 드라이버가 페이지를 할당하여 게스트의 교체 정책을 트리거할 수 있다
  • Balloon 드라이버 핀 페이지(게스트에 관한 한) 및 (게스트에 대한 비밀 정보)가 VMM에 해당 메모리를 다른 게스트에 사용할 수 있음을 알려준다
  • 풍선을 Deflating하면  게스트의 사용 가능한 페이지 풀이 늘어난다
• 기존의 메모리 커널 내 할당자(예: Linux의 get_free_page())에 의존한다
• 벌룬을 통해 사용 가능한 메모리가 부족한 경우 임의 페이지 교체 수행

Page Sharing (1)

Page Sharing (2)

#Virtualizing I/O

• 세 가지 중에서 가장 도전적인 것
  • 기가비트 네트워킹, 3D 그래픽 장치 고려
• 최신 장치 드라이버는 메모리 및 CPU 관리와 밀접하게 관련되어 있다
  • 직접 매핑된 I/O, DMA
  • scheduling 중단
• Xen

• ESX

Windows Hyper V

#IOMMU & Self-Virtualizing HW

• IOMMU – DMA를 보호하기 위한 하드웨어 지원, space interrupt함
• 자체 가상화(Self-Virtualizing) – 디바이스가 그 위에 여러 VM이 존재함을 인식함

#Container-Based Virtualization

• OS 레벨 가상화 제공
• 3단계 격리
  • 네임스페이스 분리 / Namespace separation(보안 격리)
  • Resource Isolation
  • Fault Isolation
• 예시:
  • chroot, “jails”
  • Solaris Containers
  • 리눅스 "LXC"
• 도커로 상업적으로 이용 가능

#가상화 스펙트럼

#요약

• 가상화를 통해 컴퓨터 시스템을 구성하는 데 있어 다양한 준비/혜택 제공
• 두 가지 유형
  • Type I:  VMM이 bare-hardware에서 실행될 수 있음
  • Type II: VMM은 호스트 OS에서 실행/통합되는 프로세스
• Virtualization의 chanllenge들로는
  • CPU
  • 메모리
  • I/O등이 있다
• 정확성과 효율성 모두 중요하다