Linux, VirtualBox bị treo, lỗi MSR không được kiểm tra
Cập nhật:ngày 28 tháng 11 năm 2025
Chào mừng đến với phần kỳ lạ mới nhất của tôi. Nói một cách hóm hỉnh, bạn sử dụng Linux, chẳng hạn như Ubuntu hoặc Fedora hoặc những thứ tương tự. Bạn sử dụng một loại sản phẩm ảo hóa nào đó. Trong trường hợp của tôi là VirtualBox, nhưng vấn đề này xảy ra với một loạt trình ảo hóa. Bạn khởi động một máy ảo và thỉnh thoảng máy bị treo. Trong quá trình đó, toàn bộ hệ thống của bạn (máy chủ) sẽ không phản hồi. Tôi nhận thấy vấn đề này trong VirtualBox 7.X trở đi, trong Kubfox 22.04 trở đi.
Tôi phải mất rất nhiều công sức để khắc phục sự cố nhưng tôi nghĩ cuối cùng tôi đã tìm ra nguyên nhân gốc rễ. Khi điều đó xảy ra, đây là một lỗi cắt vấn đề vô nghĩa khác, xuất phát từ sự kết hợp của nhiều thứ:lỗi kernel, biện pháp giảm thiểu dòng Spectre, xung đột giữa máy chủ-hypervisor và sau đó là một số lỗi khác. Nói cách khác, lại có một vấn đề khác khiến người bình thường không thể sử dụng máy tính để bàn Linux một cách nghiêm túc. Nhưng ít nhất cũng có những nhân vật hài hước như tôi cố gắng làm được điều đó. Vì vậy, nếu bạn vui lòng, hãy xem hướng dẫn này. Theo sau tôi.
Vấn đề chi tiết hơn
Rất đơn giản. Bạn khởi động một máy ảo trong sản phẩm ảo hóa mong muốn của mình. Tại một thời điểm nào đó, máy ảo không phản hồi. Nó có thể đơn giản như nhấp vào biểu tượng chương trình. Sau đó, bạn cũng nhận thấy rằng máy tính để bàn chủ của bạn hoạt động không chính xác. Nó không còn phản hồi khi nhấp chuột hoặc một số chương trình nhất định không phản hồi trong khi các chương trình khác thì có. Đôi khi "sự cố" tự giải quyết được, đôi khi không, và bạn phải khởi động lại máy của mình. Vô cùng khó chịu.
Tôi đã phải đối mặt với vấn đề này trong vài tháng nay. Tất nhiên, đó là một vấn đề hạt nhân khác, có thể là vấn đề tương tự, vô dụng đã khiến Titan của tôi hoạt động sai trong một thời gian hoặc vấn đề VẪN ảnh hưởng đến Điều hành của tôi. Đối với những người quan tâm, tôi lần lượt liên kết các báo cáo thứ tư và thứ sáu này. Đối với cả hai máy tính xách tay này, đã có nhiều bài viết hơn, vì vậy hãy kiểm tra phần Linux của tôi nếu bạn muốn (báo cáo thứ sáu và thứ mười, không kém).
Tại sao tôi nghĩ đó là vấn đề về kernel? Chà, bởi vì nó bắt đầu đột ngột khi tôi vẫn đang sử dụng Kubfox 22.04 và VirtualBox 7.0. Nó tiếp tục với Kubfox 24.04 và VirtualBox 7.1. Bạn có thể nói thủ phạm là VirtualBox, nhưng điều đó không giải thích được hàng loạt lỗi kernel mà tôi đã phát hiện ra.
Cụ thể, nhật ký hệ thống của tôi có lỗi ngớ ngẩn này:
kernel:lỗi truy cập MSR không được kiểm tra:WRMSR thành 0xd10 (đã cố ghi 0x00000000000
0ffff) tại rIP:0xffffffff910c6be4 (native_write_msr+0x4/0x40)
kernel:Gọi dấu vết:
hạt nhân:
hạt nhân:? show_stack_regs+0x23/0x40
hạt nhân:? ex_handler_msr+0x10a/0x180
...
Và nếu bạn tìm kiếm "lỗi truy cập MSR không được kiểm tra:WRMSR", bạn sẽ phát hiện ra hàng trăm chủ đề, có liên quan đến openSUSE, Fedora, Rocky, Ubuntu, Proxmox, v.v. Đây hoàn toàn là một vấn đề hạt nhân và các vấn đề này đã có từ năm 2019, hầu hết chúng vẫn chưa được giải quyết. Wunderbar.
Tóm lại, vì bạn cần hiểu mã đằng sau hậu trường một chút, nên tóm tắt lại như sau:do có nhiều biện pháp giảm thiểu khác nhau được thêm vào kernel (đối với các cuộc tấn công kênh bên đó, v.v.), nên có hoặc có thể xảy ra xung đột giữa lập kế hoạch kernel và quản lý lõi của bạn và bất kỳ hệ thống con nào thực hiện điều tương tự, chẳng hạn như trình ảo hóa, đặc biệt nếu bạn sử dụng ảo hóa song song và phân trang lồng nhau. Nói tóm lại, các biện pháp giảm nhẹ có thể hơi mạnh tay, có thể dẫn đến hệ thống bị treo hoặc treo.
Ngoài ra, một lưu ý nhỏ là tất cả các biện pháp giảm nhẹ nhân này đều phù hợp 100% cho doanh nghiệp, 0% phù hợp cho việc sử dụng tại nhà. Nhưng máy tính để bàn Linux là sự trùng hợp ngẫu nhiên của thế giới hạt nhân doanh nghiệp/công ty, vì vậy bạn, người dùng cuối, phải gặp phải các vấn đề doanh nghiệp trên máy ở nhà của mình.
Giải pháp thay thế
Có ba cách để bạn có thể giảm tỷ lệ xảy ra sự cố này.
Giảm số lượng lõi CPU được gán cho máy ảo
Nếu bạn đang sử dụng khoảng 8, hãy thử 1-2, có thể là 4. Điều này sẽ giúp ích một phần nhưng sẽ không loại bỏ được vấn đề.
Vô hiệu hóa phân trang lồng nhau cho các máy ảo bị ảnh hưởng
Điều này sẽ dẫn đến hiệu suất bị ảnh hưởng đáng kể, nhưng ít nhất máy của bạn sẽ chạy tốt và hệ thống của bạn sẽ không bị treo. Ví dụ:trong VirtualBox, đi tới Hệ thống> Tăng tốc và tại đây, bỏ chọn hộp có nội dung Bật phân trang lồng nhau.
Nói chung, có một số tùy chọn bạn có thể thử, xem hoán vị nào hoạt động tốt nhất:
- Bộ xử lý> Tính năng mở rộng> Bật VT-x/AMD-V lồng nhau.
- Giao diện ảo hóa song song (mặc định của Linux là KVM).
- Ảo hóa phần cứng> Bật phân trang lồng nhau.
Tắt tính năng ảo hóa song song (phân trang lồng nhau)
Điều này có thể được thực hiện thông qua BIOS/UEFI, thao tác này sẽ vô hiệu hóa tính năng này trên toàn bộ máy hoặc bạn có thể tạo tệp cấu hình cho trình ảo hóa KVM, thao tác này sẽ ngăn việc sử dụng phân trang lồng nhau cho tất cả các máy ảo. Trong /etc/modprobe.d, tạo một tệp có tiêu đề kvm-intel.conf hoặc kvm-amd.conf, dựa trên kiến trúc bộ xử lý của bạn. Bên trong tập tin này, thêm:
tùy chọn kvm-[amd|intel] Nested=0
Sau khi tải lại các mô-đun hạt nhân ảo hóa (hoặc khởi động lại), giờ đây bạn sẽ có trải nghiệm không có MSR. Tuy nhiên, tôi không khuyên bạn nên làm điều này vì nó sẽ gây ra hạn chế về tốc độ cho tất cả khối lượng công việc ảo hóa của bạn. Tốt hơn và nhanh hơn là bỏ chọn tùy chọn trang lồng nhau cho từng máy ảo theo yêu cầu hoặc bật/tắt tùy chọn theo yêu cầu cho đến khi hy vọng bản vá kernel thích hợp sẽ giải quyết được vấn đề này.
Kết luận
Thế đấy. Một vấn đề nhỏ khác làm mất niềm tin của tôi vào máy tính để bàn Linux. Lúc này, hình phạt tích lũy dần trở nên lố bịch. Thật tuyệt khi Linux có tính mô-đun và linh hoạt như vậy, nhưng tại sao tôi lại phải quan tâm đến những người thuê khách "lừa đảo" trên đám mây trên máy tính để bàn chết tiệt của mình? Tôi không quan tâm. Và tôi mong đợi các công ty sẽ thử nghiệm nhân của họ trong mọi tình huống, không chỉ trong thế giới kinh doanh (nếu có). Tất cả chúng ta đều biết QA dành cho máy tính để bàn Linux là một trò đùa, nhưng nếu một hạt nhân làm được điều gì đó thì ít nhất phải có một chút thử nghiệm.
Tôi hoàn toàn ghét những vấn đề có tính chất này. Chúng không được kiểm tra trong NĂM. Chúng là một loại vấn đề về vụ nổ súng ngắn và không liên quan đến việc sử dụng trong gia đình. Các vấn đề đại diện cho một sự hồi quy vô nghĩa. Họ làm cho việc sử dụng hàng ngày trở nên khó khăn. Và họ nhấn mạnh không gian máy tính để bàn quá phức tạp như thế nào và về bản chất, nó không phải là không gian máy tính để bàn. Tốt nhất là bạn đang sử dụng một máy chủ tồi có GUI và một số đặc quyền nhỏ đáng lẽ phải được gọi là sử dụng tại nhà. Trên thực tế, trong những tuần tới, tôi sẽ thực sự chứng minh điều này bằng cách tập hợp bản phân phối nhỏ của riêng mình. Chuẩn rồi. Bây giờ, sự thô ráp bắt nguồn từ thực tế là nó không phải là một sản phẩm ấm cúng đẹp đẽ dành cho người bình thường như lẽ ra nó phải như vậy. Dù sao đi nữa, nếu hệ thống của bạn bị treo trong khi chạy ảo hóa, hãy kiểm tra nhật ký của bạn và thử các giải pháp thay thế được liệt kê ở trên. Cho đến khi vấn đề được khắc phục, điều này rất có thể là không bao giờ xảy ra. Tạm biệt.
Chúc mừng.