앞서 Xen 환경 구축 시 자주 마주치는 문제를 다룬 트러블슈팅 기사 두 편을 소개한 적이 있습니다. 이번에는 같은 주제로 KVM의 일반적인 문제 해결법을 정리해 보겠습니다.
개인적으로 KVM은 오류 메시지의 장황함이나 전반적인 복잡도 면에서 Xen보다 훨씬 깔끔하다고 생각합니다. 그럼에도 불구하고 작업을 어렵게 만드는 성가신 오류를 만나는 경우는 언제든 있을 수 있습니다. 이 글에서는 이러한 오류를 우회하는 방법, 설정 충돌을 진단하는 요령, 그리고 실무에 바로 쓸 수 있는 다양한 팁을 소개합니다.
팁 1: 브리지 네트워크 인터페이스가 목록에 나타나지 않을 때
직접 만든 브리지 장치(예: br0)를 사용하려고 하는데, Virtual Machine Manager의 드롭다운 메뉴에서 해당 인터페이스가 보이지 않는 경우가 있습니다. 아래 이미지는 반대 상황을 보여주지만, 원하는 장치가 사용 가능한 어댑터 목록에 없다고 상상해 보시기 바랍니다. 실제로 종종 발생하는 문제입니다.
해결책은 매우 간단합니다. 해당 도메인(가상 머신)의 설정 파일을 직접 수정하는 것입니다. KVM은 기본적으로 /etc/kvm/vm 또는 /etc/libvirt/qemu 두 위치에 파일을 저장하므로, XML 파일은 대부분 이곳에서 찾을 수 있습니다. 관련 파일을 열어 <source bridge> 항목의 브리지 어댑터 정보를 수동으로 변경한 뒤, 파일을 닫고 가상 머신을 시작하면 됩니다.
<interface type='bridge'>
<source bridge='br0'/>
<mac address='52:54:00:0d:e6:4a'/>
</interface>
팁 2: biosdevname으로 인한 네트워크 문제
biosdevname은 BIOS가 제공하는 이름을 장치에 부여하여, 하드웨어 관리의 일관성을 유지하고 논리를 단순화해 주는 유틸리티입니다. 특히 네트워크 장치가 많고 각각 고유한 기능을 가진 엔터프라이즈 환경에서는 ethX 같은 일반적인 이름보다 고유한 문자열로 1Gbps와 10Gbps 어댑터 등을 쉽게 구분할 수 있어 유용합니다. 물론 가정용 시스템에서는 이런 고민을 겪을 일이 거의 없습니다.
그러나 biosdevname의 부작용으로, KVM으로 만든 가상 머신의 게스트 OS 내부에서 이 유틸리티가 실행되면 네트워크가 잡히지 않는 문제가 생길 수 있습니다. 가상화된 장치에 물리적 장치와 맞지 않는 이름이 부여되기 때문입니다.
이 문제를 우회하는 방법은 여러 가지가 있습니다. 첫째, 일부 버전의 유틸리티는 가상 환경 안에서 호출되고 있다는 사실을 감지하여 아무 변경 없이 종료됩니다. 둘째, GRUB 메뉴에서 커널 인자로 biosdevname=0을 전달하면 유틸리티 실행 자체를 비활성화할 수 있습니다.
세 번째 방법은 네트워크 카드에 이름을 부여하는 udev 규칙을 직접 수정하는 것입니다. 아래는 매우 기초적인 예시로, 네트워크 어댑터가 하나인 머신을 기준으로 작성되었습니다. 카드가 여러 개라면 더 유연한 로직이 필요하며, 주석 처리된 설명대로 규칙마다 별도의 줄을 추가해야 합니다.
수동으로 수정하여 클래식한 이름 할당 방식으로 되돌릴 수 있습니다:
vi /etc/udev/rules.d/70-persistent-net.rules
NAME 값을 "eth_biosname"에서 "ethX" 또는 원하는 이름으로 교체합니다:
# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth_biosname"
# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth0"
가상 머신에서 사용하는 가상 하드웨어에 따라 규칙 내용이 달라집니다. 예를 들어 Realtek, e1000, virtio 등 어떤 가상 NIC를 선택했느냐에 따라 문자열이 달라지므로, 반드시 자신의 환경에 맞는 해결책을 적용하시기 바랍니다.
팁 3: 도메인이 이미 존재한다는 오류
새 도메인을 정의(define)하려는데 이미 존재한다는 오류가 나오지만, 정작 설정 파일이나 선언 위치를 찾지 못하는 경우가 있습니다. virsh list에는 없고 virt-manager 어디에도 표시되지 않는다면 어떻게 해야 할까요?
virsh define machine.xml
error: Failed to define domain from machine.xml
error: operation failed: domain 'machine' already exists
with uuid 883ab02f-1a67-7430-ef9a-2b59af52210e7
설정 파일을 찾아 삭제한 후 libvirtd 서비스를 재시작하면 됩니다.
updatedb
locate machine.xml
rm <machine.xml의 전체 경로>
/etc/init.d/libvirtd restart
팁 4: 내부 오류 - cgroup을 찾을 수 없음
이 문제는 위 예시처럼 libvirtd 재시작 후에 나타날 수도 있고, 전혀 무관한 상황에서 발생하기도 합니다. 전체 오류 메시지는 대체로 다음과 같습니다:
virsh create machine.xml
error: Failed to create domain from machine.xml
error: internal error Unable to find cgroup for machine
Bugzilla 보고서에 언급된 것처럼 systemd와 관련된 원인일 수 있지만, systemd를 사용하지 않는 순정 시스템에서도 발생할 수 있습니다. 대부분의 경우 cgroups와 libvirtd 사이의 비우호적인 경합(race condition) 때문입니다. 즉, libvirtd 서비스가 cgroups보다 먼저 올라오거나, cgroup 중 하나가 삭제되었거나 애초에 존재하지 않았던 것이 원인입니다.
libvirtd 설정 파일인 /etc/libvirt/qemu.conf를 편집하여 해결할 수 있습니다. 이 파일에서 cgroups_controllers 지시문을 수정해 어떤 cgroup도 나열하지 않도록 하면, libvirtd가 cgroup 없이 실행될 수 있습니다.
cgroups_controllers = [ ]
이후 libvirtd를 다시 재시작해야 합니다. 대안으로, 필요한 cgroup을 수동으로 생성하고 libvirtd 프로세스를 해당 서브시스템에 할당하는 방법도 있습니다.
팁 5: 종료/재부팅 시 VMM에서 가상 머신이 사라지는 문제
사실 이 문제는 매우 단순할 수 있습니다. 가상 머신을 종료하거나 재부팅하면 가상 머신 콘솔이 닫혀버리는 현상입니다. 설정 자체는 멀쩡하지만, 머신 관리 흐름에 매번 개입해야 하므로 상당히 번거롭습니다.
해당 가상 머신의 XML 파일에서 on_reboot 절을 찾아, 동작이 destroy가 아닌 restart로 설정되어 있는지 확인하면 됩니다. 이것이 전부입니다.
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
팁 6: 재부팅 동작 없음 - 기능이 지원되지 않음
역시 앞선 팁과 밀접하게 관련된 내용입니다. restart 대신 reboot을 지정하면 KVM이 실행할 수 없는 잘못된 명령이라는 사실을 알게 됩니다. 이때 꽤 눈에 띄는 오류 메시지를 보게 됩니다:
libvirtError: this function is not supported by the hypervisor: virDomainReboot
restart를 사용하면 모든 것이 정상적으로 동작합니다.
팁 7: 설치 후 부트로더 오류
외부 미디어(CD/DVD 등)로 설치를 마친 후 첫 재부팅에서 GRUB 오류, 아마도 15번 오류를 볼 수 있습니다. ISO 이미지를 가상 머신에 연결한 채로 두고, XML 파일에서 CD/DVD를 첫 번째 부팅 장치로 지정한 경우 발생합니다. 이는 일부 리눅스 배포판에 영향을 주는 VirtualBox의 유사한 버그와 비슷한 문제입니다. 예시는 다음과 같습니다:
root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz
Error 15: File not found
Press any key to continue...
ISO 이미지를 마운트 해제(unmount)하고 게스트를 재부팅하면 해결됩니다. 이번에는 정상적으로 부팅될 것입니다. 참고로 하드 디스크를 첫 번째 부팅 장치로 설정하면 이 문제가 발생하지 않습니다. KVM은 디스크에서 유효한 파티션 테이블을 찾지 못하면 자동으로 두 번째 부팅 소스(PXE 또는 CD/DVD)로 넘어가기 때문입니다. 지금 막 설치 중인 단계라면 디스크에 파티션 테이블이 없는 것이 당연하니 말입니다.
오늘은 여기까지입니다.
추천 읽을거리
KVM 관련 추가 아티클도 확인해 보세요:
KVM 스토리지 및 네트워크 가이드, 브리지 네트워킹 설정
KVM + VirtualBox 함께 사용하기 하우투
KVM 클론(복제) 가이드
마무리
첫 트러블슈팅 가이드로 여섯 가지 남짓한 팁이면 나쁘지 않은 분량이라고 생각합니다. 이 튜토리얼은 브리지 네트워킹 설정, biosdevname 우회, cgroups + libvirtd 문제 해결, virt-manager가 자동 생성한 중복 도메인 제거, 그리고 게스트 OS 재부팅 문제 해결에 초점을 맞췄습니다.
대부분의 작업은 설정 파일 편집과 서비스 재시작으로 처리됩니다. GUI에 의존하지 않는 이유는, 명령줄로 변환 가능한 모든 작업은 스크립트로 만들어 더 쉽고 완전히 자동화된 관리가 가능하기 때문입니다. 이 글이 도움이 되었기를 바라며, 후속편에 대한 아이디어가 있다면 언제든 알려주세요.
감사합니다.