问题描述
在虚拟机内重启数通引擎会导致虚机重启
环境信息
arm 虚拟机
问题定位过程
1. 调大 printk 级别后 kill 数通引擎查看串口输出
串口输出中未见明显异常信息。
2. 重命名负责绑定网卡接口到 igb_uio 的程序测试
根据过去的经验，在 dpdk 数通引擎运行的时候如果去解绑业务口，也可能会导致系统重启。需要排除负责绑定网卡接口程序的影响。
重命名并杀掉相关程序后，kill 引擎后虚机仍旧重启。
3. 运行 l2fwd 程序并 kill 观察是否重启
l2fwd 代表数通引擎的极简原型，关联大的内容是 igb_uio.ko。使用 l2fwd 测试是怀疑 igb_uio.ko 的影响导致虚机重启。
测试确认不会重启。
4. 运行 kni 程序并 kill 观察是否重启
kni 与数通引擎一样都使用了 rte_kni.ko 模块，一旦出现问题可能导致系统异常。使用 kni 程序做相同的测试，以排除 rte_kni.ko 的嫌疑。
测试确认不会重启。
5. 移动数通引擎使用的一些内核 ko，仍旧会重启
虚拟机中的数通引擎在启动的时候会加载一些内部功能用到的一些内核 ko，怀疑可能是这部分 ko 的影响。
重命名 ko 所在的目录后，重新测试，确认虚机还是会重启。‘
6. 重命名 reboot、shutdown 命令，杀掉数通引擎后仍旧重启
怀疑可能是主动调用 reboot、shutdown 命令重启了虚拟机。重命名这些程序后，测试确认虚机仍旧会重启。
初步结论与问题
初步结论：问题出在环境上、外部。
问题 1：在虚拟机内部没有看到任何相关的异常信息，做的排查也没有找到问题，问题是否在外部？
问题 2：如果是主动重启，dmesg 中会有一些相关日志的输出，然而检查日志发现没有相关内容，是否有其它影响输出的功能？
是否宿主机上有人杀了虚拟机
经过上文中一通排查后，怀疑点渐渐向外前进。ps 查看到 kvm 程序的 pid 等信息，怀疑宿主机上有人可能会杀 kvm 程序导致虚机重启。
由于宿主机上缺少 gdb、strace，考虑到还有其它虚机在跑，不能执行进一步的操作排除问题，直接放弃。
问题对称过程
目标：
使用老镜像跑新的数通引擎
现状：
使用新的镜像在跑新数通引擎
分析建议：换为老镜像，快速验证是否有相同的问题，有问题再处理
几十分钟后确认到的真正的问题
几十分钟后，产品反馈问题不在虚拟机内部，是宿主机上启动的一个服务里面检测到虚拟机不转发报文就重启镜像
解决方案
在宿主机上关掉了相关服务，重启数通引擎之后设备就没有重启了。
问题与思考
-
在虚拟机中重启系统时，宿主机上的 kvm 进程会终止并重新创建吗？
- 在虚拟机中重启系统，kvm 进程不会终止，pid 不会变化，观测 kvm 进程的 pid 就能够排查问题
- 虚拟机内核 crash 自动重启时 kvm 进程的 pid 也不会变化（目前暂时没有条件验证）
-
杀掉数通引擎所带来的直接与间接的影响能否梳理出来？为什么忽略了杀数通引擎带来的报文转发终止的特点呢？l2fwd 也存在报文转发终止问题但是为什么没有相同的问题？是检测有特定的要求？
直接扎进问题比较容易关注眼前的现象而忽略稍远距离的现象。没有梳理出来杀掉数通引擎带来的一些间接的影响。
-
kvm 虚机的进程在哪些情况下会变化？
在宿主机上销毁虚拟机、stop、start 虚拟机、杀掉虚机的 kvm 进程，会导致虚机的 kvm 进程的 pid 变化。
问题定位过程的重整
- 调大虚机的内核打印级别，复现问题，查看 dmesg 信息
- 确认 dmesg 信息没有任何异常后，继续复现问题，在宿主机上观察虚拟机对应的 kvm 程序的 pid 是否变化
- 当虚机对应的 kvm 程序的 pid 变化时在宿主机上找问题，没变化时继续在虚机中找问题