이전 글에서는 Xen 환경을 테스트할 때 흔히 발생하는 몇 가지 문제를 다뤘습니다. 첫 번째 시리즈에서는 화면 표시 문제, Python 버전과 모듈 관련 이슈, 래퍼(wrapper) 스크립트 변경 및 명령어 직접 실행, 서비스 문제 해결 방법 등을 소개했습니다.
이번 글에서는 한 단계 더 깊이 들어가, 여러분이 경험했을 수도 있고 아닐 수도 있는 추가적인 문제들을 진단하고 수정하며 우회하는 방법을 살펴보겠습니다. 솔직히 일부 해결책은 다소 임시방편적일 수 있으니 무조건적으로 믿지는 말아 주세요. 하지만 전반적으로 잘 작동한다고 확신합니다. 이 글을 읽고 나면 여러분의 Xen 사용 경험이 좀 더 '선(禪)'스러워지기를 바랍니다.
팁 1: 하이퍼바이저 호스트에 대한 VNC 연결이 거부되거나 끊기는 문제
Virtual Machine Manager(virt-manager)를 시작한 후에는 VNC를 통해 가상 머신 내용을 확인할 수 있으며, 해당 도메인 콘솔의 내용이 화면에 표시됩니다. 그런데 가끔 콘솔이 갑자기 빈 화면으로 바뀌면서 제목에 언급된 오류가 나타나는 경우가 있습니다. 그렇다면 어떻게 해야 할까요?
제 경험상 이 문제는 게스트 운영체제를 재시작하거나 종료할 때마다 발생합니다. 다시 전원을 켠 후에는 불편하게도 콘솔을 다시 열어 내용을 확인해야 합니다. virt-viewer를 사용할 때도 마찬가지입니다:
virt-viewer <domain>
도메인이 재부팅, 리셋 또는 전원 차단되면 연결이 끊어집니다. 현재로서는 virt-manager나 virt-viewer를 통해 콘솔 창을 다시 여는 것이 가장 간단한 해결 방법입니다.
또는 다음과 같이 직접 연결을 설정할 수 있습니다:
virsh vncdisplay <domain>
vncviewer <virsh 명령어가 반환한 호스트명:포트>
팁 2: 게스트 구동 중 vif 인터페이스 사라짐, 네트워크 두절
가상 머신이 실행 중인데 가상 네트워크 인터페이스(일반적으로 vifX.X로 명명됨)가 ifconfig 목록에서 사라져 게스트가 무용지물이 되는 경우가 발생할 수 있습니다.
이 문제는 가상 머신 내부의 해당 네트워크 인터페이스 MAC 주소가 모두 0으로 바뀌는 현상으로도 나타날 수 있습니다. 호스트(dom0)에서는 /var/log/messages에 다음과 같은 항목이 기록될 수 있습니다:
kernel: [ 109.743854] br0: port 2(vif1.0) entering learning state
kernel: [ 109.811880] br0: port 3(tap1.0) entering learning state
kernel: [ 117.369189] br0: port 3(tap1.0) entering disabled state
kernel: [ 117.398076] device tap1.0 left promiscuous mode
kernel: [ 117.398083] br0: port 3(tap1.0) entering disabled state
kernel: [ 117.815006] br0: port 2(vif1.0) entering disabled state
kernel: [ 117.850075] br0: port 2(vif1.0) entering disabled state
그렇다면 이런 문제를 어떻게 해결해야 할까요? 몇 가지 방법이 있습니다. 첫째, 커널 업그레이드입니다. 신기하게도 문제가 해결될 수 있는데, 사실 신비로운 것이 아니라 Xen 네트워킹 스택의 경쟁 상태(race condition) 버그를 수정하는 것이므로 당연한 결과입니다.
두 번째 방법은 /etc/xen/xend-config.sxp에 위치한 Xen 설정 파일에서 네트워크 설정을 조정하는 것입니다. 이 파일에는 브리지와 가상 네트워크 인터페이스 설정 방법을 포함한 다양한 지시문이 들어 있습니다. 많은 사용자들이 Xen 네트워킹이 다소 버그투성이라며 직접 자체 스크립트를 구성해야 한다고 말합니다.
특히 다음 지시문을 변경하세요:
(network-script network-bridge) → (network-script )
또한 브리지를 직접 수동으로 구성해야 합니다. 테스트 중에는 brctl과 ifconfig 명령어를 사용하고, 변경 사항이 안정적이라는 확신이 들면 영구적으로 네트워크 스크립트에 반영해야 합니다. RedHat과 SUSE 계열 시스템에서는 ifcfg-br<number> 파일을 생성하고 /etc/sysconfig/network 아래의 기존 NIC 네트워크 스크립트를 수정하면 되며, Debian 계열 시스템에서는 /etc/interfaces 설정 파일을 편집합니다. 물론 백업은 필수입니다.
다음은 수동 브리지 구성 예시입니다:
brctl addbr br0
brctl setfd br0 0
ifconfig br0 10.0.0.128 up netmask 255.255.255.0
brctl addif br0 eth0
route add -net default gw 10.0.0.254 br0
ifconfig eth0 0.0.0.0 up
다음으로 살펴볼 것은 netloop 수 늘리기 또는 줄이기입니다. 이는 생성 가능한 가상 장치 쌍의 개수를 의미합니다. 상한에 도달했다면 개수를 늘려야 할 수 있습니다. 이는 /etc/modprobe.d 아래에 netloop이라는 파일을 만들고 다음 내용을 작성하면 됩니다:
option netloop nloopbacks=<충분히 큰 숫자, 예: 16, 32>
또는 이 옵션을 /etc/modprobe.conf에 추가하기만 해도 됩니다.
이 주제에 대한 추가 참고 자료:
Xen networking
Xen network bridges explained with troubleshooting notes
SLES networking under xen, troubleshooting and recommendations
Hassle-free Xen networking
Linux networking sucks. XEN networking sucks.
Creating additional Xen virtual network bridges
만약 이런 상황에서 커널 크래시가 발생한다면 다음 두 링크도 도움이 될 수 있습니다. 극도로 기술적인 내용이니 주의하세요:
Kernel BUG at mm/vmalloc.c:2165
[PATCH] mm: sync vmalloc address space page tables in alloc_vm_area()
흥미롭게도 netloop 수를 0으로 줄이면 문제가 실제로 해결될 수 있습니다.
팁 3: 레거시 HTTP 접근 활성화
libvirt는 dom0에 로컬 및 원격으로 연결하고 관리하는 데 있어 HTTP를 불필요하게 만들었습니다. 하지만 HTTP/HTTPS로 연결하는 OpenXenManager 같은 도구를 사용하려는 분들에게는 이 옵션이 유용할 수 있습니다. 웹에서 Xen에 접근 가능하도록 하려면 xend-config.sxp 설정 파일에서 몇 가지 지시문을 편집해야 합니다:
(xend-http-server yes)
(xend-port 8000)
(xend-address '')
xend-http-server 값을 no에서 yes로 변경하고 올바른 포트를 지정하세요. xend-address는 Xend가 리슨할 네트워크 인터페이스의 IP 주소를 지정합니다. 기본값인 빈 따옴표로 두면 모든 사용 가능한 인터페이스에서 리슨합니다. 그다음 설정 파일을 다시 로드합니다:
/etc/init.d/xend reload
이후 웹 접근을 테스트할 수 있습니다.
팁 4: ERROR: unable to connect to 'localhost:8000': Connection refused
위 팁의 연장선으로, virt-manager를 사용해 dom0에 연결하려 할 때 지저분한 'connection refused' 오류를 만날 수 있습니다. Python은 장황한 출력으로 악명이 높으니 보기 흉함을 각오하세요.
이 문제를 해결하려면 HTTP 접근을 활성화해야 할 수 있습니다. 또는 애초에 왜 이런 일이 발생하는지 스스로 생각해 볼 필요가 있습니다. 가장 유력한 원인은 Xen 서비스 중 하나가 실행되지 않아 virt-manager가 레거시 접근 방식으로 폴백(fallback)하는 것입니다. HTTP 프로토콜을 사용하지 않으려면 시스템 부팅 시 libvirtd와 xend를 포함한 모든 관련 Xen 서비스가 함께 시작되도록 확인해야 합니다.
팁 5: domU 시작 오류
xm create <domain> 또는 xm start <domain> 명령으로 도메인을 구동하려 할 때 여러 오류 메시지를 만나 답답하거나 혼란스러울 수 있습니다. 몇 가지 사례를 분석해 문제의 원인을 파악해 보겠습니다.
#xm start test1
Error: Domain unable to be unpaused: an integer is required
Usage: xm start <DomainName>
그래픽 환경에서도 동일한 오류가 나타납니다.
이는 일반적으로 네트워크 카드나 사운드 카드처럼 존재하지 않거나 지원되지 않는 하드웨어 구성 요소를 지정했음을 의미합니다. 도메인 설정 파일(대개 /etc/xen/vm에 저장됨)에 오류가 없는지 검토하세요. /var/log/messages와 Xen 오류 로그인 /var/log/xen/xend.log도 확인해 보는 것이 좋습니다.
다음 사례를 보겠습니다:
#xm create test1
Using config file "./test1".
Error: (2, 'Invalid kernel', "elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest' section found.\n")
이 오류는 도메인 설정 파일에서 HVM 커널 설정으로 반가상화(paravirtualized) 게스트를 구동하려 할 때 발생할 수 있습니다. 디버깅과 해결이 비교적 간단합니다.
#xm create test1
Using config file "./test1".
Error: Device 768 (vbd) could not be connected.
File /tmp/disk.raw is loopback-mounted through /dev/loop1,
which is mounted in a guest domain,
and so cannot be mounted now.
이 오류는 다른 가상 머신이 이미 사용 중인 하드디스크 파일을 재사용하려 할 때 발생할 수 있습니다. 또는 내용을 검사하기 위해 어딘가에 루프백 장치로 마운트했을 수도 있습니다.
vbd 오류 얘기가 나온 김에 또 하나의 사례를 보겠습니다:
#xm create test1
Using config file "./test1".
Error: Device 5632 (vbd) could not be connected. Device not found.
xend.log에 표시되는 유사한 메시지 변형은 다음과 같습니다:
DEBUG (DevController:139) Waiting for devices vscsi.
DEBUG (DevController:139) Waiting for devices vbd.
DEBUG (DevController:144) Waiting for 768.
WARNING (XendDomain:1076) Failed to setup devices for <domain id=None name=test1 memory=4294967296 state=halted>: Device 768 (vbd) could not be connected. Device not found.
원인은 하드디스크 파일이 잘못 지정되었거나, 아마도 오타 때문에 장치를 잘못 사용한 경우일 수 있습니다. 위에 나열된 첫 번째 오류와 유사한 유형입니다.
여기서 생길 수 있는 질문은 'vbd가 어떤 종류의 장치인지 어떻게 알 수 있는가'입니다. 가장 간단한 우회 방법은 부팅된 Xen domU 중 하나에서 확인하는 것입니다. 모든 장치는 /sys/devices/xen/ 아래에서 찾을 수 있습니다. 예를 들면:
#cat /sys/devices/xen/vbd-768/block/hda/hda1/dev
3:1
여기서 vbd-768이 메이저(major) 번호 3을 가진 블록 장치임을 알 수 있습니다. 따라서 hda1은 3:1에 해당하며 논리적으로 타당합니다. 이 명명 규칙에 대한 자세한 내용은 잠시 후 설명하겠습니다.
특정 가상 머신의 전체 목록은 다음과 같습니다:
#ll
total 0
drwxr-xr-x 2 root root 0 Dec 18 12:07 power
-rw-r--r-- 1 root root 4096 Dec 18 12:07 uevent
drwxr-xr-x 4 root root 0 Dec 18 12:05 vbd-5632
drwxr-xr-x 4 root root 0 Dec 18 12:05 vbd-768
drwxr-xr-x 3 root root 0 Dec 18 12:05 vfb-0
drwxr-xr-x 4 root root 0 Dec 18 12:05 vif-0
더 복잡한 방법은 숫자를 16진수로 변환한 후, 하위 2비트는 마이너(minor) 번호로, 나머지 상위 비트는 메이저 번호로 해석하여, 온라인 또는 /usr/src/linux/Documentation 아래의 devices.txt 목록을 참조해 정확한 장치 유형을 파악하는 것입니다. 예를 들어, 10진수 768은 16진수 x0300이므로 메이저 번호 3, 마이너 번호 0을 의미합니다. 이는 첫 번째(zero) IDE 장치, 즉 hda에 해당합니다. 마찬가지로 5632는 x1600으로, 메이저·마이너 조합이 16,00이며 블록 장치 기준으로 CD-ROM을 의미합니다. 꽤 재미있지 않나요? 이 오래된 Xen 메일링 리스트 스레드도 참고할 만합니다.
팁 6: 고급 설정
마지막으로 가벼운 주제 하나를 다루겠습니다. 게스트를 부팅할 때 고급 설정을 일부 조정하고 싶을 수 있습니다. 예를 들어 PAE나 OpenGL이 관심사일 수 있습니다. 가상 머신 마법사에서 올바른 옵션에 체크하거나, 명령줄과 가상 머신 설정 파일에 익숙하다면 직접 해당 문자열을 추가하면 됩니다.
마지막으로 목록에 없던 팁은 GRUB2로 멀티부트 시스템을 구성하는 것입니다. 새로운 내용은 아니며, 소개 글에서 이미 다루었으니 해당 글을 참고하세요.
오늘은 여기까지 하겠습니다.
마무리
Python으로 작성된 도구는 관리자를 골탕 먹이고 짜증나게 하려는 듯 최대한 장황한 오류 메시지를 출력하도록 설계된 것 같습니다. Xen도 이 범주에 속하며, 직면한 문제에 대해 상당히 방대하고 세련되지 못한 메시지를 출력합니다. 적어도 결코 사소한 문제가 아닙니다.
그럼에도 불구하고 이 튜토리얼이 도움이 되었기를 바랍니다. 솔직히 말씀드리면 여기에는 오류 가능성이相当히 많습니다. 이 제안들을 적용해 보았지만 참담하게 실패하고 분노와 실망을 느낄 수도 있습니다. 실제로 수백 가지 서로 미묘하게 다른 시나리오가 존재하기 때문입니다. 그럼에도 불구하고 일부 팁은 분명 유용할 것입니다. VNC 연결 끊김 우회 방법, 네트워크 문제 조사 방법, 다양한 오류와 설정 문제 해결 방법 등이 그것입니다. 이것으로 마치겠습니다. 다음에 또 만나요.
감사합니다.