跨存储热迁移虚拟机失败，提示远程启动虚拟机失败 无 1、跨存储热迁移虚拟机失败，提示远程启动虚拟机失败 2、进入HCI后台查看任务执行主机上的日志，存在如下报错 虚拟机热迁移过程中，会调用目的主机执行vm_boot启动虚拟机，由于外部磁盘快照模块在启动虚拟机时新增了纠正快照链流程，在纠正快照链时，认为虚拟机时开机状态，就在目的主机执行了qmp命令（此时目的主机是没有qemu进程的）出现失败。这时启动虚拟机就失败了，最终导致迁移失败 临时方案： 找灾备技术支持按照这个td的修改方案进行代码变更： https://td.sangfor.com/#/defect/details/2025031400375 最终方案： 升级HCI6.11.1版本解决 虚拟机迁移 是 1、迁移后报错； 2、查看日志，确认错误信息； 3、参照代码提交，进入容器（container_exec -n asv-c；）：临时更改代码内容，重启服务（/sf/etc/init.d/vtpperlproxy restart;/sf/etc/init.d/vtpdaemon restart;/etc/init.d/apache2 restart）： 参见有效排查步骤

HCI中UEFI启动的虚拟机迁移到VMware后无法自动开机 VMware虚拟机进入控制台失败 1.排查迁移前的虚拟机在HCI上设置为UEFI启动。 2.迁移过后，Vmware的虚拟机无法自动引导进入操作系统。 纳管迁移时对UEFI文件的兼容性处理不完善。 临时解决方案： 根据KB手动添加EFI启动项： https://support.sangfor.com.cn/cases/list?product_id=33&type=1&category_id=15584 最终解决方案：待0530HCI6.11.1版本发布后升级版本即可 无 是 如果发现从HCI迁移到VMware的虚拟机，无法自动引导EFI启动项，可以参照以下KB手动创建一个引导项： 临时解决方案： 根据KB手动添加EFI启动项： https://support.sangfor.com.cn/cases/list?product_id=33&type=1&category_id=15584 最终解决方案：待0530HCI6.11.1版本发布后升级版本即可 见排查步骤

主机内部虚拟机能正常访问其他虚拟机业务，外部物理机无法正常访问业务 无告警信息，能ping通，一些业务访问异常，同时HCI内部互相业务访问都正常 1、出现问题时，测试的现象如下 （1）外部主机走物理出口能ping通虚拟机内部ip，但是业务访问异常，无法提交表单，抓包发现有rst报文 （2）内部虚拟机可以访问其他虚拟机的业务，网络也是正常 2、如果出现上面这种明显对比的问题，就需要先观察下拓扑差异 如下拓扑，虚拟机间业务访问正常，是因为虚拟机直接互相访问经过的交换机1，拓扑为vm-vxlan-vm 而从物理机经过物理出口访问内部虚拟机，拓扑上经过了防火墙设备 那么结合上面的问题，外部能ping通，说明网络链路是正常的，业务报文有问题，那疑点就是防火墙可能拦截掉业务报文的端口或者数据包了（物理防火墙也是同理） 3、如果是防火墙拦截的话，防火墙内部一般会有拦截日志，可以快速判断这块 4、有的时候也可以抓包判断，不通的时候，比如说经过防火墙之前包还在，经过防火墙之后包丢了，这种也能定界是防火墙把包丢了 防火墙将业务报文拦截 在当前问题中，是进入防火墙后台排查，发现对应业务报文确实被拦截了，直通之后就正常了        

备份期间虚拟机业务卡慢异常。 虚拟机备份存储容量告警。 1、虚拟机业务存在卡慢异常，每次异常出现时虚拟机正在进行备份。 2、虚拟机的备份存储将慢，已达到90%并产生告警。 3、进入HCI后台，查看备份期间日志/sf/log/日期/sfvt_qemu-nbd.log，内核/sf/log/日期/kernel.log存在报错，存在如下信息。 1、存储为外置sffs存储，当存储将慢时，需要索引可用数据块，存储性能会急剧下降，影响IO读写。2、610R1之前，业务IO会等待备份I0(读虚拟机磁盘，写备份存储)执行完。备份机制:备份存储卡慢-》备份IO慢-》重叠的虚拟机业务IO卡慢，最终导致虚拟机业务异常。 1、停止备份策略，清理外置存储空间。 2、安装最新合集补丁包或者升级HCI到最新版本。 HCI6.3.0R3，HCI6.8.0，HCI6.8.0R1，HCI6.8.0R2，HCI6.9.1，HCI6.9.0版本最新合集补丁包已修复。 集群，外置存储 否 1、存储为外置sffs存储，当存储空间将满，性能下降。备份时虚拟机业务卡慢异常。 2、升级HCI到最新版本或者清理外置存储空间。 前台日志，后台日志

需要判断网卡是否支持RDMA 或者使用aDeploy放通后发现网卡仍不支持RDMA 无 1.检查配置文件中是否存在网卡信息 cat /sf/cfg/vn/vn-node-agent/compatible_nics.jsonwen | jq 2.确认device id，vendor id 字段是否与/sf/cfg/vn/ifaces_dev_info.ini记录的对应字段相同（下图只是举例） 3.确认驱动名称，驱动版本，固件版本是否与/sf/log/nic_driver_info.log中记录的值相同（下图只是举例） 4.最后检查对应架构的字段是否为true 代码中判断rdma支持条件较多，需要逐步排查 按上述步骤排查后如发现不支持rdma 查询兼容性平台该网卡是否支持rdma，如果支持可以使用adeploy放通。 如果不支持请联系徐永昌77836咨询处理 无 不涉及      

断电重启后，HCI告警配置下发失败。 后台检查/sf/log/today/networkd.log 发现如下报错： 关键字：flow redirect modify check fail 1.确定HCI是否被SCP纳管并部署了云安全中心（aSec），如果没有纳管非此问题。 2.打开cfgdbd debug日志 container_exec -n vn-a(680后需要执行此步骤) echo -e "cfgdb log enable\n" | cli  关闭使用echo -e "cfgdb log disable\n" | cli 注意：开启后，一定要记得关闭 3.观察/sf/log/sdn/cfgdbd.out日志，是否存在如下失败配置： 4.登录SCP的云安全中心页面找到网络攻击防护配置，查看是否存在服务一栏为异常的策略 云安全中心策略配置异常，下发到HCI后，HCI底层无法处理，导致配置全同步失败。 临时解决方案：编辑异常策略选择正确的服务，重新下发，或直接删除异常策略重新创建 永久解决方案：暂时从人为配置上控制，不要配置错误，错误的配置无法下发失效，导致服务异常 将SCP升级到6100R2及以上版本可以减小发生的概率 需要重新编辑云安全中心策略 否      

客户配置了分布式防火墙规则，但是发现规则不起作用。需要先看一下虚拟机在数据面上有没有对应的分布式防火墙规则，本KB给出查看的方法 无 0、进入分布式防火墙界面，打开f12，然后点击策略的编辑按钮，找到异常的dfw规则ID 1、通过虚拟机详情页的url找到vmid 2、在详情页找到虚拟机的运行位置 3、将虚拟机ID转换成十六进制 4、登录HCI后台，按照下面的方法进入数据库 5、根据上面转换的十六进制数值，找到网口ID（如果vm有多个网口，这里会显示多条记录，可以根据name的值确定自己想要的网口ID） 6、登录虚拟机运行主机后台，按下面的方法进入dfw中。dfwname是dfw+网口名称。show policy-rule中的name就是规则ID。就可以确定虚拟机在数据面有没有异常的规则ID了。   无 1、如果数据面有dfw rule，但是规则没有生效，则需要找研发查一下 2、如果数据面都没有dfw rule，看看是否是因为dfw规则的作用域不包含该虚拟机。 需要注意在执行dfw dfw_xxx时要确保数据面有这个dfw（通过show dfw确定）。没有的情况下，执行该命令，相当于在数据面创建了一个dfw 否。作为查看数据面是否有dfw的方法 无    

集群多台主机，所有服务器都有挂载EDS的lun掉线的告警；同时EDS侧对应时间也是一样有断开告警   存储出现掉线告警   1）查看对应的时刻内核日志/sf/log/today/kernel.log，显示detected conn error   2）查看/sf/log/today/iscsid.log, 也是连接错误 3）对应的网卡丢包数增加 /sf/log/blackbox/LOG_ifconfig.log   网络问题导致iscsi存储离线，需要协调客户看存储服务器到HCI网络链路环境是否正常。       客户的运维排查HCI到存储服务器的网络链路  

1.卡慢盘场景，配置smartpqi raid卡的服务器宕机，宕机堆栈包含pqi_aio_io_complete。 2.踢盘场景均有可能触发。 检查宕机日志，观察堆栈是否与如下类似： [ 956.563551] smartpqi 0000:5e:00.0: removed 14:0:9:0 36c92bf000a0e41c0000000000000000 Direct-Access ATA WDC WUH722222AL AIO+ qd=32 [ 985.949532] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 [ 985.957936] PGD 0 P4D 0 [ 985.960801] Oops: 0000 [#1] SMP NOPTI [ 985.964789] CPU: 20 PID: 0 Comm: swapper/20 Kdump: loaded Tainted: G U O --------- -t - 4.18.0-6.10.0_R2 #1 [ 985.976140] Hardware name: SANGFOR S2122-S12L/ASERVER-P-2000, BIOS TYR.2.00.0100 05/18/2019 [ 985.985067] RIP: 0010:dma_direct_unmap_sg+0x24/0x60 [ 985.990275] Code: 4c 8b 04 24 eb b9 0f 1f 44 00 00 85 d2 7e 4d 41 57 49 89 ff 41 56 41 89 ce 41 55 4d 89 c5 41 54 41 89 d4 55 31 ed 53 48 89 f3 <8b> 53 18 48 8b 73 10 4d 89 e8 44 89 f1 4c 89 ff 83 c5 01 e8 44 ff [ 986.009871] RSP: 0018:ffff88942fe03e70 EFLAGS: 00010046 [ 986.015423] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 986.022893] RDX: 0000000000000017 RSI: 0000000000000000 RDI: ffff8894272760b0 [ 986.030361] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8894272760b0 [ 986.037823] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000017 [ 986.045293] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8894272760b0 [ 986.052755] FS: 0000000000000000(0000) GS:ffff88942fe00000(0000) knlGS:0000000000000000 [ 986.061410] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 986.067486] CR2: 0000000000000018 CR3: 000000000221c002 CR4: 00000000007606e0 [ 986.074950] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 986.082422] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 986.089892] PKRU: 55555554 [ 986.092928] Call Trace: [ 986.095701] <IRQ> [ 986.098046] pqi_aio_io_complete+0x16/0xa0 [smartpqi] [ 986.103423] pqi_irq_handler+0x1be/0x970 [smartpqi] [ 986.108634] ? try_to_wake_up+0x44/0x5a0 [ 986.112884] __handle_irq_event_percpu+0x7b/0x190 [ 986.117920] handle_irq_event_percpu+0x20/0x50 [ 986.122694] handle_irq_event+0x36/0x60 [ 986.126855] handle_edge_irq+0x7a/0x190 [ 986.131024] handle_irq+0x1c/0x30 [ 986.134668] do_IRQ+0x49/0xe0 [ 986.137962] common_interrupt+0xf/0xf [ 986.141949] </IRQ> [ 986.144371] RIP: 0010:mwait_idle+0x6f/0x1c0 [ 986.148883] Code: 80 6c 01 00 48 89 d1 0f 01 c8 48 8b 00 a8 08 0f 85 47 01 00 00 e9 07 00 00 00 0f 00 2d dc f3 53 00 31 c0 48 89 c1 fb 0f 01 c9 <65> 8b 2d 9a 91 74 7e 0f 1f 44 00 00 65 48 8b 04 25 80 6c 01 00 f0 [ 986.168473] RSP: 0018:ffffc900002e3ed0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffdd [ 986.176613] RAX: 0000000000000000 RBX: 0000000000000014 RCX: 0000000000000000 [ 986.184079] RDX: 0000000000000000 RSI: 0000000000000087 RDI: 0000000000000000 [ 986.191551] RBP: 0000000000000014 R08: 0000000000000000 R09: 0000000000000002 [ 986.199020] R10: 00000000000439d3 R11: ffff88942fe3d9c0 R12: ffff889428488000 [ 986.206489] R13: 0000000000000000 R14: 0000000000000000 R15: ffff889428488000 [ 986.213957] do_idle+0x1a0/0x260 [ 986.217510] cpu_startup_entry+0x19/0x20 [ 986.221761] start_secondary+0x156/0x190 [ 986.226016] secondary_startup_64+0xb7/0xc0 1.进入vs容器，确认驱动与固件版本。 container_exec -n vs-c /sf/bin/raidtools/bin/arcconf_pm822 getversion   smartpqi驱动bug，当内核通用块层释放request后，驱动处理已释放的io时未做好前置检查。 1.临时规避方案，如有故障硬盘则先替换，后续如果频发可考虑停止vs容器内的踢盘服务。 container_exec -n vs-c mv /sf/vs/etc/init.d/unused-disk-monitor /sf/vs/etc/init.d/unused-disk-monitor.bak /sf/vs/etc/init.d/unused-disk-monitor.bak stop mv /sf/vs/etc/init.d/vs-diskchecker /sf/vs/etc/init.d/vs-diskchecker.bak /sf/vs/etc/init.d/vs-diskchecker.bak disable /sf/vs/etc/init.d/vs-diskchecker.bak stop 2.等待后续补丁计划。 规避方案，禁用vs容器内的踢盘服务操作，可能会导致硬盘卡慢时业务也出现卡慢。 是，永久解决方案预计6.11.1修复，补丁计划待定预计6.11.1发布之后一个月 非不必要，不要用规避方案。 smartpqi上的硬盘因为故障，导致上层提交io硬盘完全不响应。此时进行踢盘，scsi层会经过一系列超时错误处理后，走到scsi_finish_command → scsi_io_completion → scsi_mq_uninit_cmd → scsi_mq_free_sgtables ，此处对struct scatterlist等结构进行了释放， 当后续raid卡长时间没有收到故障硬盘io，触发pqi_irq_handler中断处理卡住的io时，此时通用块层已经将还未返回的io释放了，从而导致了空指针。  

1、当出现宕机三无的问题上升研发必要执行：无core，无dmesg，内核日志空，需要收集信息以分析，但是日志从微信拷贝来拷贝去非常的繁琐耗时，而且上传到文叔叔之类的需要研发下载，可能问题多一下就忘记下载了 2、使用研发的提供的日志传输通道替代文叔叔和百度云企业微信之类的第三方传输平台，可以一步将日志传送到研发内网服务器                 1、打开 ：HCI技术支持平台  点击 下载工具 按钮下载日志收集脚本 2、按照收集方法把日志上传到出问题的服务器，执行命令收集日志 3、拷贝日志到远程电脑 4、打开: Token获取平台 这里需要登陆Atrust，目前只有CTI能访问 获取上传的Token（当前只有CTI和研发才能登陆atrust能访问这个网站） 5、查看并复制Token 6、点击 HCI技术支持平台 点击 上传文件 填写复制的Token并选择需要上传文件点击上传                

在6.11.1版本，HCI qemu支持ARM架构虚拟机cpu拓扑结构，但经测试发现麒麟guestos内lscpu无法查看cpu拓扑 无外部告警 给虚拟机配置2socket 4core，在虚拟机内部通过lscpu只能看到1socket8core。无法显示cpu拓扑信息 查看麒麟guestos kernel日志，可以看到ACPI错误，PPTT unable to locate core x 该问题经麒麟内部确认可以认定为麒麟os自身缺陷 由于该问题为麒麟侧缺陷导致，以下的方案为麒麟侧给出 1. 使用内核版本高于4.19.90-52.43版本的麒麟os。但当前内核版本暂时没有提供发行版，可关注麒麟官方发布。2. 购买麒麟正版授权的客户，可以自行联系麒麟侧，会有技术支持协助升级内核版本。 虚拟机cpu拓扑 否 无 无  

存在外部快照的链式派生云主机进行克隆或快照克隆时新建全量克隆虚拟机失败，报错系统繁忙 1、检查虚拟机为链式派生虚拟机，发现存在外部快照 2、对虚拟机执行全量克隆或全量克隆虚拟机快照 3、报错对应时间点后台日志（/sf/log/today/vmdisk-agent-rpc.log）出现不能打开磁盘的报错 4、虚拟机运行主机不能访问克隆的目标存储   1、链式虚拟机存在外部快照情况下进行克隆或进行快照克隆时，最后一步会进行磁盘convert和rename，这两个操作在执行时中并未进行调度而是直接在本机操作 临时解决方案： 1、配置虚拟机运行的主机能访问克隆的目标存储   彻底解决方案： 1、升级到HCI6.11.1   否    

开了CBT的虚拟机磁盘跨粒度热扩容两次后，cbt位图会异常缩小 导致第二次扩容失败，并导致虚拟机HA。 注：跨粒度扩容指的是以下两种情况之一：1. 磁盘本在1024GB以下，扩容到了1024GB以上 2. 磁盘本在4TB以下，扩容到了4TB以上 虚拟机HA 1. HCI后台在虚拟机镜像目录下，确认虚拟机是否开了CBT（有没有cbt相关文件） 2. 编辑虚拟机扩容任务失败 3. 虚拟机HA 开了CBT的虚拟机磁盘跨粒度热扩容两次后，cbt位图会异常缩小 导致虚拟机HA。 虚拟机出现该问题后，联系技术支持为用户关闭虚拟机CBT，可恢复。 规避方案： 方案一（永久解决）： 打HCI6.10.0_R2在25年3月的技术支持补丁 方案二（永久解决）： 升级HCI至6.11.1或更高版本 虚拟机磁盘扩容、无代理备份 见 解决方案 无 无  

存在外部快照的虚拟机，删除外部快照后，虚拟机无法正常开机启动业务/数据异常 虚拟机无法正常开机启动业务/数据异常   后台在虚拟机删除快照的执行节点上，在删除外部快照期间，存在下图错误日志 1、关机删除最新快照005，stream合并（001->005->006）到最后阶段：改backing成功后存储异常，刷元数据失败，且管理面rm掉005快照文件失败； 2、触发第二次关机删除最新快照成功（由于被改backing，有可能跳过了刷元数据失败的COR区域），之后的TOP镜像数据就有问题了 3、在多次创建删除快照后（合并路径：001->005->006, 001->006->007, ... , 007->disk4) ，最终将问题数据合并到了基镜像，导致之后的镜像链上所有数据出问题。 问题发生后，数据已丢失，无法恢复。规避方案如下： 方案一（永久解决）： 打HCI6.10.0_R2在25年3月的技术支持补丁 方案二（永久解决）： 升级HCI至6.11.1或更高版本 虚拟机删除外部快照 见解决方案 无 后台日志，前台审计日志  

外置存储上的虚拟机已开启CBT，跨主机不跨存储热迁移导致虚拟机HA 虚拟机HA 1. HCI后台在虚拟机镜像目录下，确认虚拟机是否开了CBT（有没有cbt相关文件） 2. 虚拟机运行在外置存储上 3. 虚拟机执行了跨主机不跨存储热迁移 4. 虚拟机HA 同存储跨主机热迁移的时候对端会先创建一个临时文件（文件名为[external_XXXX_]vm-disk-X.mig.vmid）用于对端qemu拉起，数据传输完成后会去加载cbt位图，加载的时候打开cbt位图文件是根据bs的文件名来获取CBT文件名，由于临时文件是.mig因此匹配不到相应的CBT位图文件，导致迁移失败，虚机HA。 方案一（永久解决）： 打HCI6.10.0_R2在25年3月的技术支持补丁 方案二（永久解决）： 升级HCI至6.11.1或更高版本 虚拟机迁移 见解决方案 无 前台任务与后台虚拟机属性  

【Title】：虚拟机异常关机重启【最近告警时间】：2025-02-03 11:08:01【描述】：HA第1次拉起虚拟机（X）失败，错误信息：当前虚拟机状态为：正在迁移，不允许启动【集群_IP】：x.x.x.x   1. 查看HCI补丁情况信息。 cat /boot/firmware/history 2. 通过排查HCI前台虚拟机的操作日志，发现：迁移虚拟机、内部重启虚拟机、启动虚拟机、HA恢复虚拟机等操作日志。 同客户获取信息：客户没有做过内部重启操作，没有做过手动迁移等操作。虚拟机有安装vmtools，没有特殊配置； 3. 通过HCI平台所有主机后台执行lmtTools排查虚拟机HA，关注输出为【err】或者【warn】的内容。 sfd_cluster_cmd.sh e "/sf/lmtTools -opt chkHA -vmid 814117875802 -haTime 3" 3.1 发现：【err】虚拟机HA，执行（grep 'handle_abort_vms_run，start_vms' -rn /sf/log/3/ | grep 814117875802）查看日志详情 3.2 发现：【err】虚拟机HA，可能是以下原因导致： 虚拟机原运行主机异常qemu进程异常退出（/sf/data/local/dump下会有日志）vtp-vmmonitor由于io-error杀掉了qemu进程（见vtp-vmmonitor检查结果）由于内部重启虚拟机导致误判，见kb: http://tskb.sangfor.com/forum.php?mod=viewthread&tid=19466 排查结果： 虚拟机原运行主机无异常qemu进程未异常退出（/sf/data/local/dump下没有发现日志） 工具名： lmtTools： http://tskb.sangfor.com/plugin.php?id=menu_tags:index&mod=viewdatabase&tid=31852&search=6d704f64515565444c554e485a&highlight= 4. 通过排查HCI平台主控后台的vtprgm日志sfvt_vtprgm.log，找到关键日志：add vm 814117875802 as it aborted，说明：11:07:58 虚拟机状态异常（虚拟机电源状态power为on，虚拟机状态status 为 stopped）而导致的HA。 vim /sf/log/[日期]/sfvt_vtprgm.log 5. 通过排查迁移前虚拟机运行位置所在HCI主机后台的qemu日志sfvt_qemu_[vmid].log，发现：vl:1705 ### qemu_system_reset_request ###，说明：内部重启虚拟机，需要进一步排查虚拟机内部重启的原因。 (1)虚拟机系统内部正常重启时，qemu会输出日志：pckbd:313 kbd_write_command => qemu_system_reset_request(2)虚拟机系统内部正常关机时，qemu会输出日志：core:554 ### acpi_pm1_cnt_write => qemu_system_shutdown_request ###(3)虚拟机系统内部由于硬狗wdt超时而重启时，qemu会输出日志：watchdog:117 ### qemu_system_reset_request ### (4)内部重启虚拟机，qemu会输出日志：vl:1926 ### qemu_system_reset_request ### 6. 通过排查虚拟机内部Windows日志：系统，发现：Windows 成功诊断出虚拟内存不足的情况。以下程序使用了大部分虚拟内存: sglservr.exe (3692)使用了 905621504字节:PopBlock.exe(5040)使用了737116160 字节:MsMpEng.exe (3764)使用了337510400 字节，说明：Windows虚拟内存不足导致"虚拟机异常关机重启"。 【aDesk】Windows运维问题之虚拟机使用过程中突然黑屏 https://support.sangfor.com.cn/cases/list?product_id=26&type=1&category_id=13805&isOpen=true 7. 通过排查HCI平台主控后台的policy日志policy.log，发现：suggestion [host-X:[vmid]:host-X] auto join the migrate queue，说明：迁移虚拟机是由DRS调度自动发起。 vim /sf/log/[日期]/policy.log       虚拟机内部重启的原因：Windows虚拟内存不足；物理机负载不均衡触发DRS迁移虚拟机，然后虚拟机虚拟内存不足导致内部关闭虚拟机（此时迁移还在进行所以会导致HA失败），此时：虚拟机状态异常（虚拟机电源状态power为on，虚拟机状态status 为 stopped）而导致虚拟机异常关机重启。   临时规避方案 不涉及。 彻底解决方案 空闲期间调整虚拟内存。        

问题现象： （1）前端看网口离线了   （2）后台看网口有up但没有running   （3）前端看网口可能是灰色的   （4）后台看网口都是down的，且mac都是 0   （5）ethtool拿不到任何数据   以上几个现象都可能是这个问题   1. 查看内核日志，发现出问题的几个网口都出现 Firmware recovery mode detected 的信息 该信息表明网卡固件进入了恢复模式，该模式下固件功能有所缺失，有些信息会拿不到。 网卡固件进入了恢复模式（ Firmware recovery mode），该模式下固件功能有所缺失导致网口异常，比如down无法up、mac为0，ethtool获取不到信息，无法收发包等等。 这种情况属于网卡固件层面的错误，如果固件版本过低需要升级固件，有时可能断电重启后能恢复，但无法保证下次不会再出。 重启主机影响 否      

网口降速 主机网口降速 1、后台连接到问题主机，进入vn-agent容器确认告警接口接管状态 进入vn-agent容器： container_exec -n vn-agent 查看接管状态： echo -e "show interface-take-over\n"|cli，输出结果中，显示take-over的为接管状态，其他为非接管状态；   2、查看网卡支持速率和当前速率 存在p_ethX口或者非接管接口 执行realethtool p_ethX（非接管口执行 realethtool ethX）查看 support link modes为支持的最大速率；下面speed为当前速率；当speed速率小于支持的最大速率时即发生了降速； 其他情况联系研发确认； 网口降速通常为硬件问题，如网卡、网线、光模块、光纤、对端交换机口； 可尝试更换网线、光纤、光模块以及对端网口尝试解决；更换后仍存在问题联系硬件排查； 排查过程不影响业务；更换网线、光纤、光模块以及对端网口会导致网口down、up，注意业务影响； 否 按照kb排查； 网口支持速率以及当前协商速率；  

虚拟机关机删除外部快照后出现数据异常 无 1.查看关机删除快照时间点的sfvt_qemu-img-real.log，日志内有qocw2_cache_entry_flush的报错： 2.HCI操作日志中显示删除快照成功。 3.虚拟机开机后会存在数据异常。 关机使用qemu-img stream方式合并外部快照，只会在close磁盘时刷新元数据 。若在close时刷新元数据失败(不影响合并成功的结果），就会导致虚拟机数据丢失。 1.合集补丁未发布前如果有客户需要关机删除快照，则联系技术支持替换qemu-img二进制工具后再执行删除。 2.升级HCI6.11.1版本或者HCI6.10.0R2版本+0330合集补丁，解决该问题。 替换二进制影响范围：快照合并，镜像创建等使用qemu-img二进制的操作。   替换二进制为临时方案，升级版本和打上HCI6.10.0R2的0330合集补丁为最终解决方案。 HCI6100，HCI610R1，HCI610R2版本关机删除快照时有数据丢失的风险，需要尽快升级到HCI6.10.0R2的版本并打上0330的合集补丁。   见有效排查步骤  

插拔usb设备时，服务器宕机出core。   宕机问题，无前台告警 查看宕机日志 [56585606.336851] usb 1-2: USB disconnect, device number 2 [56585610.740837] usb 1-2: new full-speed USB device number 14 using xhci_hcd [56585610.872850] usb 1-2: device descriptor read/64, error -71 [56585611.143354] usb 1-2: New USB device found, idVendor=096e, idProduct=0705, bcdDevice=63.10 [56585611.143357] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [56585611.143358] usb 1-2: Product: FT Interpass3000 [56585611.143359] usb 1-2: Manufacturer: FS [56585611.144448] usb-storage 1-2:1.0: USB Mass Storage device detected [56585611.144551] scsi host30: usb-storage 1-2:1.0 [56585612.172075] scsi 30:0:0:0: CD-ROM FT Interpass300004 1.00 PQ: 0 ANSI: 2 [56585612.172079] scsi 30:0:0:0: scsi_device_set_state() [created]->[running] [56585612.172230] scsi 30:0:0:1: scsi_device_set_state() [created]->[deleted] [56585612.173312] sr 30:0:0:0: [sr0] scsi3-mmc drive: 0x/0x caddy [56585612.173966] sr 30:0:0:0: Attached scsi CD-ROM sr0 [56585612.174069] sr 30:0:0:0: Attached scsi generic sg55 type 5 [56585615.816804] device channel1.3705 entered promiscuous mode [56585619.357557] device channel1.3705 left promiscuous mode [56585620.560744] device channel1.91 entered promiscuous mode [56585621.775416] sr 30:0:0:0: scsi_device_set_state() [running]->[cancel] [56585621.776639] scsi 30:0:0:0: scsi_device_set_state() [cancel]->[deleted] [56585622.261200] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585622.921195] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585623.593202] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585623.925843] device channel1.91 left promiscuous mode [56585624.385192] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585624.677175] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585624.981200] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585625.781185] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585625.934135] usb 1-2: device descriptor read/all, error 2 [56585626.061130] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585626.214152] usb 1-2: device descriptor read/all, error 2 [56585626.345118] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585626.366216] usb 1-2: device descriptor read/all, error 2 [56585626.497109] usb 1-2: reset full-speed USB device number 14 using xhci_hcd [56585626.517802] usb 1-2: device descriptor read/all, error -71 [56585626.517933] usb 1-2: USB disconnect, device number 14 [56585626.518097] general protection fault: 0000 [#1] SMP NOPTI [56585626.518208] CPU: 40 PID: 7690 Comm: kworker/40:1 Kdump: loaded Tainted: G U O --------- -t - 4.18.0 #1 [56585626.518331] Hardware name: SANGFOR INSPUR/ASERVER-P-2305, BIOS 4.1.8 12/06/2019 [56585626.518445] Workqueue: usb_hub_wq hub_event [56585626.518553] RIP: 0010:kfree+0x4b/0x170 [56585626.518651] Code: ba 00 00 00 80 48 8b 15 73 28 fd 00 49 01 da 0f 83 d4 00 00 00 49 01 d2 49 c1 ea 0c 49 c1 e2 06 4c 89 d0 48 03 05 05 68 f1 00 <48> 8b 50 08 4c 8d 52 ff 83 e2 01 4c 0f 44 d0 49 8b 52 08 48 8d 42 [56585626.519111] RSP: 0018:ffffc90026563cb0 EFLAGS: 00010207 [56585626.519525] RAX: 03ffe9fe00ddd5c0 RBX: ffff880037757063 RCX: 0000000082000111 [56585626.520248] RDX: 0000777f80000000 RSI: 0000000082000111 RDI: ffff880037757063 [56585626.520956] RBP: ffff88fcd6248800 R08: 0000000000000001 R09: 0000000000000000 [56585626.521647] R10: 03fffffe00ddd5c0 R11: 0000000000000000 R12: ffffffff81628448 [56585626.522339] R13: ffff88fcd62488b0 R14: ffff88b851a2c800 R15: 0000000000000002 [56585626.523042] FS: 0000000000000000(0000) GS:ffff88bf80300000(0000) knlGS:0000000000000000 [56585626.523801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56585626.524226] CR2: 00000223a86b0010 CR3: 000000000221c005 CR4: 00000000007626e0 [56585626.524920] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [56585626.525612] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [56585626.526306] PKRU: 55555554 [56585626.526691] Call Trace: [56585626.527084] usb_destroy_configuration+0x48/0x120 [56585626.527479] usb_release_dev+0x1f/0x60 [56585626.527878] device_release+0x30/0x90 [56585626.528273] kobject_release+0x68/0x190 [56585626.528663] hub_port_connect+0x75/0xa70 [56585626.529057] hub_event+0x752/0xae0 [56585626.529450] process_one_work+0x15e/0x3f0 [56585626.529841] worker_thread+0x4c/0x440 [56585626.530230] ? rescuer_thread+0x350/0x350 [56585626.530621] kthread+0xf8/0x130 [56585626.531009] ? kthread_destroy_worker+0x40/0x40 [56585626.531402] ret_from_fork+0x1f/0x40 [56585626.531793] Modules linked in: ib_iser(O) rdma_cm(O) iw_cm(O) ib_cm(O) squashfs overlay ipmi_poweroff ipmi_watchdog ipmi_devintf bonding iptable_nat nf_nat_ipv4 nf_nat nfsv3 ipt_REJECT nf_reject_ipv4 rpcsec_gss_krb5 nfsv4 dns_resolver xt_comment fuse nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc 8021q garp mrp ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack libcrc32c iptable_filter ip_tables ramoops reed_solomon mpt3sas(O) raid_class scsi_transport_sas iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vhost_net vhost tap vfio_iommu_type1 vfio_pci vfio_virqfd vfio mlx5_ib(O) mlx5_core(O) mlxfw tls(t) ib_uverbs(O) ib_core(O) mlx_compat(O) dm_round_robin dm_multipath mlx4_en mlx4_core tipc ip6_udp_tunnel udp_tunnel tun nbd skx_edac nfit libnvdimm k10temp coretemp bridge stp llc watch_reboot(O) sffs(O) cl_lock(O) cl_softdog(O) kvm_intel kvm irqbypass igb(O) i2c_algo_bit ixgbe(O) i40e(O) loop dm_mod sr_mod cdrom usbhid sg sd_mod usb_storage [56585626.531833] iTCO_wdt iTCO_vendor_support pcspkr megaraid_sas(O) ahci i2c_i801 libahci lpc_ich i2c_core mfd_core ioatdma libata dca wmi ipmi_si ipmi_msghandler acpi_cpufreq acpi_power_meter sch_fq_codel [last unloaded: iw_cm] [56585626.537056] Features: eBPF/event 观察是否存在 [56585625.934135] usb 1-2: device descriptor read/all, error 2 [56585626.214152] usb 1-2: device descriptor read/all, error 2 [56585626.366216] usb 1-2: device descriptor read/all, error 2 相关日志。并且堆栈相似，则为同问题 特定usb设备初始化时，usb配置读取可能会不完整，导致内存拷贝时出现脏数据，从而异常访问导致宕机。 6.11.1版本已解决该问题 td2024072200006，升级后即可解决。 旧版本补丁还在排期中。 升级HCI版本需要集群主机重启。 否 如引起故障的usb设备后续常用，建议安排时间升级HCI版本，如不常用，可考虑等待后续的补丁计划。 hub_port_init调用usb_get_device_descriptor，向下传入了USB_DT_DEVICE_SIZE=18， 现有代码逻辑，当usb_get_descriptor返回值大于0时，memcpy就会固定将desc的数据传入&dev->descriptor， 但是没考虑到usb_get_descriptor读取到的值和USB_DT_DEVICE_SIZE不一致的情况。