리눅스(Ubuntu, Fedora 등)에서 VirtualBox와 같은 가상화 소프트웨어를 사용하다 보면, 가상 머신이 간헐적으로 버벅거리다가 호스트 시스템 전체가 응답하지 않는 현상을 겪을 수 있습니다. 필자는 VirtualBox 7.x와 Kubuntu 22.04 이후 환경에서 이 문제를 발견했으며, 상당한 트러블슈팅 끝에 근본 원인을 파악했습니다. 이 문제는 커널 버그, 스펙터(Spectre) 계열 취약점 완화 조치, 호스트와 하이퍼바이저 간의 충돌이 복합적으로 작용한 결과입니다.
문제의 구체적인 증상
증상은 의외로 단순합니다. 가상 머신을 시작하면 어느 시점부터 가상 머신이 응답하지 않습니다. 프로그램 아이콘 클릭처럼 사소한 동작만으로도 발생할 수 있죠. 동시에 호스트 데스크톱 역시 비정상적으로 동작합니다. 마우스 클릭에 반응하지 않거나, 일부 프로그램만 멈추고 다른 프로그램은 정상 작동하는 식입니다. 운이 좋으면 잠시 후 스스로 복구되지만, 그렇지 못한 경우 강제 재부팅 외에는 방법이 없습니다. 상당히 짜증 나는 문제입니다.
필자는 이 문제를 몇 달째 겪어 왔습니다. 역시 또 커널 문제입니다. 과거 타이탄(Titan) 노트북을 괴롭혔던 문제나, 지금도 Executive 노트북에 영향을 주고 있는 문제와 비슷한 부류입니다. 관심 있는 분들은 필자의 리눅스 섹션에서 관련 보고서들을 확인해 보시기 바랍니다.
이것을 커널 문제로 판단하는 이유는 다음과 같습니다. 문제는 Kubuntu 22.04와 VirtualBox 7.0을 사용하던 중 갑자기 시작되었고, Kubuntu 24.04와 VirtualBox 7.1로 넘어간 후에도 계속되고 있습니다. 범인을 VirtualBox로 지목할 수도 있지만, 그렇다면 필자가 밝혀낸 수많은 커널 버그들을 설명할 수 없습니다.
실제로 시스템 로그에는 다음과 같은 오류가 기록됩니다:
kernel: unchecked MSR access error: WRMSR to 0xd10 (tried to write 0x000000000000ffff) at rIP: 0xffffffff910c6be4 (native_write_msr+0x4/0x40)
kernel: Call Trace:
kernel: <TASK>
kernel: ? show_stack_regs+0x23/0x40
kernel: ? ex_handler_msr+0x10a/0x180
..."unchecked MSR access error: WRMSR"로 검색해 보면 openSUSE, Fedora, Rocky, Ubuntu, Proxmox 등 다양한 배포판과 관련된 수백 개의 스레드를 발견할 수 있습니다. 명백한 커널 문제이며, 이 문제들은 2019년까지 거슬러 올라가지만 대부분 아직까지도 해결되지 않은 상태입니다.
근본 원인
이 문제를 제대로 이해하려면 배후의 코드를 조금 알아야 합니다. 요약하면 다음과 같습니다. 커널에는 스펙터 같은 사이드 채널(side-channel) 공격에 대응하기 위한 다양한 완화(mitigation) 조치가 추가되어 있습니다. 그런데 이 완화 조치들이 커널의 스케줄링 및 코어 관리와, 유사한 작업을 수행하는 다른 서브시스템(예: 하이퍼바이저) 사이에 충돌을 일으킬 수 있습니다. 특히 반가상화(paravirtualization)와 중첩 페이징(nested paging)을 사용할 때 그렇습니다. 요컨대 완화 조치가 다소 공격적으로 작동해서 시스템이 얼거나 멈출 수 있는 것입니다.
덧붙이자면, 이런 커널 완화 조치들은 기업 환경에서는 100% 유효하지만 가정용으로는 0% 필요 없는 것들입니다. 그러나 리눅스 데스크톱은 기업용/서버용 커널 세계의 산물이기 때문에, 최종 사용자인 여러분이 집에서 기업용 문제를 고스란히 떠안아야 하는 것이죠.
해결 방법(워크어라운드)
이 문제의 발생 빈도를 줄일 수 있는 방법은 크게 세 가지입니다.
1. 가상 머신에 할당하는 CPU 코어 수 줄이기
8개처럼 많은 코어를 할당하고 있다면 1~2개, 혹은 4개로 줄여 보세요. 어느 정도 도움은 되지만 문제를 완전히 없애지는 못합니다.
2. 해당 가상 머신의 중첩 페이징(Nested Paging) 비활성화
성능 저하는 상당하지만, 적어도 가상 머신은 안정적으로 돌아가고 시스템이 멈추는 일은 없어집니다. VirtualBox라면 설정에서 시스템(System) > 가속(Acceleration)으로 이동한 뒤, "Enable Nested Paging(중첩 페이징 사용)" 체크박스를 해제하면 됩니다.
일반적으로 아래 옵션들을 조합해 보면서 자신에게 가장 잘 맞는 설정을 찾아볼 수 있습니다:
- 프로세서(Processor) > 확장 기능(Extended Features) > 중첩 VT-x/AMD-V 활성화(Enable Nested VT-x/AMD-V)
- 반가상화 인터페이스(Paravirtualization Interface) — 리눅스 기본값은 KVM
- 하드웨어 가상화(Hardware Virtualization) > 중첩 페이징 활성화(Enable Nested Paging)
3. 반가상화 비활성화
BIOS/UEFI에서 비활성화하면 머신 전체에 적용되고, KVM 하이퍼바이저용 설정 파일을 만들면 모든 가상 머신에 대해 중첩 페이징 사용을 막을 수 있습니다. /etc/modprobe.d 디렉터리에 CPU 아키텍처에 따라 kvm-intel.conf 또는 kvm-amd.conf라는 이름의 파일을 생성하고, 파일 안에 다음 내용을 추가합니다:
options kvm-intel nested=0 # 인텔 CPU의 경우
options kvm-amd nested=0 # AMD CPU의 경우하이퍼바이저 커널 모듈을 다시 로드하거나 재부팅하면 더 이상 MSR 오류를 만나지 않게 됩니다. 다만 이 방법은 권장하지 않습니다. 모든 가상화 워크로드에 속도 저하가 생기기 때문입니다. 차라리 필요에 따라 각 가상 머신별로 중첩 페이징 옵션을 켜고 끄는 편이 더 빠르고 효율적입니다. 물론 근본적인 해결은 커널 패치가 나와야겠죠.
맺음말
또 하나, 리눅스 데스크톱에 대한 신뢰를 깎아내리는 문제가 추가되었습니다. 이 시점에서 누적된 불편함은 거의 우스꽝스러울 지경입니다. 리눅스가 모듈화되고 유연하다는 건 좋지만, 데스크톱에서 굳이 클라우드의 '무단 거주자(guest tenant)'까지 신경 써야 할 이유는 없습니다. 기업들은 커널을 모든 시나리오에 대해 테스트해야 마땅합니다. 리눅스 데스크톱 QA가 농담 수준이라는 건 모두가 알지만, 커널이 뭔가를 한다면 최소한의 테스트라도 있어야 하지 않을까요?
필자는 이런 종류의 문제를 정말 싫어합니다. 몇 년씩 방치되고, 가정용과는 무관한 산탄총식 문제이며, 무의미한 회귀(regression)에 불과합니다. 일상적인 사용을 어렵게 만들고, 데스크톱 공간이 얼마나 지나치게 복잡한지, 그리고 본질적으로 이것이 진짜 데스크톱이 아니라는 점을 드러냅니다. 솔직히 말하면 GUI를 얹은 변형된 서버에 가정용 편의 기능을 살짝 얹은 정도죠. 참고로 앞으로 몇 주 안에 필자가 직접 나만의 작은 배포판을 만들어 이를 입증해 보일 예정입니다.
요약하면, 가상화를 실행하는 도중 시스템이 멈춘다면 로그를 확인하고 위의 워크어라운드를 시도해 보세요. 문제가 수정될 때까지 말이죠. 물론 그날이 영영 오지 않을 수도 있습니다.
즐거운 리눅스 되세요!