簡介
本文檔介紹如何解決由CentOS核心崩潰引起的CPS（思科策略套件）VM重啟問題。
問題
每個CPS虛擬機器（qns、lb、pcrfclient等）都基於CentOS運行。這些VM可能由於CentOS端的問題（而不是CPS應用程式端的問題）而重新啟動。如果由於CentOS核心的問題而重新啟動，則即使對CPS capture_env進行了調查，也無法找到根本原因。capture_env日誌不包含重新啟動期間重新啟動的VM中的任何錯誤日誌。在這種情況下，/var/crash下的日誌可用於調查。
解決方案
CentOS可以在核心出現問題時生成核心崩潰轉儲。預設情況下，CPS配置為收集所有VM的核心故障轉儲。
此命令可檢查狀態。
[root@dc1-qns01 ~]# systemctl status kdump.service
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2023-01-10 07:29:35 UTC; 4 months 4 days ago
Main PID: 1023 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 75300)
Memory: 0
CGroup: /system.slice/kdump.service
如果在啟用kdump.service的情況下發生核心崩潰，則在/var/crash下生成名為「address-YYYY-MM-DD-HH:MM:SS」的目錄。CentOS在此目錄下生成2個檔案。
[root@dc1-lb02 127.0.0.1-2022-10-18-06:18:41]# pwd
/var/crash/127.0.0.1-2022-10-18-06:18:41
[root@dc1-lb02 127.0.0.1-2022-10-18-06:18:41]# ls -rtl
total 161436
-rw-r--r-- 1 root root 89787 Oct 18 2022 vmcore-dmesg.txt
-rw------- 1 root root 165215218 Oct 18 2022 vmcore
- vmcore:
將核心記憶體的內容儲存為二進位制檔案的檔案。分析需要核心調試和崩潰等工具。
- vmcore-dmesg.txt:
崩潰時的dmesg文本檔案。
例如，在CPS端的日誌中，未從重新引導的VM的日誌中確認重新引導之前的錯誤日誌。分析結果來自VMWare端，重新啟動是由此錯誤日誌引起的，該錯誤日誌是由訪客作業系統引起的。
The CPU has been disabled by the guest operating system. Power off or reset the virtual machine.
如果存在與重新啟動時間匹配的目錄，請檢查重新啟動的VM的/var/crash。事實證明，重新啟動是由於CentOS端的核心問題，我們能夠繼續進一步的調查。
意見