우리는 Xen에서 당신이 당신의 환경에서 Xen을 시도하고 테스트할 때 발생할 수 있는 몇 가지 일반적인 Xen 문제들에 대한 한 튜토리얼을 가졌습니다. 첫 번째 팁과 트릭 배치들은 디스플레이, 파이썬 버전과 모듈들, 래퍼 스크립트 변경과 명시적 명령어 실행, 서비스 트러블슈팅 문제들에 초점을 맞췄습니다.
오늘, 우리는 더 깊이 다이빙하고 당신이 마주쳤을 수도 있고 아닐 수도 있는 몇 가지 더 많은 문제들을 이해하고, 고치고, 우회하려고 시도합니다. 저는 일부 해결책들이 약간 애드혹일 수 있음을 인정해야 합니다, 그래서 내 말을 그대로 받아들이지 마세요, 하지만 저는 그것들이 전반적으로 잘 작동한다고 믿습니다. 희망적으로, 이 읽기 후에 당신의 Xen 경험은 더, 어, 선(禪)스러워질 것입니다.
팁 1: 하이퍼바이저 호스트에 대한 VNC 연결이 거부되거나 끊김
Virtual Machine Manager (virt-manager)를 시작한 후, 당신은 VNC를 사용하여 당신의 가상 머신들의 콘텐츠들을 볼 수 있는 옵션을 가집니다, 그것은 그 다음 관련 도메인의 콘솔 콘텐츠들을 표시할 것입니다. 이제 그리고 그때, 콘솔은 공백이 될 수 있고 위에 쓰여진 에러를 던질 수 있습니다. 질문, 지금 당신은 무엇을 합니까?
내 경험은 이것이 게스트 운영 체제가 재시작되거나 종료될 때마다 일어날 것임을 보여줍니다. 한 번 당신이 그것을 다시 켜면, 당신은 콘텐츠를 보기 위해 콘솔 창을 다시 여는 것으로 가장 불편하게 해야 할 것입니다. 동일한 것이 virt-viewer를 사용하면 발생합니다:
virt-viewer <domain>
도메인이 재부팅, 리셋, 또는 파워 오프되면, 당신은 연결을 잃을 것입니다. 현재로서는, 간단한 해결책은 콘솔 창을 다시 여는 것입니다, virt-manager 또는 virt-viewer를 통해.
대안적으로, 연결을 설정하기 위해:
virsh vncdisplay <domain>
vncviewer <hostname:port returned by virsh command>
팁 2: 게스트 실행 중 vif 사라짐, 더 이상 네트워킹 없음
당신의 가상 머신이 실행 중일 때 가상 네트워크 인터페이스, 정상적으로 vifX.X로 레이블된, ifconfig 목록에서 사라질 수 있습니다, 당신의 게스트를 쓸모없는 벽돌로 만듭니다.
이 문제는 또한 가상 머신 내부의 관련 네트워크 인터페이스 MAC 주소가 모든 제로들로 변하는 것으로 나타날 수 있습니다. 그리고 호스트(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 네트워킹 스택의 레이스 컨디션들을 고치는 것과 더 비슷합니다.
두 번째 옵션은 /etc/xen/xend-config.sxp에 위치한 Xen 구성 파일의 네트워크 설정들을 트윅해보려는 것입니다. 이 파일은 브리지와 가상 네트워크 인터페이스들을 어떻게 설정할지를 포함하여 모든 종류의 지시어들을 포함합니다. 많은 이들은 네트워킹이 다소 버그가 있고 당신이 당신의 자신의 스크립트들을 수동으로 구성해야 한다고 주장합니다.
특히, 다음 지시어들을 변경하세요:
(network-script network-bridge) to (network-script )
게다가, 당신은 당신의 브리지를 수동으로 구성해야 합니다. 테스트하는 동안, 당신은 brctl과 ifconfig 명령어들을 사용해야 하고, 일단 당신이 당신의 변경들이 견고하다고 확신하면, 당신은 그때 그것들을 당신의 네트워크 스크립트들에 영구적으로 커밋해야 합니다. 레드햇과 수세 시스템들에서, 이것은 ifcfg-br<number>를 생성하는 것과 당신의 네트워크 카드들에 대한 기존 네트워크 스크립트들을 /etc/sysconfig/network 아래에서 변경하는 것을 의미하고, 데비안-기반 시스템들에서, /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
다음 메뉴에, netloops의 수를 늘리거나 줄이는 것, 즉 얼마나 많은 가상 장치 쌍들이 생성될 수 있는지를 의미합니다. 만약 당신이 상한선에 부딪힌다면, 당신은 그 숫자를 늘리고 싶을 수 있습니다. 이것은 netloop라는 파일을 /etc/modprobe.d 아래에 생성하고 안에 쓰는 것에 의해 행해집니다:
option netloop nloopbacks=<some high number, e.g. 16, 32>
또는 그냥 이 옵션을 /etc/modprobe.conf에 추가하는 것.
이 주제에 대한 상당히 더 많은 읽기:
Xen 네트워킹
트러블슈팅 노트와 함께 설명된 Xen 네트워크 브리지들
Xen 아래 SLES 네트워킹, 트러블슈팅과 권장사항들
번거로움 없는 Xen 네트워킹
리눅스 네트워킹은 빨아들인다. XEN 네트워킹은 빨아들인다.
추가 Xen 가상 네트워크 브리지들 생성
만약 당신이 이것이 일어날 때 커널 크래시들을 마주친다면, 이 두 링크들도 다소 흥미로울 수 있습니다, 초-긱주의를 조심하세요:
Kernel BUG at mm/vmalloc.c:2165
[PATCH] mm: sync vmalloc address space page tables in alloc_vm_area()
이 문제는 실제로 netloops의 수를 제로로 줄임으로써 해결될 수 있습니다.
팁 3: 레거시 HTTP 접근 활성화
libvirt는 로컬과 원격으로 dom0에 연결하고 관리하는 것에 관해서 HTTP를 중복되게 만듭니다. 그러나, 당신들 중 일부는 이 옵션에 관심이 있을 수 있습니다, 특히 당신이 OpenXenManager 같은 도구들을 사용하려는 경우, 그것은 HTTP/HTTPS를 사용하여 연결합니다. 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: 'localhost:8000'에 연결할 수 없음: 연결 거부됨
위의 팁의 귀결은 당신이 virt-manager를 사용하여 dom0에 연결하려고 할 때 추한 연결 거부 에러를 얻을 수 있다는 것입니다. 파이썬은 장황함으로 악명이 높으니, 추함에 대비하세요.
이 문제를 해결하기 위해, 당신은 HTTP 접근을 활성화해야 할 수 있습니다. 대안적으로, 당신은 이 일이 처음에 왜 일어나는지 자문해야 합니다. 가장 가능성이 높은 이유는 Xen 서비스들 중 하나가 실행되고 있지 않아서, virt-manager가 레거시 접근으로 폴백하도록 강요하기 때문입니다. 만약 당신이 HTTP 프로토콜을 사용하고 싶지 않다면, 당신은 당신의 시스템이 모든 관련 Xen 서비스들, 특히 libvirtd와 xend와 함께 부팅하는지 확인하고 싶을 수 있습니다.
팁 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 커널 설정들을 사용하여 반가상화된 게스트를 켜려고 시도하면 일어날 수 있습니다. 디버그하고 해결하기에 꽤 사소합니다.
#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이 메이저 번호 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진수로 변환하고, 그 다음 마이너 번호를 위해 두 개의 최하위 비트들을 사용하고, 나머지 상위 비트들을 메이저 번호로 사용하고, 그 다음 온라인이나 /usr/src/linux/Documentation 아래에 있는 devices.txt 리스트를 참조하여 정확한 장치 타입을 해독하는 것입니다. 예를 들어, 768 데시멀은 x0300 헥사, 의미 메이저 번호 3, 마이너 번호 0. 이것은 첫 번째(제로) IDE 장치 또는 hda로 번역됩니다. 마찬가지로, 5632는 x1600으로 번역되어, 메이저, 마이너 16,00 조합을 의미하며, 블록 장치들에 대해 이것은 CD-ROM입니다. 꽤 훌륭하죠? 이 오래된 Xen 메일링 리스트 스레드도 흥미로울 수 있습니다.
팁 6: 고급 설정들
마지막으로, 무언가 가벼운 것. 당신의 게스트들을 부팅할 때, 당신은 일부 고급 설정들을 트윅하고 싶을 수 있습니다. 예를 들어, 당신은 PAE나 OpenGL에 관심이 있을 수 있습니다. 당신은 가상 머신 위자드에서 올바른 옵션들을 표시해야 합니다, 또는 대안적으로, 만약 당신이 명령줄과 가상 머신 파일들에 익숙하다면, 그냥 올바른 문자열들을 거기에 추가하세요.
마지막, 나열되지 않은 팁은 GRUB2가 담당하는 멀티-부트 시스템들을 설정하는 것입니다. 새로운 것 없음, 우리는 소개 기사에서 이것에 대해 이야기했습니다, 그래서 거기로 가서 한번 보세요.
그리고 우리는 오늘 여기서 끝낼 것입니다.
결론
저는 파이썬으로 쓰인 어떤 도구도 관리자들을 괴롭히고 짜증나게 하기 위해 가능한 한 많은 에러 장황함으로 설계되었다고 믿습니다. Xen은 이 범주에 속하며, 그것이 직면하고 있는 문제에 대해 꽤 풍부하고 우아하지 않은 메시지들을 가집니다. 사소하지 않은, 적어도.
여전히 희망적으로, 이 튜토리얼은 당신에게 어떤 쓸모가 있었습니다. 저는 여기에서 에러에 대한 꽤 많은 여지가 있음을 인정해야 합니다. 당신은 이 제안들을 적용해보려고 시도할 수 있고 비참하게 실패할 수 있습니다, 분노와 실망을 느끼며. 이것은 당신을 괴롭힐 수 있는 진정으로 수백 개의 다른 시나리오들이 있기 때문입니다, 각각은 아주 약간씩 다릅니다. 그럼에도 불구하고, 일부 팁들은 유용해야 합니다. VNC 단절들을 우회하는 방법, 네트워크 문제들을 조사하는 방법, 다양한 에러들과 구성 문제들, 그리고 더. 글쎄요 그게 다일 것입니다, 또 봐요.
치어스.
