반응형

Host OS: Ubuntu 14.04.1 LTS (amd64)

Guest OS: Windows 10 (64-bit)


연구실 PC가 메모리가 넉넉한 편이라서(16GB) 가상 머신으로 윈도우를 시험삼아 돌려 보고 있는데, 이상하게 오랜만에 가상머신에 원격으로 접속하면 (원격 데스크탑 RDP 사용) 바탕화면이 뜨는데 상당히 오랜 시간이 걸린다. 정확히 재지 않았지만, 1분은 확실히 넘는 것 같다.


가상머신 구성은 다음과 같다:

  • 가상 머신 관리는 QEMU KVM을 사용
  • 윈도우 가상 머신에 CPU 2 Cores (물리적으로 2개, 쓰레드 기준으로 4개), 6GB 메모리, 180GB의 하드디스크를 할당
  • 평소에 항상 PC를 켜 두고, 리눅스를 주로 사용하다가 몇 시간에 한 번씩 윈도우 가상 머신에 RDP로 연결(리미너 원격 클라이언트 또는 FreeRDP 사용)

보통 맨 처음 가상 머신을 부팅시키고 나면 직접 Virtual Machine Manager 어플리케이션에서 확인하든 RDP로 원격접속하든 상관 없이 바로 바탕화면이 나오는데, 윈도우에서의 작업을 마치고 원격 접속 연결만 해제한 채 (즉, 켜진 상태로) 오랜 시간을 쓰지 않으면, 나중에 다시 접속할 때 위와 같이 상당히 오랜 시간이 걸린다. 그리고 그 때 PC의 물리적인 상태를 보면 HDD 램프가 빠르게 깜빡거리면서 하드디스크에 지속적으로 열심히 접근하고 있다.


확인해본 결과, 우분투는 기본적으로 물리적인 메모리에 상주하는 어플리케이션을 가급적이면 스왑 영역(가상 메모리 영역; 즉 하드디스크)에 옮겨 두려는 경향이 크다는 것을 알게 되었다. 그리고 그 경향을 조절하는 설정 변수가 Swappiness이다. 0부터 100 사이의 값 중에서 기본값이 60으로 되어 있다. 60이라는 숫자가 정량적으로 얼마만큼의 메모리 영역을 스왑 영역으로 보내는지는 확실하지 않지만, 경향성이 매우 높은 편에 속한다는 사실에는 이견이 없어 보인다.


인터넷에서 대부분의 우분투 사용자들이 개인 PC에서 우분투를 쓸 때 성능을 개선하기 위해서 가장 먼저 swappiness부터 조정한다는 것 또한 알 수 있었다. 설정 방법은 /etc/sysctl.conf 파일에 아래와 같이 한 줄을 추가하거나, 이미 있으면 숫자를 아래와 같이 조정한다:

vm.swappiness=10


인터넷에서는 보통 swappiness 값을 10 으로 권장하는 분위기이다. 실제로 나도 swappiness 값을 조정하고 나서 윈도우 가상 머신의 원격 데스크탑 접속 로딩 시간이 꽤 단축되는 것을 체감할 수 있었다. 하지만 여전히 몇 시간 후에 다시 접속하면 약 30초 가량의 딜레이가 발생하였다. 그래서 아예 vm.swappiness 값을 3으로 더욱 낮게 설정했더니, 그제서야 길어도 10초 이내로 바로 원격 데스크탑 화면이 나타났다.


개인적인 경험으로 볼 때, 물리적 메모리가 16GB이고 가상 머신을 한 개만 운용하고 있으며, 이외에 메모리를 많이 소비하는 다른 프로그램을 쓰지 않기 때문에 swappiness 값을 매우 낮게 줘도 앞으로 쓰는 데는 문제가 없을 것 같다.


하지만 근본적으로는 서버에서 가상 머신을 돌리는 것이 속도를 개선하는 가장 확실한 방법인 것 같다. 실제로 연구실에서 운용하는 24코어에 64GB 메모리, 5TB의 하드디스크를 갖고 있는 서버에서 동일한 스펙의 가상 머신을 돌리는 것이 개인 PC에서 돌릴 때에 비해 속도가 월등하게 빨랐다. 즉, 그래픽 측면의 이질감과 불편함(폰트 같은 것이 깔끔하게 표시되지 못하고, 게임을 실행하지 못하는 문제)만 감수할 수 있다면, 서버에서 가상 머신을 돌리는 것(결국 클라우드 환경)이 좋을 수밖에 없다.


아직 연구실에 오픈스택(OpenStack)을 적용하지는 못했는데 (당장 이 쪽으로 연구실 구성원 중에 연구주제가 있는 것은 아니고, 운영상의 목적만 있음), 서버 여러 대와 몇몇 잉여 데스크탑 본제들을 조합해서 클라우드 환경을 만들어서 돌려보고 싶다. 일단은 졸업이 급하니 졸업하고 나서 해 봐야겠다. ㅜㅜ


반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04.2 LTS (amd64)


KVM에서 이미 만들어 둔 가상 머신의 디스크 크기(즉, img 파일의 크기와 직결)를 바꾸고 싶을 때 (일반적으로는 늘리고 싶을 때), 아래와 같이 하면 쉽게 된다.


디스크 크기를 변경할 VM을 종료하고 나서, VM 이미지 파일이 있는 곳으로 간다.

이미지 파일 위치는 우분투의 경우 /var/lib/libvirt/images/ 이다.

또는 virt-manager GUI에서 VM 정보 확인하는 창에서 Disk 항목을 선택해서 볼 수도 있다.




해당 디렉토리는 루트 권한이 없으면 열람이 안되기 때문에 루트 계정을 써서 접근한다.

$ cd /var/lib/libvirt/images

$ sudo su

# qemu-img resize [크기 조정할 이미지파일 이름.img] +100G

Image resized.

#


이렇게 설정하고 VM의 디스크 정보를 확인해 보면 용량이 100GB 늘어나 있는 것을 볼 수 있다.

참고로 윈도우 계열(윈도우xp, 7, 8, 10)의 경우 이미지가 늘어나더라도 내 컴퓨터에서 하드디스크를 보면 늘리기 전의 용량으로 되어 있을 텐데, "디스크 관리자"를 이용해서 파티션을 확장해 줘야 한다. (http://skylit.tistory.com/67 참고)


반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04 LTS (64-bit)

KVM version: 0.9.5


인터넷에서 검색해 보면 KVM을 활용하여 브릿지 네트워크를 구축하기 위해서, 자동으로 설정되어 있던 NAT 설정을 지우는 방법은 많이 나와 있다. 어느 해외 블로그에서도 (http://www.cyberciti.biz/faq/linux-kvm-disable-virbr0-nat-interface/) 자동 생성되는 virbr0 인터페이스와 함께 연동된 NAT를 disable 하는 방법은 나와 있지만, 거꾸로 삭제한 NAT 설정을 다시 복구하는 방법이 설명되어 있지 않다.


나도 연구실 서버에 네트워크 브릿지 설정을 진행하면서 NAT를 disable하는 과정을 무작정 따라했는데, 막상 나중에 다시 가상 머신(VM)에 NAT를 쓰게 하려고 보니 어떻게 해야 할지 떠오르지 않았다.리고 결과적으로는 브릿지를 설정하는 과정에서 NAT 설정을 삭제하지 않아도 전혀 문제가 되지 않는다는 것을 알게 되었다.

알고 보니 virt-manager GUI를 이용할 수만 있면 매우 쉽게 NAT 설정을 복구할 수 있음을 알게 되었다. 그리고 굳이 커맨드 라인에서 disable할 필요도 없이 NAT를 중지(disable)하거나 삭제(delete)하는 것도 GUI를 통해서 쉽게 된다. 방법은 아래와 같다.



삭제된 NAT 설정을 복구하기 (새로운 virtual network 생성)


(1) virt-manager를 실행하고, Edit - Connection Details 선택한다.

  원격에서 SSH를 통해서 서버에 접속한다면 X11 forwarding이 가능해야 한다. Desktop Linux에서는 "ssh -X [account_name]@[address]" 명령으로 가능하다.

  Connection Details 창이 뜨면 "Virtual Networks" 탭을 선택한다.



(2) Virtual Network 탭에 가면 아래 그림과 같이 virtual network를 관리할 수 있는 화면이 나온다.

  아래 그림에는 "default"라는 이름의 virtual network가 생성되어 있지만, 위에 링크된 글처럼 disable NAT 과정을 따라하게 되면 default 항목이 사라지고 없을 것이다.

  새로운 virtual network를 만들기 위해서 왼쪽 하단의 "+" 버튼을 누른다.



(3) "Creating a new virtual network" 대화상자가 뜬다. Forward 버튼을 눌러서 진행한다.



(4) Virtual network의 이름을 원하는 대로 지정한다.

  기존에 있던 "default"를 지운 사용자들이라면 간편한 복구를 위해서 이름을 "default"로 입력한다.



(5) NAT를 위한 서브넷 IP주소 대역을 지정한다.

  아래 그림에서는 KVM이 자동으로 192.168.100.* 네트워크를 추천해 주었는데, 원래 지우기 전의 설정에 최대한 맞추기 원한다면 192.168.122.0/24 대역을 써도 좋다.



(6) NAT를 통해서 연결되는 VM들이 할당받을 DHCP 주소 범위를 지정한다.

  앞서서 지정한 NAT의 서브넷 주소 대역 범위 내에서 지정하도록 한다.



(7) 다음 화면에서 virtual network와 physical network 간의 연결을 설정한다.

  여기서는 삭제된 NAT를 복구하는 것이기 때문에 "Forwarding to physical network"를 선택하고, Mode는 "NAT"로 지정한다. Destination 항목은 물리적 네트워크 인터페이스를 지정할 수 있는데, 필자의 경우 굳이 지정하지 않아도 정상적으로 작동하였다.



(8) 마지막으로 설정을 검토하고 Finish를 누르면 새로운 virtual network가 생성된다.





생성된 virtual network를 중지/삭제하기


생성된 virtual network (NAT 설정)을 중지(disable)하려면 처음의 Connection Details 창에서 "X" 버튼을 누르면 된다. 참고로 virtual network 삭제 버튼은 맨 오른쪽의 금지 모양의 버튼인데, 먼저 중지부터 해야 삭제가 가능하다.






생성된 virtual network를 중지/삭제하기


기존에 만들어 둔 VM이 다시 NAT를 쓰도록 하려면 목록에서 원하는 VM을 더블클릭하고, "show virtual hardware details" 버튼을 누른다. (왼쪽에서 두번째 (i) 버튼) 목록 중에서 NIC를 선택하면 우측에 virtual network interface 설정이 나온다.

여기서 Source device 를 아까 NAT로 설정하고 생성한 virtual network로 선택한다. Device model은 아무거나 상관이 없지만 기본 설정은 virtio 이다.





반응형
블로그 이미지

Bryan_

,