반응형

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_

,
반응형

Host OS: Ubuntu 16.04 (amd64)

Guest OS: Windows 10 Enterprise (64-bit)


KVM에서 윈도우10 가상 머신을 하나 만들어서 쓰고 있었는데, 최근에 아침에 확인할 때마다 계속 재부팅이 되어 있는 것이었다. 윈도우 업데이트 중에서 중요한 것들을 자동으로 설치하고 나면 보통 자동으로 재부팅이 되어 있긴 하지만, 최근에는 매일 아침마다 재부팅이 되어 있길래 의아했다.


업데이트 기록을 보니, 다른 업데이트는 다 되는데 버전 1607 (레드스톤)만 업데이트가 안되고 있었다. 직접 virt-viewer 화면을 통해서 수동으로 1607 업데이트를 진행하는 과정을 지켜보니, 업데이트 설치는 되는데 이후 재부팅할 때 블루스크린이 뜨면서 멈췄다가, 그 뒤에 다시 이전 버전으로 롤백해서 재부팅이 되었다.


윈도우10 업데이트 버전 1607이 다른 업데이트와는 달리 거의 서비스팩 수준으로 많은 것이 바뀌는 버전이라서 업데이트 과정에서 VM 설정과 충돌이 났을 지도 모르겠다.


무엇이 원인인지는 찾지 못했지만, 인터넷에 해결 방법은 있었는데 그게 VM의 CPU 쓰레드 개수를 1개로 설정해 놓고 업데이트를 진행하는 것이었다.

그래서 나도 가상 CPU 1개로 설정하고 업데이트를 하니 정말 문제없이 업데이트가 잘 되었다. =_=...


덕분에 매일같이 재부팅되어 있는 문제는 해결했으니 뭐...



<참고자료>

[1] Windows 10 VM crashes on reboot after installing 1607 update, 

https://forums.lime-technology.com/topic/50477-windows-10-vm-crashes-on-reboot-after-installing-1607-update/




반응형
블로그 이미지

Bryan_

,
반응형

Test OS: Ubuntu 16.04 Server (amd64)


서버가 고정IP(IPv4)를 사용하는 경우를 기준으로 작성했다.



1. brctl 도구를 이용해서 br0 인터페이스 추가

  브릿지 인터페이스 이름은 꼭 br0이 아니어도 상관은 없다.


$ sudo brctl addbr br0



2. 인터페이스 설정


/etc/network/interfaces 파일

auto 이더넷_인터페이스_이름

iface 이더넷_인터페이스_이름 inet manual


auto br0 

iface br0 inet static

    address 고정IP주소

    netmask 넷마스크

    gateway 고정IP에_해당하는_게이트웨이

    dns-nameservers 도메인_네임_서버_IP주소

    bridge_ports 위에_manual로_설정된_물리적_이더넷_인터페이스

    bridge_fd 0

    bridge_maxwait 0

    bridge_stp off


# lo 인터페이스라던가, 그외 별도로 다른 인터페이스에 대해 설정해둔 것은 그대로 둘 것


(예) 서버에서 쓰는 물리적 이더넷 인터페이스 이름이 eno1이고 고정IP를 10.0.4.11/24로 쓸 경우,


auto eno1

iface eno1 inet manual


auto br0 

iface br0 inet static

    address 10.0.4.11

    netmask 255.255.255.0

    gateway 10.0.4.1

    dns-nameservers 8.8.8.8

    bridge_ports eno1

    bridge_fd 0

    bridge_maxwait 0

    bridge_stp off 



3. 서비스 재시작 또는 재부팅해서 설정 적용


$ sudo /etc/init.d/networking restart  또는 sudo service networking restart

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


아니면 그냥 깔끔하게 재부팅.



서버 쉘에서 ifconfig 쳤을 때, br0 인터페이스가 보이면서 고정IP주소가 제대로 설정되어 있고, HWaddr에 적힌 맥주소가 실제 물리적 이더넷 인터페이스와 똑같으면, 그리고 물리적 이더넷 인터페이스에는 아무 IP주소도 할당되어 있지 않으면 성공적으로 설정한 것이다.


혹시 재부팅 후에 SSH로 서버에 접근이 안되는 경우 (== 서버가 네트워크 연결을 못하는 경우), /etc/network/interfaces 파일에서 bridge_ports에 적힌 이름실제 물리적 이더넷 인터페이스 이름이 서로 맞지 않는지, 즉 오타가 없는지 먼저 점검할 것 (여기서 두 번 실수함. ㅠㅠ)

만약 물리적 인터페이스 이름을 정확히 매치하지 않으면, KVM (정확히 말하면 virt-manager GUI에서의 개별 VM 설정에서 네트워크 인터페이스 설정 창)에서는 br0이라는 이름 옆에 empty bridge라고 표시된다.





반응형
블로그 이미지

Bryan_

,
반응형

Host OS: Ubuntu 14.04.1 Desktop (amd64)

Host OS (이동 대상): Ubuntu 14.04 Server (amd64)

Guest OS: Windows 10 (64-bit)


개인 PC에서 개인용 윈도우10 VM 하나를 만들어서 KVM에서 돌리다가, PC의 디스크 속도가 받쳐주질 못해서 서버에 옮기기로 했다.


원래 개인 PC에서 VM을 쓰려고 했던 이유는 guest OS에 원격접속할 때 네트워크 지연 시간을 극단적으로 줄이려는 목적이었고, 실제로 지연 시간은 매우 적었지만 물리적인 하드디스크 1개에서 host OS (Ubuntu)와 guest OS (Windows 10)를 모두 써 보니 전체적인 속도가 느려지고 말았다. 안 그래도 디스크를 많이 쓰는 경향이 있는데 SSD도 아니라서 bottleneck이 되고 말았다. 그래서 같은 건물에 있어서 어차피 LAN의 범위 안에 있는 자원이 충분한 서버에 VM을 옮기기로 했다.


VirtualBox처럼 간단하게 이미지 파일만 복사하면 되는 것 같지는 않아서 찾아본 결과, 나와 같은 목적으로 VM을 다른 호스트 머신에 복사해서 성공한 사례가 있었다. [1]



정리하면:


1. clone 명령으로 옮길(==복사할) 이미지를 만든다. 사실은 새로 안 만들고 바로 옮겨도 될 것 같다. 

즉, 굳이 복사할 필요성을 못 느낀다면 원래 있던 VM 이름과 이미지 파일 위치, xml 파일 위치를 기억해 두고 바로 2번부터 시작한다.


# virt-clone --original=[원래 있던 VM 이름] --name=[새로 만들 VM 이름] -f [생성할 img 파일 위치] --mac [랜카드 맥주소]


예를 들어,

# virt-clone --original=testvm1 --name=newvm -f /var/lib/libvirt/images/skylit_newvm.img --mac 00:12:34:56:78:90



2. 기존 호스트 머신에서 방금 생성한 img 파일과 설정 파일(xml)을 새로운 호스트 머신에 옮긴다.

서로 네트워크로 연결돼 있다면 scp를 쓰는 게 제일 빠를 듯. 일반적으로 virt-manager에 의해서 생성되는 VM 이미지가 저장되는 위치는 /var/lib/libvirt/images/ 이다. (루트 권한으로만 접근 가능)그리고 xml파일은 /etc/libvirt/qemu/ 에 [새로 만든 VM 이름].xml 로 생성된다.


예를 들어, 아래 두 파일을 새로운 호스트 머신으로 옮긴다.

  • /var/lib/libvirt/images/newvm.img
  • /etc/libvirt/qemu/newvm.xml



3. 새로운 호스트 서버의 콘솔에서, virt-manager에서 인식할 수 있도록 새로 옮긴 VM 이미지를 추가한다.

$ virsh define /etc/libvirt/qemu/[옮겨온 VM 이름].xml



4. 이제 virt-manager를 실행하면 목록에 방금 옮겨온 VM 이름이 추가되어 있음을 확인할 수 있다.



<주의사항>


옮겨 가는 새로운 호스트 머신의 KVM 설정에 따라서 기존 호스트 머신에서 설정한 것이 작동하지 않을 수도 있다.

대표적으로 CPU 설정, 메모리 용량, display 설정 등이 있다. 


  • CPU는 가상 CPU로 특정 모델(e.g. Intel SandyBridge)을 지정해 두었는데 새로운 호스트 머신에서 해당 CPU 모델을 가상화하지 못할 수 있으므로, CPU 프로파일을 한번 확인해 볼 필요는 있다.
  • 메모리의 경우, [1] 에서도 언급되었듯이 물리적인 전체 메모리 용량을 넘어서는 등의 자원 할당 문제가 있는지 살펴봐야 한다.
  • Display의 경우, 필자는 기존 호스트 머신에서 SPICE 프로토콜을 썼는데 옮겨 가는 새로운 호스트 머신에 SPICE를 설치해 두지 않아서 virt-manager를 통해서는 화면을 볼 수 없었다. 하지만 네트워크 관련 설정에 문제가 없어서 원격 접속하는 데에는 문제가 없었다.




<참고자료>

[1] http://serverfault.com/questions/399835/clone-kvm-qemu-vm-to-a-different-server


반응형
블로그 이미지

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_

,