ARM 가상화 관련 자료
- ARMv7 Architecture Overview
- KVM for ARM: 대표적인 오픈 소스 ARM 하이퍼바이저 1(논문)
- Xen ARM: 대표적인 오픈 소스 ARM 하이퍼바이저 2(위키)
- Hardware-Supported Virtualization on ARM: ARM 가상화 확장을 정리한 논문
- Virtual Open System: KVM/ARM을 기반의 ARM 가상화 솔루션을 제공하는 start-up
ARM Cortex-A 페이징 (1)
최근에 생성한 다른 블로그에 ARM Cortex-A 페이징에 대해 정리하였습니다. 쓰다보니 글이 길어져서 여러편으로 나누게 되었네요.
1편은 페이징에 대한 전반적인 내용과 1단계 페이징과 L1 페이지 테이블 엔트리에 대한 내용을 담고 있습니다.
'Xen으로 배우는 가상화 기술의 이해 - 메모리 가상화' 출간!
이번 편은 메모리 가상화에 대한 내용입니다. 우리가 사용하는 어플리케이션이 사용하는 메모리 주소는 실제 물리 메모리의 주소가 아닙니다. 모든 어플리케이션이 동일한 가상 주소를 사용하는대요. 이 가상 주소를 물리 주소로 변환하는 것을 '페이징'이라고 합니다. CPU의 MMU(Memory Management Unit)가 가상 주소를 물리 주소로 변환하는 페이징을 합니다.
자~그럼 가상화 환경에서 페이징은 어떻게 할까요? 가상 머신의 물리 주소가 물리 메모리의 물리 주소가 될까요?
그 해답에 대한 내용이 이 책에 담겨 있습니다.
전자책이므로 서점에는 없습니다. 한빛미디어 홈페이지에 접속하시면 저렴한 가격으로 pdf를 구매하실 수 있습니다.
'Xen으로 배우는 가상화 기술의 이해 - CPU 가상화' 출간!
매주 토요일 공저자 세 분과 함께 Xen 하이퍼바이저 소스 코드를 분석을 했던 내용을 책으로 엮었습니다. 최근 IT 분야의 핫 이슈라면 클라우드와 빅 데이터를 들 수가 있는데, 가상화 소프트웨어는 그 중 클라우드의 핵심이 되는 컴포넌트입니다. 번역서를 제외하고는 가상화 소프트웨어 활용이 아닌 내부 구조를 본격적으로 다루는 최초의 국내 서적이므로 가상화 기술에 관심이 있으시거나 공부하시는 분이라면 한번 보시길 바랍니다.
많은 배경 지식과 경험이 필요한 시스템 소프트웨어 분야의 특성상 집필 과정에서 내용을 어느정도 수준까지 다루어야 하는지 설정하는 것이 가장 힘들었습니다. '이정도는 다들 알고 있겠지?' '이런 것까지 설명해야 되나?'등의 많은 고민을 거쳐서 집필 하였지만 독자의 입장에서는 잘 이해되지 않는 난해한 부분이 있을 수 있습니다. 더구나 소스 코드 분석에 대한 내용이 많다보니 소스 코드를 보는 것에 익숙하지 않는 독자라면 더욱 힘들지도 모르겠습니다. 그런 분들은 책을 집필한 저자들에게 질문을 주시면 저희가 아는 한도에서 최대한 성실하게 답변드리도록 하겠습니다.
전자책이므로 서점에는 없습니다. 한빛미디어 홈페이지에 접속하시면 저렴한 가격으로 pdf 파일로 구매해서 보실 수 있습니다.
핫이슈를 넘어서 이제는 당연시 되고 있는 클라우드 시스템(Cloud System). 클라우드를 구성하는 요소 중에서 가상화(Virtualization) 기능은 빠질 수 없는 핵심 요소 중에 하나라고 할 수 있다. 가상화를 하기 위해서는 하이퍼바이저(Hypervisor, Virtual Machine Monitor이라고도 한다)라는 별도의 시스템 프로그램이 필요하다. 이미 서버단의 가상화는 자원의 효율성 측면에서 기본이 되어가고 있다.
가상화 분야에서 '가상화 대상이 되는 시스템'을 의미하는 용어는 여러 용어가 횬재되어 사용되니 정리하고 넘어가자. '가상머신(Virtual Machine)'-약어로 'VM', '도메인(Domain)'-약어로 'Dom', '게스트(Guest)' 이들 용어 모두가 '가상화 대상이 되는 시스템'을 의미한다. '게스트 운영체제'와 대비되는 '호스트 운영체제'는 가상화 프로그램을 실행하는-즉, 가상화 하지 않은- 실제 운영체제를 의미한다. 호스트 운영체제는 Type 2에서만 존재하는데, Xen은 Type 1 하이퍼바이저이므로 호스트 운영체제가 존재하지 않는다. Type 1은 하이퍼바이저 위에 모든 도메인이 동작하는 방식이고, Type 2는 호스트 운영체제에서 가상화 프로그램을 실행하여 게스트를 실행하는 방식을 말한다.
<그림 1. Type 1과 Type 2 하이퍼바이저>
대표적인 오픈소스 하이퍼바이저로는 Xen과 KVM이 있다. Xen은 'Xen and the Art of Virtuallization'이라는 가상화 분야에서 매우 유명한 논문과 함께 대표적인 반 가상화(Para Virtualization) 하이퍼바이저로 등장하였다. 반 가상화는 게스트 운영체제 일부를 수정하는 시스템을 말한다. 반 가상화의 대비되는 전 가상화(Full Virtualization)은 게스트 운영체제를 수정하지 않고 실제 머신과 동일하게 사용하는 것을 말한다. Xen의 반 가상화의 게스트 운영체제는 특권 명령을 실행하려면 '하이퍼콜(Hypercall)'로 하이퍼바이저에게 서비스를 요청하는 해야 한다. 운영체제에서 어플리케이션이 커널에게 '시스템 콜(System Call)'로 서비스를 요청하는 방식과 동일하다. 실제로 하이퍼 콜은 시스템 콜과 동일한 방식으로 구현되어 있다. 서비스를 요청이 (어플리케이션 -> 커널) 인지, 아니면 (게스트 운영체제 -> 하이퍼바이저) 인지에 따라 용어가 달라질 뿐이다.
Xen에는 도메인 0라는 특수한 도메인이 존재한다. 도메인 0는 실제 물리 디바이스와 통신하는 디바이스 드라이버가 있고, 각 도메인을 제어한다. 도메인 0는 기능상 Type 2 하이퍼바이저의 호스트 운영체제와 유사하지만, Type 2에서 호스트 운영체제는 하이퍼바이저를 하나의 어플리케이션으로 관리하고, Type 1에서 도메인 0는 하이퍼바이저에서 하나의 도메인으로 관리되므로 전혀 의미가 다르다. Xen 반 가상화에서 장치 입/출력을 예를 들면, 각 도메인은 하이퍼 콜로 Xen 하이퍼바이저에게 입/출력 요청을 하게 되고, Xen 하이퍼바이저는 이를 도메인 0에게 전달하여 실제 장치와 입/출력을 하게 된다. 그러면, Xen 하이퍼바이저는 입/출력 결과를 다시 입/출력을 요청한 도메인에게 입/출력 결과를 응답한다. Xen의 반 가상화 입/출력을 할 시에 사용되는 매커니즘으로 I/O 링, 이밴트 채널(Event Channel), 프론트-앤드/백-앤드 드라이버, 그랜트 테이블(Grant Table), XenStore등이 있지만 모두 설명하려면 내용이 너무 길어지니 그런 것이 있다고만 알고 넘어가도록 하자.
<그림 2. Xen 아키텍처>
KVM은 Xen과 다른 관점에서 가상화를 제공한다. KVM은 가상화를 제공하는 하이퍼바이저를 메모리 관리자나 파일 시스템등과 같은 커널의 '서브 모듈'로 취급한다. 개인적으로는 가상화 기능이 운영체제의 기본이 되어가는 시점이므로 KVM과 같은 접근 방식이 옳다는 생각이다. KVM에서 가상화를 제공하기 위해서는 한 가지 전제 조건이 붙는데, 사용하는 CPU에서 HVM(Hardware Virtual Machine) 기능을 제공해야 한다는 점이다. 과거 가상 메모리(Virtual Memory)를 지원하기 위해 CPU에서 페이징(Paging) 기능을 하드웨어 차원에서 제공했던 것과 같이, 최근 가상화 기능이 많이 사용되므로 CPU에서 가상화 기능을 하드웨어 차원에서 제공해주는 것이다. x86 아키텍처의 HVM으로는 Intel의 VT-x와 AMD의 SVM가 있다. 같은 x86 아키텍처이라고 할지라도 가상화 기능은 벤더마다 다르므로 벤더별로 구현해야 하는 단점이 있다. 최근에는 임베디드 시스템에서 주로 사용되는 ARM 아키텍처도 Cortex-A15 이후로 가상화 확장(Virtualization Extension) 기능이 추가되어 HVM을 제공한다.
<그림 3. KVM 아키텍처>
이렇듯 Xen과 KVM은 가상화를 제공하기 위해 애초에 접근 방법이 다르고 물론 구현도 매우 달랐'었다'. 당연히 프로젝트 초창기에는 Xen과 KVM 양 진영에서 서로 각자가 좋다고 주장하며 많이 싸웠다. 상용 하이퍼바이저인 VMWare, MS 하이퍼-V와 오픈 소스 Xen, KVM 등의 '하이퍼바이저 전쟁'이 한창 이다. (Xen의 반 가상화는 VMWare의 바이너리 변환(Binary Translation)에 대비되는 기술이다. 초창기에는 기술적인 측면에서 '반 가상화 Vs. 바이너리 변환'로 대립하였다.)
여기서 중요한 점은, Xen과 KVM은 오픈 소스라는 것이다. 원한다면 누구나 소스를 볼 수 있고, 필요에 따라 코드를 수정 할 수 있다. 리눅스가 BSD의 장점을 흡수하면서 발전해온 것처럼, Xen과 KVM도 서로 장점을 흡수하면서 발전해 나가고 있다. 이미 Xen도 매우 오래전부터 전 가상화를 지원해 왔다. Xen의 전 가상화는 KVM과 같이 HVM 기능을 활용하여 구현되어 있다. 즉, Xen의 전 가상화 기능만 떼고 봤을 때는 KVM이나 Xen이나 유사하다는 것이다. 더구나 VMWare나 KVM도 반 가상화 기능을 제공한다. Xen의 하이퍼 콜, VMWare의 VMI등의 각 하이퍼바이저 별로 다르게 구현된 반 가상화 인터페이스를 일관된 인터페이스로 추상화 하기 위하여 Paravirt Operation가 등장하였다.
결론은 이제는 가상화 시스템을 구축하기 위하여 어떤 하이퍼바이저를 선택하던간에 비슷하다는 것이다. Xen의 "하이퍼바이저 위에서 모두 놀아라." 라던지, KVM의 "커널이 곧 하이퍼바이저이다." 라던지 현 시점에는 더 이상 의미가 없어졌다. 돈이 좀 들더라도 높은 완성도에 기술 지원을 바라면 VMWare가 정답이고, MS빠라면 하이퍼-V가 정답이다. 무료로 필요에 따라 소스 수정도 할 생각이면 Xen이나 KVM 어느 것도 괜찮다. 그냥 익숙한 것을 선택하면 된다. 지금 사용 중인 하이퍼바이저가 다른 하이퍼바이저보다 성능이 떨어진다면 하이퍼바이저를 의심 할 것이 아니라 튜닝이 잘못 된 것이므로 담당 엔지니어의 능력을 의심해 보라.
qemu/kvm으로 윈도우 가상머신 사용하기
KVM이 활성화 되어 있지 않으면 x86 CPU를 에뮬레이션하므로 매우 느리다. 호스트 운영체제에서 KVM 모듈이 올라가 있는지 lsmod로 확인한다. kvm 모듈과 kvm_intel 또는 kvm_amd 모듈이 올라가 있어야 한다. kvm 모듈이 없으면 리눅스 커널 컴파일 설정과 빌드를 다시 해야한다. (요즘 CPU는 거의 다 포함되어 있지만, 저가형 CPU 모델에는 Intel VT-x와 AMD SVM등의 하드웨어 지원 가상화 기능이 빠져있는 경우도 있다. 이런 CPU에서는 KVM을 사용 할 수 없다.)
$ lsmod | grep kvm
qemu 코드를 받아온다.
$ git clone git://git.qemu.org/qemu.git
컴파일 설정을 한다.
$ ./configure --enable-kvm --enable-sdl --target-list=x86_64-softmmu --audio-drv-list=alsa
- --enable-kvm: kvm 기능 활성화 한다.
- --enalbe-sdl: 로컬에서 디스플레이 하기 위해서 SDL 라이브러리를 활성화 시킨다.
- --target-list=x86_64-softmmu: qemu는 ARM이나 PPC등 호스트와 다른 머신을 에뮬레이션 할 수 있다. 지금은 사용 중인 머신과 똑같은 x86 64bit 아키텍처를 타겟으로 한다.
- --audio-drv-list=alsa: 현재 사용 중인 오디오 드라이버를 포함시킨다.
- --enable-kvm: kvm 기능을 활성화 한다.
- -sdl: 로컬에서 디스플레이하도록 SDL을 사용한다. 이 옵션을 주지 않으면 디폴트는 VNC이다. (원격 데스크탑. VNC 클라이언트로 원격지에서 가상머신에 접속이 가능하다.)
- -m 2048: 메모리 크기 설정. 2G로 설정하였다.
- -cpu kvm64: CPU 설정. 64bit x86 아키텍처이고, KVM을 사용 중이므로 kvm64를 CPU로 설정한다.
- -vga vmware: 비디오 카드 설정. std, cirrus, vmware, qxl, xenfb등을 지원한다. 로컬에서 사용하기에는 cirrus와 vmware가 가장 낫다. qxl은 VNC와 유사한 spice라는 원격 데스크탑 프로그램에 최적화된 비디오 카드이다.
- -soundhw ac97: 사운드 카드 설정.
- -hda windows7.img: 하드디스크 설정.
- -cdrom windows7.iso: cdrom으로 사용 할 ISO 이미지 설정.
- -boot dc: 부팅 순서를 설정한다. D(cdrom) 드라이브부터 부팅해서 Windows 7을 설치 하도록 한다.
패치 승인하기 (git)
1. 패치 내용 저장
- 저장된 파일 이름을 patch_test.mbox, 저장한 디렉토리를 홈 디렉토리의 '문서' 디렉토리에 저장되었다고 가정한다.
$ cd <프로젝트 디렉토리>
$ git am ~/문서/patch_test.mbox
KVM 가상머신 이미지 마운트하기
VMWare나 VirtualBox 등의 가상화 프로그램을 써보면 다들 '공유 폴더' 기능을 제공합니다. 공유 폴더는 게스트 운영체제와 호스트 운영체제 사이에 데이타 공유를 편리하게 만들어 줍니다.
그러면, KVM에서 공유 폴더 설정은 어떻게 해야 할까요? 우선, KVM은 리눅스 커널 기반 하이퍼바이저이므로 호스트 운영체제는 무조건 리눅스 입니다. 게스트 운영체제가 무엇인가에 따라 공유 폴더를 설정하는 방법이 달라지게 되는데, 게스트 운영체제가 리눅스라면 9p virtio를 이용한 방법으로 공유 폴더를 만들 수 있습니다.
저처럼 게스트 운영체제를 윈도우를 사용하는 경우에는 공유 폴더 설정이 달라집니다. 윈도우 게스트와 리눅스 호스트 간의 공유 폴더 설정 방법은 여러가지 있겠지만 NFS나 SAMBA를 활용하는 방법을 추천하더군요. (링크)
저도 그동안 SAMBA로 공유 폴더 설정해서 써왔습니다. 그런데, 이게 생각보다 여러가지로 불편하더군요. 특히, 용량이 큰 파일을 복사할 때 파일이 깨져서 다시 복사해야 하는 경우가 잦았습니다. 짜증나잖아요? 그래서, 호스트와 게스트간에 데이타 공유하는 다른 방법을 찾게 되었습니다.
곰곰히 생각해보니, 가상머신이 사용하는 이미지 파일이 있으니 이것을 호스트 운영체제에서 그냥 mount 해서 사용하면 되겠다는 생각이 들더군요. 찾아보니 역시 가상머신 이미지를 마운트 하는 방법이 있었습니다. 정말 리눅스 커널의 VFS는 멋집니다. :-)
(Mount VM image) $ sudo kpartx -av win7.img (Umount VM image) $ sudo kpartx -dv win7.img |
kpartx -dv가 되지 않으면, /media 디렉토리에 생성된 mount point를 umount하고 하시기 바랍니다.
You are my hero...
오늘 Korea Linux Forum 2012에 다녀왔습니다.
혼자 갔는데, 혹시 아는 사람 없나? 둘러보니 의외로 아는 분이 잘 안보이더라구요. 평일에다가 사람이 원체 많아서 그랬던것 같네요.
중간중간 한국에서 Linux Kernel 분야에서 유명하신 분들을 뵙고, 혼자 속으로 '우와~' 하고 감탄하고 있었습니다. 다음과 같은 분들을 뵈었습니다.
세계적인 리눅스 커널 해커 허태준님!
-> 실력과 글로벌 인지도에 비해 국내에선 그렇게 알려지지 않은 것 같아서 조금 안타깝습니다. 리눅스 커널 메인테이너 중에서도 손에 꼽을 정도로 왕성한 활동 중이신 자랑스러운 한국인입니다.
Korean Top 리눅스 커널 개발자 김남형님!
-> 곧 메인테이너가 되실듯...요즘에는 리눅스 커널 perf tool 부분에 많은 시간을 할애 하시더군요.
'코드로 알아보는 ARM 리눅스 커널' 저자이신 노서형님!
-> 리눅스 커널 소스 분석 스터디 모임에서 온라인으로 자주 뵈었던 분인데, 오프라인에서 제대로 뵙고 인사드린건 처음 인 것 같네요.
