2010년 8월 7일 토요일

vmware 우분투(리눅스) 설치 팁(II) - 가상화 설정

Guest OS(리눅스)의 가상화 설정

 

더 이상 CPU의 가상화 지원이 새삼스럽지 않다.
그만큼 클라우딩 컴퓨팅 환경과 가상화에 대해 사람들이 더 이상 새롭게 느끼질 못한다.

 

하지만 정작 그 가상화 기능을 사용하는 유저인 나는 실제 적용을 잘 못하고 있었던 것 같다... ㅡㅡ;;
특히 paravirtualization 이나 hypervisor 와 같은 용어에 대해서 혼란을 겪고 있었는데,
다음 링크를 통해서 어느정도 개념을 정립할 수 있었다.

 

IMB DW - 가상 리눅스
위키백과 - 하이퍼바이저


대충 보면,

 

Hypervisor

하이퍼바이저(hypervisor)는 호스트 컴퓨터에서
다수의 운영 체제(operating system)를 동시에 실행하기 위한 가상 플랫폼(platform)을 말한다.
가상 머신 모니터(virtual machine monitor, 줄여서 VMM)라고도 부른다.

걍 VMM = Hypervisor 라고 이해하면 될 듯...

 

 

전체 가상화(Full virtualization)

네이티브 가상화 라고도 하며 하드웨어 위에 VMM이 있어서
VMM이 게스트(guest) OS들과 네이티브 하드웨어 사이를 중재(mediate)하는 형태.
특정 모드에서 실행되는 명령들은 VMM에서 trap 혹은 mediate 되는 방식.

풀이하면 거의 모든 하드웨어 관련 처리를 VMM이 중간에서 무식하게 전부다 처리해주는 방식.

 

 

준가상화 혹은 반가상화? (Paravirtualization)
게스트 OS수정해서 특정 하드웨어 처리에 대해서는 VMMtrap필요없이
빠른 처리가 가능하도록 만든 가상화 방식.
다만 게스트 OS수정해야한다는 단점이 있다.

para 라는 접두사가 보통 (準) : "비슷하긴 하지만 공식적이거나 완전히 자격을 갖추지는 않은"
이라는 뜻이 있으므로 쉽게 유추해볼 수 있다.
위의 전체 가상화에서는 하드웨어에 대한 요청에 해서 trap이나 부가적인 처리를 VMM이 해줘야 했는데,
게스트 OS를 수정해서 VMM에서 해줘야 했던 부가적인 처리나 trap을 거치지 않고도
VMM을 통해서 해당 명령을 빠르게 처리해주는 방식. 대충 이 정도 이해를 하면 될 듯 하다.

 

 

Intel VT-x / AMD AMD-v

x86 아키텍쳐에서 CPU가 하드웨어적으로 지원하는 가상화 방식들이다.

이들 프로세서는 모두 x86 아키텍쳐에서 동작하는 가상화 지원 방식들인데,
x86 아키텍쳐의 특징상 여러 모드에서 문맥을 보고 해당 명령의 리터값이 결정된다.
x86의 권한 모드는 모두 4가지 레벨(Ring 0, 1, 2, 3) 이 존재한다.
Ring 0(가장 높은 권한)가 OS를 Ring 1 2 는 일반적으로 디바이스 드라이버를,
마지막으로 Ring 3가 유저 어플리케이션을 지원한다.
같은 명령이라도 해당 권한 레벨에 따라서 다른 값을 리턴하는 것이다.
(x86 아키텍쳐의 보호모드에서의 권한모드에 관련된 내용은 여기에서 살펴봅니다.)
이러한 난제때문에 초창기에는 x86에서는 가상화가 힘들거라는 평이 많았다.
그러나 요즘 CPU들은 이런 아키텍쳐를 극복할 수 있는 위의 기술들을 제시하며, 가상화 시대를 제촉하고 있다.

 


이제 개념도 어느정도 정립했으니, 당장 vmware에서 내가 사용할 수 있는 가상화 옵션을 살펴보자.


vmware에서 나온 문서가 가장 정확하니, 다음 pdf 문서를 봅니다.
http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf

 

요약을 해보면, vmware는 3가지의 가상화 지원 서비스를 제공하고 있습니다.

 

1. Full virtualization - binary translation

2. Paravirtualization

3. Hardware assisted virtualization

 

1. Full virtualization - binary translation

역시 위에서 살펴본 전체 가상화 기술입니다.
vmware 가 가장 기본적으로 제공하고 있는 가상화 기술로써 우리가 그냥 설치하고 아무런 설정없이,
또한 가상화 지원기술이 없는 CPU를 사용하고 있다면, 바로 이 full virtualization 을 사용하고 있는 겁니다.
vmware 지원 기술 중 가장 느리지만 가장 범용적인 것이죠.

아래 그림을 보면,

The binary translation approach to x86 virtualization

x86 아키텍쳐 상에서 Guest OS는 Ring 1에서 지원되고 VMM 은 Ring 0 즉 OS 상에서 지원되고 있음을 알 수 있습니다.
VMM 에 의해서 게스트 OS는 하드웨어와는 완전하게 분리되어 추상화됩니다.
즉 게스트 OS는 자신이 가상화된 상태인지도 모르는 거죠.
하드웨어 상에서 돌아가고 있는 상황과 전혀 다르지 않다는 겁니다.
sensitive instructions 이나 privileged instructions의 가상화에 대해서
하드웨어상의 지원이나 OS의 지원이 전혀 없다고 볼 수 있습니다.
VMM이 모든 OS 단의 명령들을 처리하는 반면 유저 레벨의 명령들은 네이티브 속도로 실행됩니다.


2. Paravirtualization

앞의용어 설명에서 언급한 것처럼 guest OS의 일부분을 수정해서 호스트 OS에서 좀 더 빠른 처리가 가능하다록 한 것입니다.
Full virtualization 에서는 guest OS는 자신이 실제 하드웨어 위에 있는지 VMM 위에 있는지 모른다고 했습니다.
그 만큼 동일한 환경을 제공한다는 것이죠.
그러나 paravirtualization은 guest OS를 가상화를 위해서 수정한 것입니다.
그러니 실제 하드웨어 상에서의 동작과 VMM 위에서의 동작이 달라질 수밖에 없습니다.
당연히 OS를 뜯어 고치는 수고를 더 한 것이니 full virtualization보다는 VMM 위에서 더 빨라야겠죠?
또한 guest os는 실제 하드웨어 상에서 작동될 때에는 더 느려질 수도 있습니다.
Guest OS의 커널을 직접 수정한 것이고 그에 따른 오버헤드가 있으니까요.
그림을 살펴 보면,

The Paravirtualization approach to x86 Virtualization

위의 binary translation 과 달라진 점이 Ring 1 의 자리를 차지하고 있던 guest OS가 더 이상 보이질 않습니다.
Paravirtualized Guest OS 가 ring 0 로 내려와 있고, Virtualization Layer 하드웨어와 ring 0 사이에 위치해 있네요.
가상화가 어려운 명령들을 하이퍼콜로 대체해서 Virtualization Layer 와 직접 communication을 합니다.
당연히 Virtualization Layer의 VMM도 메모리 관리나 인터럽트 처리등의 커널과 관련된
크리티컬한 오퍼레이션에 대한 하이퍼콜 인터페이스를 제공합니다.
이렇게 하면 일부분 host OS의 하드웨어 환경과 동일한 guest OS 하드웨어 환경이 제공됩니다.

Xen이 이러한 가상화 기술의 대표적인 프로젝트 입니다. 성능도 상당히 좋구요.
vmware 에서도 이러한 가상화 기술을 제공을 하고 있습니다.
vmware-tool 이 paravirtualization을 이용한 것이라 볼 수 있죠. 그리고 VMI 도 있구요.
요 VMI는 좀 있다가 다시 설명을 좀 하죠.

 

3. Hardware assisted virtualization

최근 하드웨어 벤더들이 가상화 기술에 상당한 열을 올렸었죠.
AMD를 필두로 Intel도 가세를 해서 이제는 거의 기본이 된 AMD-V 와 VT-x 가상화 기술을 사용하는 겁니다.
두 기술 모두 핵심은 CPU 아키텍쳐에 새로운 실행 모드를 추가한 것입니다.
그림을 보죠.

The hardware assist approach to x86 virtualization

위에서 보면 ring 0에 guest OS가 있고 특이하게 Root Mode Privilege Level 이 추가되어 있는 것을 볼 수 있습니다.
기존의 Ring 0 1 2 3 은 모두 Non-Root Mode Privilege Level 이 되었습니다.
결국 sensitive instructions 이나 privileged instructions 가 하드웨어에 의해 자동으로 VMM으로 trap 되고,
기존의 Binary translation 이나 paravirtualization 은 필요가 없어진 것이죠.

또한 AMD의 NPT 와 Intel의 EPT의 경우 메모리 오버헤드를 줄여주는 가상화 기술을 보여주고 있죠.
특히 시스템 메모리를 많이 잡아먹는 쉐도우 페이지 테이블이 더 이상 필요 없어졌습니다.
그에 따라서 메모리 리매핑을 위한 상당한 오버헤드를 줄일 수 있게 된거죠.
더욱이 I/O 가상화에 대응하는 인텔의 VT-d 나 AMD의 IOMMU 는 DMA와 Interrupt 가상화등을 지원하고 잇습니다.
하드웨어의 가상화 지원이 상당히 빠른 속도로 이뤄지고 있어 오히려 Hypervisor 제공 업체들의 최적화가 시급해 보일 정도입니다.

 

아무튼 vmware 은 이렇게 3 가지 모두 지원하고 있습니다.

 


그럼 guest os로 리눅스 사용시 어떻게 적용하게 될까요?

 

1. Full virtualization

위에 언급한 것처럼 가상화 지원되지 않는 CPU에 그냥 설치한 상태죠.

 

2. Paravirtualization
Paravirtualization은 guest os를 수정해야 한다고 했습니다.
guest os리눅스 커널수정해야 한다는 이야기죠.
다행히 최근 우분투배포판paravirtualization 옵션이 적용된 커널을 기본으로 배포하고 있어요.
그래서 아래그림의 vmware의 한 가지 옵션(VMware kernel paravirtualization)만 체크해주면,

VMware kernel paravirtualization 옵션

Paravirtualization 이 적용된 가상화 기술을 사용할 수 있는거죠.

(참고로 64bit guest OS는 지원하지 않는다고 하는군요.)

현재 자신의 guest OS가 paravirtualization 을 사용하는지 확인하는 방법은
[code]dmesg | grep vmi [/code]

를 해보면 됩니다. 아래 그림 처럼 결과가 나오겠죠?

커널 부팅 메시지의 VMI 항목

 

3.Hardware assisted virtualization

이것 역시 아래 그림처럼 자신의 CPU의 가상화 기술 지원에 따라 설정해주면 됩니다.

CPU가 지원하는 가상화

(인텔은 네할렘부터 EPT가 지원되었으니 참고하세요.)
Help 파일을 보니 그냥 Automatic을 사용하면 알아서 VMware 가 CPU 스펙에 따라서 선택한다고 합니다.

굳이 해당 CPU를 선택할 필요가 없을 것 같습니다. ^^;

 

그런데 몇 가지 문제가 있습니다.
먼저 VMware에서는 paravirtualization hardware assisted virtualization 이 함께 적용될 수 없습니다.
만약 옵션의 VMware kernel paravirtualization 을 체크하고
동시에 Preferred mode에서 Intel VT-x or AMD-V 혹은 EPT/RVI 를 선택한다면
다음과 같은 경고 메시지를 받게 될 겁니다.

VMWare 경고메시지

 

그럼 이제 paravirtualization 을 선택할 건지 hardware assisted virtualization 을 선택할 건지 결정을 해야죠.

넵... 말할 것도 없이 CPU에서 가상화 지원을 해준다면 Hardware assisted virtualization 을 선택합니다.
만약 자신의 CPU가 가상화를 지원하지 않는다면 paravirtualization 을 적용해야 겠지요.

여기서 다시 드는 궁금증...
만약 VMware kernel paravirtualization 도 체크하고 automatic을 선택한다면, VMware는 어떤 모드로 동작하게될까?
제가 테스트한 바로는 해당 guest OSparavirtualization을 지원할 경우 paravirtualization 으로 동작을 하더군요.
CPU가상화지원한다면 automatic 을 선택하고 VMware kernel paravirtualization체크 해제 하세요.
이게 VMware의 최초 default 값입니다. (그럼 도대체 왜 이렇게 장황하게 글을 썼냐? 응? ㅡㅡ;)
만약 가상화를 지원하지 않는 CPU를 가지고 계시면 VMware kernel paravirtualization 을 체크하시구요.

 

두번째 문제는 VMI(Virtual Machine Interface) 관련 문제입니다.
vmware가 paravirtualization을 위해서 그 동안 리눅스 OS에 VMI를 지원해 왔습니다.
그런데 이제 더 이상 지원을 하지 않기로 결정이 되었지요. 아래 링크를 참조하시면 아시겠지만,

http://www.mjmwired.net/kernel/Documentation/feature-removal-schedule.txt#422

http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html

하드웨어 지원의 가상화paravirtualization 의 가상화 퍼포먼스를 비교해 봤더니,
guest os에 여러 수고로움을 마다하지 않았음에도 몇몇 워크로드에서 하드웨어 지원가상화성능상 압도를 당합니다.
그러니 이제 여러 guest OS별로 가상화를 위한 귀찮은 일을  할 필요가 없다고 느낀거지요.
하지만 금방 없어지기 보다는 1~2년 정도의 시간을 두지 않을까? 합니다.
다음은 리눅스 커널(2.6.32) 컴파일 옵션에 나오는 내용입니다.

리눅스의 VMI 관련 커널 컴파일 옵션


이번 글도 글 내용에 비해서 알맹이가 별로 없네요. ㅡ,.ㅡ;;;

 

결국, 결론은

가급적 가상화 CPU 사서 그냥 사용하면 된다!
자신의 CPU가 가상화를 지원하지 않을 경우에만 VMware kernel paravirtualization 을 사용하자!

입니다.  아~ 허무해... ㅡㅡ;;

 

다음 내용은 vmware에 적용할 리눅스 커널 컴파일 입니다.

vmware 우분투(리눅스) 설치 팁(I) - 실제 파티션 사용하기

실제 물리 파티션에 guest OS를 설치하기

 


vmware에서 리눅스를 guest OS로 사용시 성능과 관련해 고려할 주요한 사항을 한번 적어 보겠습니다.
(vmware에 우분투를 설치하는 것은 인터넷에 잠시만 검색해도 다 나오는 내용이니 넘어가겠습니다.)

OS 사용에서 bottleneck 부분의 성능 향상이 결국은 시스템의 전체적인 성능향상으로 이어집니다.
아무리 빠른 CPU와 RAM 이 있어도 Storage의 bottleneck에 정체되면 결국 소용 없는 일이죠.


이 같은 이치는 vmware에서도 동일하게 적용됩니다.
Guest os를 Host OS의 가상화 파일설치할 경우 직접 물리 파티션설치할 때보다 상당한 오버헤드발생합니다.
그래서 호스트 OS가 설치된 HDD가 아닌 다른 여분HDD특정 파티션을 설정하고
 물리 파티션vmware Guest OS직접 설치합니다.
(전체 하드디스크가 아닙니다! 드라이브 내에 있는 하나의 파티션을 말합니다.)

 

문제는 리눅스 배포판의 경우 루트(/) 파티션을 하드의 물리 파티션에 직접 설치하려고 하면,
설치 중간에 grub이 물리 파티션의 파티션 테이블 정보를 직접 수정하려고 할 때,

vmware에서 안정성을 이유로 막아버려서 실제 HDD의 파티션 테이블은 변경되지 않습니다.(당연한거겠죠...)

그래서 정상적인 부팅 진행이 되질 않죠.

 

해결책은 100MB 정도의 작은 가상하드를 만들고 이 하드 전체를 /boot 파티션으로 마운트시키는 겁니다.
그러면 부팅할 때만 grub이 /boot 에서 initrd 와 커널이미지를 참조하고 램디크를 생성한 이후에
실제 물리 파티션루트파티션(/)으로 마운트 시키는 거죠.

 

이렇게 했을 때 좋은 점은 성능상의 잇점뿐만 아니라
호스트 OS의 파티션에 문제가 발생해도 복구가 가능하고,

해당 파티션에 대해 다른 리눅스 시스템에서도 직접 접근이 가능하다는 점이겠죠.

 

 

 

VMWARE에서 물리파티션 추가 보기


 

우분투 설치 중에 파티션 부분을 좀 살펴보죠.

 

 

파티션 설정에서 수동으로 파티션 조정을 선택하고 아래 체크 박스를 누릅니다.

 

 

 

그러면 이렇게 파티션 상황이 나오는데 위에 그림에서
"/dev/sda" 요 하드디스크가 실제 하드디스크 입니다.
/dev/sda2 가 바로 제가 /(루트파티션)으로 마운트할 파티션이죠.

 

 

 

이제 해당 목록을 더블클릭해서 파티션 편집창을 띄우세요.
포맷을 할거면 해당 포맷체크를 하고 기존의 파티션이면 그냥 쓰면 됩니다.
그리고 밑에 마운트 위치/선택해서 루트파티션으로 마운트 합니다.

 

 

 

위에 화면에 보시면 해당 파티션을 제가 사용하고 있었기때문에 실제 수정을 가하지는 않았지만
만약 실제로 변경을 했다면 아래 사진에서도 나오겠지만 타입 ext4 마운트 위치는  /로 나타납니다. ^^;;

 

 

 

이제 /dev/sdb 즉 /boot 로 마운트할 가상드라이브 녀석을 초기화 합니다.

 

 

 

드라이브 초기화를 하면 남은 공간 106MB 가 나오죠.

 

 

 

해당 항목을 다시 더블 클릭하면 위와 같이 파티션 설정을 합니다.
그림처럼 셋팅을 해줍니다.

 

 

 

같은 방법으로 SWAP 도 설정을 해주고 나면 위와 같이 정확하게 마운트할 위치와 해당 파티션이 나오지요.
이제 설치를 진행하면서 마지막 설치 준비 화면이 나올 때까지 진행을 합니다.

 

 

 

여기에서 중요한 셋팅을 해줘야 합니다.
아래부분에 있는 고급 버튼을 선택하고, 생성했던 가상하드디스크 /dev/sdb부트로더를 설치하도록 설정합니다.
실제 루트로 마운트되는 파티션인 /dev/sda 가 아닙니다.
이제 우분투 설치를 시작하고 모두 설치가 되고 나면, 리부팅을 합니다.

 

 

 

리부팅 후에 또 한가지 중요한 셋팅이 있습니다.
리부팅을 하면 vmware부팅 바이오스 화면에서 잽싸게 F2를 눌러줍니다.
그럼 위와 같은 boot 설정에 들어가서 우리가 생성한 가상하드디스크가장 첫 자리에 오도록 합니다.
위에서 VMware Virtual SCSI Hard Drive(0:1)가 바로 그 가상 하드디스크 입니다.
여기 설정을 하지 않으면 부트로더를 찾지 못합니다. 중요!!!
(아마도 vmware 에서 하드 추가한 순서대로 번호가 붙나 봅니다.)
이렇게 해야 /boot 의 grub이 실행이 되겠죠.

이제 변경사항을 저장하고 나오면 vmware 에서 실제 물리 파티션에서 돌아가는 리눅스를 볼 수 있습니다.

 

참고로 게스트 OS에 HDD를 추가하는 순서를 바꿔보면 마지막 바이오스 설정은 필요 없을 수도 있습니다.
예를 들어서 처음 HDD추가를 가상하드로 하게되면 /dev/sda 가  /boot가 되겠죠.
그리고 그 다음에 하드디스크의 실제 물리 파티션을 추가한다면 그 파티션이 있는 하드디스크가 /dev/sdb/ 가 될 겁니다.
그렇게 되면, 그냥 바이오스에서도 첫번재 부팅 순서가 /dev/sda 인 하드디스크가 될테니 말이죠...

 

 

사실 이렇게 장황하게 쓸 필요가 없었는데... ㅡ,.ㅡ;;;

 

 

다음 편에서는 vmware 에서 돌아가는 리눅스인 만큼 가상화와 관련된 매우 중요한 팁을 올려 보겠습니다.
많은 사람들이 헷갈려하는 paravirtualizationcpu 하드웨어 가상화 에 대해서 알아보죠.

2010년 8월 4일 수요일

크롬 툴팁 사전 확장기능



크롬에서 사용할 간단한 툴팁 사전을 만들어 봤습니다.



만들었다기 보다는 여기 저기 소스 가져다 그냥 조합한 수준이지만...







필요하신 분들은 아래 링크로 가셔서 다운받으세요. ^^






ps) 참고로 로컬에 있는 파일을 보실 때에도 사용하고 싶으시다면,

크롬 확장 프로그램 설정 창에서 "파일 URL에 대한 액세스 허용" 을 선택하세요.

2010년 1월 17일 일요일

net 명령어로 samba 서버에 연결된 윈도우에서 세션 끊기!


일단 현재 samba 서버와의 세션이 어떻게 되어 있는지 확인하기 위해서 net use를 사용하자.
컴맨드 창에서 net use를 치면, 사용하고 있는 세션들의 리스트가 나온다.

그리고 원하는 samba와의 연결을 끊기 위해서는

net use \\삼바서버의 이름이나 ip주소\userid /delete
와 같은 명령을 사용하게 된다.

만약 삼바 서버의 주소가 192.168.1.5 이고, 접속하는 계정이 just4kox 라면

net use \\192.168.1.5\just4kox /delete
를 입력하면 해당 삼바 세션이 끊기는데,
이 때 주의 할 점은 네트워크 드라이브로 연결되어 있는 세션은 먼저 네트워크 드라이브 연결제거해야만 한다.
그 이후에 위와 같은 명령을 실행하면 해당 세션을 끊을 수 있다.

리눅스에서 유저에 대한 삼바 권한 설정을 변경 할 때, 윈도우에서 위와 같은 명령을 사용해서 테스트를 하면 편하다. ^^

2010년 1월 13일 수요일

Android 소스 git 이용해서 관리하기.

칸드로이드에 있는 게시물인데 

안드로이드 소스를 받아서 나름의 워킹 프로젝트 만들어서 관리하기에 상당한 도움이 되는 글이다.

기본적으로 git 사용에 익숙하다면, 크게 어려움은 없을 것 같다.

 

안드로이드 소스 저장소 복제 및 활용 가이드

 


>> SSH를 통해서 로컬 클라이언트에서 서버쪽으로 git 계정으로 접근이 가능해야만 한다.
>> 클라이언트에서 각자 만든 공개키(id_rsa.pub)를 git의 repositories가 설치된 내부 로컬 서버로  보낸다.
>> scp "경로/id_rsa.pub" "git설치된서버의git홈경로/.ssh/authorized_keys" 를 이용해서 각 로컬클라언트 추가하기.
>> 각기 다른 로컬에서 모두 서버의 git 계정으로 로그인한다. git 내에서 각각의 클라이언트 모두 다른 설정이 가능.

 

>> 참고로 내부 클라이언트에서 로컬 서버로 접속이 잘 되지 않거나 repo init 이 되지 않는다면,

>> 주소를 git@192.168.1.2:/home/git/repositories/android/ 와 같은 절대 경로로 써주면 된다.

 

>> 또한 cupcake 대신 eclair 로  입력하면, 그나마 최신버전 소스 받을 수 있다.