반응형

OS: Ubuntu Server 16.04


연구실 서버에 있는 40개의 CPU 코어를 쪼개서 쓰기 위해 우분투 서버 위에 qemu-kvm을 설치하고, 가상 머신(VM)들을 관리하기 위해서 virt-manager라는 GUI 프로그램도 사용하고 있는데, VM 개수가 10개가 넘어가자 작은 문제가 하나 생겼다.


연구실 구성원 모두가 터미널(shell) 환경에서만 작업하는 게 아니라서 호스트 서버의 GUI 화면에도 원격으로 접속할 수 있도록 XRDP와 xfce4-session을 설치해 두었는데, RDP로 접속하면 호스트 서버의 GUI 화면 (xfce4-session에 연결되는 VNC 서버)에 대한 기본 포트는 5910으로 되어 있다.


참고로 XRDP에서 디폴트 설정을 그대로 쓰면 로그인할 때마다 포트번호 -1 값으로 새로운 세션을 새로 실행하게 되고, 그러면 5910번 포트에서 숫자가 1씩 커지면서 세션이 하나씩 새로 생성이 된다.

이전에 이미 만들어 둔 세션에 다시 접속하려면 포트번호에 5910을 입력하면 되는데 (참고: XRDP 기존 세션 재활용하기), 어느 날 포트번호 5910을 입력했더니, 호스트 서버의 화면 대신 내가 예전에 생성했던 VM의 내부 화면이 나타났다.


왜 그런가 해서 보니, qemu-kvm에서 실행 중인 VM의 개수가 10개를 넘어가 있어서 그런 거였다.

(16개 중에 12개의 VM이 실행중... 각각 localhost로 VNC 서버를 돌린다. 즉, 5900~5911까지의 포트가 모두 VM의 화면으로 쓰이는 상태다.)


QEMU에서 VM을 하나 생성하면 해당 VM의 화면을 보여주기 위해서 VM마다 자체적으로 VNC 서버를 실행하고, 그 VNC 화면마다 포트번호가 하나씩 할당이 되는데, 그게 5900번부터 시작한다. 그런데 qemu가 실행하는 VM의 개수가 10개를 넘으면, 10번째로 실행되는 VM은 가상 머신의 화면 출력을 위해 포트번호 5910을 할당받게 된다.


다만, 여기에 호스트 서버의 xfce4 세션이 먼저 실행이 되고 포트번호 5910을 미리 할당받고 있는 상태였으면 VM의 화면이 5910 포트를 할당받는 일은 없었을 것이다. 그러나 호스트 서버를 재부팅시키고 나서, 자동으로 시작하도록 설정되어 있는 모든 VM들이 자동으로 부팅이 먼저 되고, 호스트 서버의 xfce4 세션은 사용자가 명시적으로 실행시켜 주지 않으 5910번 포트가 비어 있게 되므로 10번째로 자동 시작되는 VM이 자연스럽게 5910을 할당받게 된다. 그리고 부팅 직후에 자동으로 같이 부팅되는 VM의 개수가 10개를 넘어간다면, xfce4 세션을 qemu-kvm 서비스보다도 먼저 부팅 직후에 자동으로 실행돼서 세션 하나를 만들어주도록 설정하지 않는 이상 VM 중의 하나가 5910 포트를 점유하게 된다.


결국 원격 데스크톱 연결 앱으로 서버에 접속할 때 맨 처음 나타나는 XRDP 세션 로그인 화면(맨 위의 화면)에서 5911, 5912, ... 이렇게 하나씩 포트번호를 바꿔 가며 접속을 시도해 보니, 호스트 서버를 위한 GUI 세션은 5915번에 할당되어 있었다. (그 당시에 VM 15개가 실행중이었음) 이 상황을 연구실 학생들과 공유를 해야 하는데... 설명하기가 쉽지 않다. ㅜㅜ


여러가지 측면에서 리눅스 서버를 공동으로 관리할 때의 불편함이 있는 것 같다. 그냥 후배들이 똑같은 문제에 봉착하면 그 때 그냥 나와 같은 과정을 거쳐서 XRDP, xfce4-session, qemu-kvm 서비스 및 데몬들이 5900부터 시작하는 포트 번호를 할당받고 반대로 5910 포트를 통해 접근을 시도하면서 서로 어떤 영향을 끼치는지 직접 겪어 보는 수밖에 없는 듯 하다.

회사라면 이런 일을 System administrator가 대신 해 주지만, 연구실은 그렇지 않으니까... 매번 동일한 문제가 생기면 똑같이 겪어 보고 배우는 것이 각자의 이해를 넓히는 측면에서도 바람직한 것이 아닐까 하는 생각도 든다.



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04.2 LTS (amd64)

Virtual Machine Manager 0.9.5-1ubuntu3

KVM: 미확인 (sudo apt-get install kvm 으로 2015년 9월 초에 설치)


우분투에서 virt-manager를 통해서 가상머신을 관리하다가, 시스템 관련 중요 소프트웨어 업데이트를 한 차례 하고 재부팅을 하고 나서 한동안 PlayOnLinux 를 통해서 한컴오피스 2014를 설치하였다.


그러고 나서 가상 머신을 켜기 위해 virt-manager를 실행했더니, 아래와 같은 에러 메세지가 나왔다:

Unable to connect to libvirt.


Verify that:

 - The 'libvirt-bin' package is installed

 - The 'libvirtd' daemon has been started

 - You are member of the 'libvirtd' group


Libvirt URI is: qemu:///system


Traceback (most recent call last):

  File "/usr/share/virt-manager/virtManager/connection.py", line 1027, in _open_thread

    self.vmm = self._try_open()

  File "/usr/share/virt-manager/virtManager/connection.py", line 1009, in _try_open

    flags)

  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth

    if ret is None:raise libvirtError('virConnectOpenAuth() failed')

libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory


이전에는 spice-vdagent 때문에 이와 유사한 에러가 발생했으나, 이번에는 /var/log/spice-vdagent.log 파일에도 아무 변화가 없다. 다른 문제 때문에 발생한 것인데 원인을 찾지 못했다.

비슷한 증상은 여러 사람들이 겪고 있어서 인터넷에 검색이 되었는데 (https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/issues/71), 별 기대를 안했지만 아래와 같이 서비스를 재시작 했더니 해결이 되었다. ㅡㅡ;


$ sudo /etc/init.d/libvirt-bin restart


일단 잘 되니까 다행인데, 현재로써는 시스템 업데이트 등 여러 작업으로 인해 일시적으로 발생한 문제였기를 바라는 수밖에 없겠다.



반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04.2 LTS (amd64)

KVM: 2.0.0 (qemu-system-x86_64)

Virt-manager: 0.9.5


위와 같은 상태에서 가상 머신(VM)을 만들고 Windows 8.1을 설치하였다. VM의 Display 설정을 VNC 대신 SPICE로 하였고, spicec (콘솔에서 실행하는 spice client)를 통해서는 접근이 잘 되었다.


그러나 virt-manager에서 VM 선택해서 확인하는 창에서는 VNC와 달리 볼 수 없었다. 그 이유는 "Cannot display graphical console type 'spice': No module named SpiceClientGtk" 라는 에러 메세지 때문이었는데, virt-manager와 연동해서 spice 서버의 화면을 보여줄 client 모듈이 없다는 것이었다.


virt-manager에서 spice 방식 display를 확인하기 위한 모듈은 spice-vdagent이고, 우분투에서도 apt-get install로 설치는 가능하지만, 문제는 Ubuntu 소프트웨어 센터에서 제공하는 버전을 설치하고 나면 virtio device를 찾지 못해서 virt-manager 자체가 실행이 안되는 버그가 있는 버전이라는 것이다. 로그 확인을 위해 /var/log/spice-vdagent.log 파일을 보면 아래처럼 에러 메세지가 찍혀 있다.

Sep 7 21:14:52.746986 spice-vdagent[2960]: Missing virtio device '/dev/virtio-ports/com.redhat.spice.0': No such file or directory


이 문제는 아래 링크 페이지에 설명되어있다.

https://bugzilla.redhat.com/show_bug.cgi?id=1006205


확인해 보면 spice-vdagent-0.14.0-5.el7 이후 버전은 이 문제가 해결되었다고 나오지만, 2015년 9월 7일 현재 우분투 소프트웨어 센터(apt-get install)를 통해서 설치되는 패키지는 spice-vdagent-0.14.0-1ubuntu1 이라서 아마도 위의 버그를 포함하는 것 같다.


따라서 2015년 9월 7일 현재로써는 최신 버전의 spice-vdagent를 별도로 다운로드 받아야 한다. 아래 링크에서 spice-vdagent로 시작하는 압축파일을 다운받아서 압축을 풀고 설치 스크립트를 실행해서 설치한다.

http://www.spice-space.org/download/releases/



반응형
블로그 이미지

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_

,