标签归档:处理办法

N5105,ALL IN ONE 主机,PVE下VM卡死,故障处理,方式方法,记录 2023-05-04

一、需求描述

如前两篇博客记录的,我购买了一个N5105主机,配置了PVE虚拟化,安装了一些VM虚拟机,主要为Debian 11系统的VM,运行了几天,发现了一个很严重的问题。

那就是,VM虚拟机,会出现卡死的现象,具体表现为,在整体资源使用率不高的情况下,虚拟机VM,无法SSH连接登录,此时从PVE后台VM的Console页面观察,login:后面的光标不再跳动,部分时候,Console页面,出现cpu类型的错误提示页面

二、问题分析

这样就很尴尬了,这个不知道是设备散热问题,还是设备的CPU通道的性能问题,对于自己而言,这个稳定性,就有很大的问题了,低功耗设备不堪大用呀,下次一定买桌面级CPU的设备玩,不玩低功耗的了。

后续查了一下谷歌,好像,这个是一个N5105的普遍现象,属于已知的Bug存在,网络的处理办法,就是更新Microcode,PVE的Linux核,这个好像即便更新了,也作用不大。也有说,必须换成Windows平台做虚拟底层才行。

我这里已经部署了PVE,也不想大折腾了,下次换桌面CPU的设备就是了,就这样吧,这个小破玩具。

这个现象,不知道有没有朋友遇到过类似的故障场景,有更好处理办法的,有的话,务必留言告诉我。

三、处理办法(我自己的处理方式,临时)

临时处理方式也简单,对于,跑在这台N5105设备上的VM,我对其要求只要10分钟内,能自愈恢复即可,那即便它VM卡死,只要一旦发现其出现卡死的情况,需要对其进行强制关机,开机一下即可。

每个VM卡死,人工点击 虚机的硬关机、启动,终究是不行的,我这里使用Python设置定时轮询检测任务,配置定时的检测,逻辑为一旦出现3次无法登录该VM(每次间隔几十秒),即进行VM强制重启的操作。

三、执行处理,含代码部分 * 开源

https://github.com/fdmove/PublicCodex/blob/main/vm_status_command_monitor.py

为了简化操作,我这里,使用了SSH的私钥登录Debian 11虚机,这样,代码就简化了,不必使用SSH用户名/密码的方式。

需要使用字典,静态化定义VM的 IP、SSH端口、SSH超时时间秒数、PVE内的VMID几个参数

检测的时间间隔,为20秒

检测逻辑为,私钥SSH登录VM,执行 echo OK命令,能返回OK字符串,即可认为虚机VM是正常的,其他或异常就认为VM卡死了

代码没什么的,非常简单,配置一个轮循的定时任务即可,我配置的是8分钟执行一次VM状态的检测工作。

配置在PVE宿主机内的cron任务如下:

#  SSH ECHO 方式
*/8 * * * * /usr/bin/python3 /root/sh/vm_status_command_monitor.py  > /root/sh/Log_vm_status_command_monitor.log

这样,配置下来,发现也就没什么了,基本,即便VM卡死,在上面的代码帮助下,VM也能10分钟~20分钟内恢复,也算是一个不错的临时的解决办法。

四、后续1官方社区,给到的处理办法(推荐)

更新于 2023-05-05

根据proxmox社区的话题讨论,对于N5105虚拟化,可选升级到5.19内核,会稳定一点

https://forum.proxmox.com/threads/opt-in-linux-5-19-kernel-for-proxmox-ve-7-x-available.115090/

升级操作

apt update
apt install pve-kernel-5.19
reboot

也就死马当作活马医,升级内核试试看了,升级后的版本如下(更新时间 2023-05-05),升级后,把我的监控脚本,暂时停掉或者设置一个长间隔时间运行,观察看看。

root@pve:~# uname -a
Linux pve 5.19.17-2-pve #1 SMP PREEMPT_DYNAMIC PVE 5.19.17-2 (Sat, 28 Jan 2023 16:40:25  x86_64 GNU/Linux
root@pve:~# 

升级后,第四天了,VM虚机基本非常平稳的运行着,只有1台VM有点问题。相比之前,已经稳定非常多了。

附录1、

博客内,所有教程为手打原创教程,如果技术教程对您有所帮助,欢迎打赏作者

对于博客内已提及的专业知识,如果需要技术指导,欢迎联系我,仅需支付工时费

Twitter: Dasmz

Youtube: @DasmzStudio

Donate
云乞讨