Linux, VirtualBox 정지, 확인되지 않은 MSR 오류
업데이트 날짜:2025년 11월 28일
이상한 최신 기사에 오신 것을 환영합니다. 즉, Ubuntu나 Fedora 등 Linux를 사용합니다. 일종의 가상화 제품을 사용하고 있습니다. 제 경우에는 VirtualBox이지만 이 문제는 다양한 하이퍼바이저에 적용됩니다. 가상 머신을 시작하면 가끔 끊김 현상이 발생합니다. 그 과정에서 전체 시스템(호스트)이 응답하지 않게 됩니다. VirtualBox 7.X 이상, Kubuntu 22.04 이상에서 이 문제를 발견했습니다.
문제를 해결하는 데 많은 시간이 걸렸지만, 마침내 근본 원인을 알아낸 것 같습니다. 공교롭게도 이것은 커널 버그, Spectre 제품군 완화, 호스트-하이퍼바이저 충돌 등의 조합으로 인해 발생하는 또 다른 무의미한 문제 슬래시 버그입니다. 즉, 일반 사람들이 Linux 데스크톱을 진지하게 사용하는 것을 방해해야 하는 또 다른 문제입니다. 하지만 적어도 나처럼 그것을 작동시키려고 노력하는 재미있는 캐릭터가 있습니다. 그러니 원하신다면 이 튜토리얼을 살펴보세요. 나 이후에.
자세한 문제
매우 간단합니다. 원하는 가상화 제품에서 가상 머신을 시작합니다. 어느 시점에서 가상 머신이 응답하지 않게 됩니다. 프로그램 아이콘을 클릭하는 것만큼 간단한 것일 수도 있습니다. 그런 다음 자신의 호스트 데스크탑이 올바르게 작동하지 않는다는 사실도 알게 됩니다. 더 이상 마우스 클릭에 응답하지 않거나 특정 프로그램은 다른 프로그램이 응답하는 동안 응답하지 않습니다. "문제"가 저절로 해결되는 경우도 있고 그렇지 않은 경우도 있으므로 시스템을 하드 부팅해야 합니다. 정말 짜증나네요.
나는 몇 달 동안 이 문제에 직면해 있었습니다. 물론 그것은 또 다른 커널 문제일 것입니다. 아마도 내 타이탄이 한동안 오작동하게 만든 유사하고 쓸모없는 작물이거나 여전히 내 경영진에 영향을 미치는 문제일 것입니다. 관심 있으신 분들을 위해 4차 보고서와 6차 보고서를 각각 연결해 두었습니다. 이 두 노트북에 대해 더 많은 기사가 있으므로 원하시면 내 Linux 섹션을 확인하세요(6번째 및 10번째 보고서).
왜 커널 문제라고 생각합니까? 글쎄요, 제가 아직 Kubuntu 22.04와 VirtualBox 7.0을 사용하고 있는 동안 갑자기 시작되었기 때문입니다. Kubuntu 24.04 및 VirtualBox 7.1에서 계속됩니다. 범인이 VirtualBox라고 말할 수도 있지만 그것만으로는 제가 발견한 수많은 커널 버그를 설명할 수 없습니다.
즉, 내 시스템 로그에 다음과 같은 어리석은 오류가 있습니다:
커널:확인되지 않은 MSR 액세스 오류:WRMSR에서 0xd10(0x00000000000을 쓰려고 시도함)
0ffff) rIP:0xffffffff910c6be4 (native_write_msr+0x4/0x40)
커널:호출 추적:
커널:<작업>
커널:? show_stack_regs+0x23/0x40
커널:? ex_handler_msr+0x10a/0x180
...
그리고 "확인되지 않은 MSR 액세스 오류:WRMSR"을 검색하면 openSUSE, Fedora, Rocky, Ubuntu, Proxmox 등과 관련된 수백 개의 스레드를 발견할 수 있습니다. 그것은 커널 문제이며 문제는 2019년까지 거슬러 올라가며 대부분은 해결되지 않았습니다. 분더바.
간단히 말해서 이면의 코드를 조금 이해해야 하기 때문에 다음과 같이 요약됩니다. 커널에 추가된 다양한 완화(부채널 공격 등에 대한)로 인해 특히 반가상화 및 중첩 페이징을 사용하는 경우 커널 스케줄링 및 코어 관리와 하이퍼바이저와 같이 유사한 작업을 수행하는 하위 시스템 간에 충돌이 있거나 충돌이 발생할 수 있습니다. 간단히 말해서 완화 조치는 다소 공격적일 수 있으며 이로 인해 시스템이 정지되거나 중단될 수 있습니다.
또한 참고로 이러한 커널 완화는 모두 기업용으로 100% 관련성이 있고 가정용으로는 0% 관련성이 있습니다. 그러나 Linux 데스크탑은 엔터프라이즈/기업 커널 세계의 우연의 일치이므로 최종 사용자인 귀하는 가정용 시스템에서 엔터프라이즈 문제를 겪어야 합니다.
해결 방법
이 문제의 발생률을 줄일 수 있는 세 가지 방법이 있습니다.
가상 머신에 할당된 CPU 코어 수 줄이기
8과 같은 것을 사용하는 경우 1-2, 어쩌면 4를 시도해 보십시오. 도움이 될 수는 있지만 문제가 제거되지는 않습니다.
영향을 받는 가상 머신에 대해 중첩 페이징 비활성화
이로 인해 상당한 성능 저하가 발생하지만 최소한 시스템은 제대로 작동하고 시스템이 중단되지 않습니다. 예를 들어 VirtualBox에서 시스템> 가속으로 이동한 다음 여기에서 중첩 페이징 활성화 상자를 선택 취소하세요.
일반적으로 시도해 볼 수 있는 옵션이 몇 가지 있으며 어떤 순열이 가장 효과적인지 확인하세요.
- 프로세서> 확장 기능> 중첩된 VT-x/AMD-V 활성화
- 반가상화 인터페이스(Linux 기본값은 KVM).
- 하드웨어 가상화> 중첩 페이징 활성화
반가상화 비활성화(중첩 페이징)
이는 전체 시스템에서 이를 비활성화하는 BIOS/UEFI를 통해 수행할 수 있습니다. 또는 KVM 하이퍼바이저에 대한 구성 파일을 생성하여 모든 가상 시스템에 대한 중첩 페이징 사용을 방지할 수 있습니다. /etc/modprobe.d에서 프로세서 아키텍처에 따라 kvm-intel.conf 또는 kvm-amd.conf라는 제목의 파일을 만듭니다. 이 파일 안에 다음을 추가하세요:
옵션 kvm-[amd|intel]nested=0
하이퍼바이저 커널 모듈을 다시 로드(또는 재부팅)한 후에는 이제 MSR이 없는 환경을 갖게 됩니다. 그러나 이 방법을 사용하면 모든 가상화 작업 부하에 속도 저하가 발생하므로 권장하지 않습니다. 필요에 따라 각 가상 머신의 중첩 페이지 옵션을 선택 해제하거나 적절한 커널 패치로 이 문제가 완전히 해결될 때까지 필요에 따라 옵션을 활성화/비활성화하는 것이 더 빠르고 좋습니다.
결론
됐어요. Linux 데스크탑에 대한 나의 자신감을 떨어뜨리는 또 다른 작은 문제입니다. 이쯤 되면 누적된 처벌이 우스꽝스러워진다. Linux가 모듈식이고 유연하다는 것은 매우 좋은 일입니다. 그런데 왜 내 빌어먹을 데스크탑의 클라우드에 있는 "악성" 게스트 테넌트에 관심을 가져야 합니까? 나는 상관하지 않는다. 그리고 나는 기업들이 비즈니스 세계뿐만 아니라 모든 시나리오에 대해 커널을 테스트할 것으로 기대합니다. 우리 모두는 Linux 데스크톱 QA가 농담이라는 것을 알고 있지만, 커널이 어떤 일을 한다면 최소한 어느 정도의 테스트는 있어야 합니다.
나는 이런 성격의 문제를 정말 싫어합니다. 수년 동안 확인되지 않은 상태로 유지됩니다. 이는 가정용으로는 관련성이 없는 산탄총 폭발 유형의 문제입니다. 문제는 무의미한 회귀를 나타냅니다. 일상적인 사용을 어렵게 만듭니다. 그리고 데스크탑 공간이 얼마나 지나치게 복잡한지, 그리고 본질적으로 데스크탑 공간이 아니라는 점을 강조합니다. 기껏해야 GUI와 가정용이라고 해야 할 몇 가지 작은 특혜를 갖춘 형편없는 서버를 사용하고 있을 뿐입니다. 사실, 앞으로 몇 주 안에 나는 내 자신의 작은 배포판을 조립하여 이를 실제로 시연할 것입니다. 예. 거친 느낌은 일반 사람들이 보기에 편안하고 좋은 제품이 아니라는 사실에서 비롯됩니다. 어쨌든, 가상화를 실행하는 동안 시스템이 정지되면 로그를 확인하고 위에 나열된 해결 방법을 시도해 보세요. 문제가 해결될 때까지는 결코 해결되지 않을 수도 있습니다. 안녕히 계세요.
건배.