虚拟机备份覆盖恢复期间，虚拟机所在存储位置的存储发生异常（比如虚拟存储网络异常等），备份恢复失败后启动虚拟机失败，描述：虚拟磁盘（）镜像文件不可访问，请检查存储网络和磁盘状态。   1. 通过排查操作日志中涉及HCI主机后台的vtpdaemon日志sfvt_vtpdaemon.log，找到关键报错：rename或者重命名文件失败，说明：覆盖恢复进程出现异常。 vim /sf/log/[日期]/sfvt_vtpdaemon.log 2. 通过排查HCI前台操作日志，说明：启动虚拟机失败出现在执行恢复虚拟机备份之后。 2.1 发现：恢复虚拟机备份，失败，描述：恢复XXX备份失败：恢复虚拟机镜像目录失败！回滚配置失败，请联系技术支持处理！错误码：0x0100058F。 2.1 发现：启动虚拟机，失败，描述：虚拟磁盘（）镜像文件不可访问，请检查存储网络和磁盘状态。 3. 通过排查虚拟机配置文件，发现：虚拟机配置文件全在/sf/data/xxx/private/recycle/目录下。 1. TD2024082600545。该TD在备份覆盖恢复过程中新增回滚机制，修复覆盖恢复源虚拟机目录移动之后恢复失败但是未做回滚导致虚机无法开机的问题。2. 在回滚期间若源虚拟机所在存储发生异常，回滚会失败，进而仍存在源虚拟机开机失败问题。 如果无法解决回滚失败的问题，期望在源虚拟机备份恢复失败导致无法开机时给个提示信息：如虚拟机备份恢复失败，下次启动会发生故障，请联系技术支持。 临时规避方案 联系灾备技术支持进行恢复：将虚拟机配置文件拷贝回原目录即可。 彻底解决方案 TD2025032800152。        

6.10.0告警HA预留资源不足，发现HA预留资源不足，平台无法保障有冗余资源可以恢复虚拟机，保障业务高可用，建议扩容HA预留资源或关闭不重要的虚拟机来释放HA预留资源 版本6.10.0 1、6.10.0 会定时模拟主机离线，假如这台主机离线，剩余资源（内存、cpu）不足以HA任一主机上面的所有虚拟机，则会触发告警。 2、该告警是预防式告警，但是该功能计算剩余资源时，错误的把预留资源按已占用来计算了，导致配置预留资源后，反而判断资源不足 【临时解决方案】可以忽略告警或者告警配置页面关闭该告警 【长期解决方案】 方案一：升级至6.10.0r2版本，并打上202505的集合补丁(关注社区补丁发布) 方案二：升级至6.12.0版本(待发布)              

存在外部快照的链式派生云主机进行克隆或快照克隆时新建全量克隆虚拟机失败，描述：系统不可用，可能由于系统繁忙导致，请稍后重试。如果问题一直持续，请联系系统管理员或者技术支持处理。   1. 通过HCI前台检查虚拟机为链式派生虚拟机，发现存在外部快照。 2. 通过排查HCI前台操作日志，发现对虚拟机执行全量克隆或全量克隆虚拟机快照，全部失败。 3. 通过排查操作日志中涉及HCI主机后台的mdisk-agent-rpc日志mdisk-agent-rpc.log，找到关键报错：Could not open '/sf/data/xxx': No such file or directory，说明：不能打开磁盘。 vim /sf/log/[日期]/vmdisk-agent-rpc.log 4. 通过排查HCI前台，发现：虚拟机运行位置所在HCI主机不能访问克隆的目标存储。   链式虚拟机存在外部快照情况下进行克隆或进行快照克隆时，最后一步会进行磁盘convert和rename，这两个操作在执行时中并未进行调度而是直接在运行位置所在HCI主机操作。 临时规避方案 配置虚拟机运行的主机能访问克隆的目标存储。 彻底解决方案 TD2025032000368。已在HCI6.11.1版本优化，可将当前版本升级至HCI6.11.1及以上版本。  操作影响： 平台升级可能会重启主机和影响业务，更多具体影响可参见版本的升级指导。          

  检查主机内存条是否有ecc或者uecc错误   检查主机的CPU、内存是否存在降频   检查主机的raid卡是否卡慢或者报错   1、  内存CE检查 a）可纠正ECC控制台检查：控制台告警“内存可纠正错误过高”，这个还需结合后台日志确认 b）可纠正ECC后台检查：检查ecc条目累计10w以上，或者每小时增长6000以上，即为异常。  命令（有两种）：  grep [0-9] /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count grep "[0-9]" /sys/devices/system/edac/mc/mc*/csrow*/ch*   c）不可纠正ECC控制台检查：控制台告警“检测到主机内存出现不可修正的内存错误”，则为异常。 d）不可纠正ECC后台检查：如提示有UEC或者Uncorrectable ECC，则为异常  命令：modprobe ipmi_msghandler;modprobe ipmi_devintf;modprobe ipmi_si;ipmitool -I open sel elist e) 不可纠正ECC后台检查：UE_count值不为0则为异常，UE_error_sign值不为0为异常，index里对应的故障槽位 命令：cat /var/ECC_data | tail   2、  CPU内存降频  a）CPU降频控制台检查：确认告警日志输出“CPUxx降频”或者“CPU温度过高” b）CPU降频后台检查：Bzy_MHz值小于TSC_MHz值的70%即为降频  命令：  ssh -p 25022 localhost        ##680及以上版本需要执行该命令，进入vt容器，这里的localhost可以替换为对应的主机IP echo $$ > /mnt/cgroup/cpu/tasks; turbostat         ##不支持arm环境 c）内存降频后台检查：如果输出的值多次小于1GB/Sec即为降频（在主机负载过高的情况下进行判断可能会不准确）  命令：  ssh -p 25022 localhost ##680及以上版本需要执行该命令，进入vt容器，这里的localhost可以替换为对应的主机IP watch -n 2 perf bench mem all ## 每隔2s执行一次perf bench mem all，ctrl+c停止，可以让该命令执行16s左右 3、  raid卡或其他硬件故障    故障服务器，能ping通但ssh无法登录，接显示器用键鼠输入无响应，web页面显示虚拟机挂起 （2、3不便确认的情况下，可以只判断1）    如有条件，可以在对应日期的内核日志中确认是否有硬件error日志，或dump打印的kernel timeout日志，指向系统io超时，需要检查硬盘卡慢。 3、  检查IPMI日志是否有其他硬件异常告警（可以直接登录IPMI查询，也可以直接用下图命令直接后台打印IPMI日志）  命令：modprobe ipmi_msghandler;modprobe ipmi_devintf;modprobe ipmi_si;ipmitool -I open sel elist       1、【快速恢复】隔离主机存储网络 a）虚拟存储场景： 方式1：进机房，将虚拟存储口网线拔掉 方式2：将故障主机从集群隔离出去，登入任意正常的主机，执行如下命令进行隔离：     ssh -p 25022 localhost ##680及以后版本执行这条，才能用vs_cluster_cmd.sh      vs_cluster_cmd.sh e " iptables -I OUTPUT -d <存储口IP>/32 -j REJECT "     #故障主机修复后，通过下面的命令取消隔离掉假死的主机：     #ssh -p 25022 localhost ##680及以后版本执行这条，才能用vs_cluster_cmd.sh      #vs_cluster_cmd.sh e " iptables -D OUTPUT -d <存储口IP>/32 -j REJECT "  b)外置存储场景：  方式1：进机房，将对应主机的外置存储口网线拔掉  方式2：ssh到对应主机上，后台手动down存储口     ifconfig ethX down （ethX为实际故障网口，FC存储只能去机房拔线路）   2、  【后置处理】故障硬件更换    内存返修硬件产品-深信服技术支持   CPU降频硬件产品-深信服技术支持   raid卡固件和故障：深信服科技股份有限公司          

虚拟机备份失败后触发HA恢复 虚拟机HA恢复 1、虚拟机备份失败后立即HA恢复 2、虚拟备份时的主机，其qemu里面有日志/sf/log/today/sfvt_qemu_{vmid}.log 1、虚拟机IO过大，多协程对备份临时文件进行truncate发生冲突。根本原因是：客户的存储太好了，虚拟机IO过大，备份多协程同时操作临时文件引发的。 1、若已经出现，需暂时停止备份，并立即升级版本或者最新合集补丁包。 2、版本解决情况： 2、1 6.11.1及以上的版本已经解决（内部TD2024060400245）； 2、2 合集补丁修复情况： （1）6.3.0R3、6.8.0、6.8.0R1、6.8.0R2、6.10.0R1最新合集补丁已修复； 取包地址：https://support.sangfor.com.cn/productSoftware/list?product_id=33&category_id=12 （2）6.10.0R2合集补丁已在2025.4.12修复； 问题虚拟机 是 问题现象： 1、虚拟机备份失败后立即HA，虚拟机的qemu日志中含有truncate的assert日志。 解决方案： 1、若已经出现，需暂时停止备份，并立即升级版本或者最新合集补丁包。 2、版本解决情况： 2、1 6.11.1及以上的版本已经解决（内部TD2024060400245）； 2、2 合集补丁修复情况： （1）6.3.0R3、6.8.0、6.8.0R1、6.8.0R2、6.10.0R1最新合集补丁已修复； 取包地址：https://support.sangfor.com.cn/productSoftware/list?product_id=33&category_id=12 （2）6.10.0R2合集补丁已在2025.4.12修复； 前台日志，后台日志

在VMware上创建虚拟机使用ovf模板的方式部署仲裁主机，导入模板时提示有兼容性问题，换用iso安装的方式部署仲裁主机，部署时直接在vmware上新建虚拟机配置两个新的容量大于100G的磁盘，然后使用在深信服社区下载的仲裁主机模板进行安装，创建完成后在HCI上创建卷时报错。 [size=13.3333px]主机x.x.x.x硬盘配置不符合要求，请为主机配置-块仲裁盘，并且要求仲裁盘容量大于100G 479015ec4cd1730f48.png (191.98 KB)   1、通过vmware上创建一台（虚拟机配置需要8核32G，两块500G的独立磁盘）虚拟机作为仲裁机。 2、然后通过iso方式安装仲裁机。 3、然后在acloud上创建卷，创建延伸卷，选择仲裁节点时提示：‘[size=13.3333px]主机x.x.x.x硬盘配置不符合要求，请为主机配置-块仲裁盘，并且要求仲裁盘容量大于100G’。 4、通过在vmware上更改虚拟机高级配置，增加disk. enableuuid=true的配置参数。 5、然后测试重新添加延伸集群，成功创建延伸卷。 vmware上配置了磁盘后，acloud平台无法直接识别到磁盘，需要更改vmware上虚拟机参数，让acloud可以识别到磁盘。 关机虚拟机更改参数之后重启，避免在开机过程中修改，然后重启，避免参数没有被加载 1、通过登录vmware控制台管理界面，找到对应的HCI仲裁虚拟机，右键选择【编辑设置】 339325ec50702182fa.png (119.15 KB)   2、在【虚拟机选项】中选择【高级】，并下拉找到【编辑设置】 22975ec50762bb299.png (101.66 KB)   142685ec507701d444.png (37.4 KB)   3、在编辑界面中新增一个键值对【disk. enableuuid】【true】，然后保存。（如果已经有disk.enableuuid这个值，直接改对应的值为true即可） 552625ec50787318eb.png (33.32 KB)   如果使用ovf模板的方式部署仲裁主机出现异常时，可以尝试iso安装作为备选方案，使用iso安装时可以参考如上案例，案例中是vmware版本是：VMware ESXi, 6.0.0, 3620759

编辑端口组报错：服务不可用，系统繁忙 无 1.检查端口组是否连接了路由器   2.检查编辑端口组之前是否有过编辑虚拟机网卡的操作（操作日志可能很久以前了，如果没有找到，可以直接看第三步）   3.登录HCI主控，检查日志中是否存在如下报错： vim /sf/log/today/vn/vn-manager-service-api.log 关键字：AttributeError: 'IfaceSqlBase' object has no attribute 'vrouter' 级联框架管理类CascadeManager为单例模式，只会在mp启动和重启时进行初始化，先执行更新虚拟机网口操作时， 会将CascadeManager().Interface.evrif_obj改为1.1版本 执行端口组更新时，CascadeManager().Interface.evrif_obj已经被改为了1.1版本，按正常流程应执行1.0版本，而1.1版本的interface_api没有vrouter属性， 因此执行self.interface_api.vrouter.update_interfaces()失败报错 临时解决方案：可以在端口组临时创建一个新端口组，创建成功后，编辑原来的端口组，随后再删除刚才创建的新端口组。 永久解决方案：升级到HCI6.11.1版本 无 否 无 无

插拔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   [15804344.996848] INFO: task spicec:25164 blocked for more than 120 seconds. [15804344.996850] Tainted: G O --------- -t - 4.18.0-6.9.0 #1 [15804344.996851] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [15804344.996852] spicec D 0 25164 84257 0x00004000 [15804344.996855] Call Trace: [15804344.996862] ? __schedule+0x3c9/0x630 [15804344.996865] ? enqueue_entity+0x139/0x640 [15804344.996866] schedule+0x39/0xa0 [15804344.996868] schedule_timeout+0x1d6/0x2d0 [15804344.996871] ? check_preempt_curr+0x50/0x90 [15804344.996872] ? ttwu_do_wakeup+0x19/0x140 [15804344.996873] wait_for_completion+0xa3/0x120 [15804344.996874] ? wake_up_q+0x60/0x60 [15804344.996880] kthread_stop+0x43/0x100 [15804344.996883] release_everything+0x26/0xa0 [usb_storage] [15804344.996887] usb_unbind_interface+0x79/0x270 [15804344.996890] device_release_driver_internal+0xeb/0x1c0 [15804344.996891] proc_disconnect_claim+0x9b/0x100 [15804344.996893] usbdev_do_ioctl+0xd0e/0x1120 [15804344.996896] ? bConfigurationValue_show+0x53/0x70 [15804344.996897] usbdev_ioctl+0xa/0x10 [15804344.996900] do_vfs_ioctl+0x91/0x5f0 [15804344.996901] ? _cond_resched+0x16/0x40 [15804344.996903] ksys_ioctl+0x66/0x70 [15804344.996904] __x64_sys_ioctl+0x16/0x20 [15804344.996906] do_syscall_64+0x5b/0x1d0 [15804344.996908] entry_SYSCALL_64_after_hwframe+0x65/0xca [15804344.996912] RIP: 0033:0x7f8480b09f47 [15804344.996915] Code: Bad RIP value. [15804344.996916] RSP: 002b:00007f847e7d36a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [15804344.996917] RAX: ffffffffffffffda RBX: 00007f8478000b90 RCX: 00007f8480b09f47 [15804344.996918] RDX: 00007f847e7d36b0 RSI: 000000008108551b RDI: 000000000000001d [15804344.996918] RBP: 0000000000000000 R08: 00007f8478000b90 R09: 0000000000000000 [15804344.996919] R10: 0000000000000092 R11: 0000000000000202 R12: 0000000000000000 [15804344.996920] R13: 0000000000000001 R14: 0000000000000000 R15: 00000000020cdf80 [15804465.828790] INFO: task spicec:25164 blocked for more than 120 seconds. [15804465.828792] Tainted: G O --------- -t - 4.18.0-6.9.0 #1 [15804465.828792] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [15804465.828793] spicec D 0 25164 84257 0x00004000 [15804465.828796] Call Trace: [15804465.828803] ? __schedule+0x3c9/0x630 [15804465.828806] ? enqueue_entity+0x139/0x640 [15804465.828807] schedule+0x39/0xa0 [15804465.828809] schedule_timeout+0x1d6/0x2d0 [15804465.828812] ? check_preempt_curr+0x50/0x90 [15804465.828813] ? ttwu_do_wakeup+0x19/0x140 [15804465.828814] wait_for_completion+0xa3/0x120 [15804465.828816] ? wake_up_q+0x60/0x60 [15804465.828821] kthread_stop+0x43/0x100 [15804465.828825] release_everything+0x26/0xa0 [usb_storage] [15804465.828829] usb_unbind_interface+0x79/0x270 [15804465.828832] device_release_driver_internal+0xeb/0x1c0 [15804465.828834] proc_disconnect_claim+0x9b/0x100 [15804465.828836] usbdev_do_ioctl+0xd0e/0x1120 [15804465.828839] ? bConfigurationValue_show+0x53/0x70 [15804465.828840] usbdev_ioctl+0xa/0x10 [15804465.828844] do_vfs_ioctl+0x91/0x5f0 [15804465.828845] ? _cond_resched+0x16/0x40 [15804465.828847] ksys_ioctl+0x66/0x70 [15804465.828848] __x64_sys_ioctl+0x16/0x20 [15804465.828851] do_syscall_64+0x5b/0x1d0 [15804465.828852] entry_SYSCALL_64_after_hwframe+0x65/0xca [15804465.828857] RIP: 0033:0x7f8480b09f47 [15804465.828860] Code: Bad RIP value. [15804465.828861] RSP: 002b:00007f847e7d36a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 [15804465.828862] RAX: ffffffffffffffda RBX: 00007f8478000b90 RCX: 00007f8480b09f47 [15804465.828863] RDX: 00007f847e7d36b0 RSI: 000000008108551b RDI: 000000000000001d [15804465.828864] RBP: 0000000000000000 R08: 00007f8478000b90 R09: 0000000000000000 [15804465.828865] R10: 0000000000000092 R11: 0000000000000202 R12: 0000000000000000 [15804465.828865] R13: 0000000000000001 R14: 0000000000000000 R15: 00000000020cdf80 [15804562.556342] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [15804562.556476] PGD 0 [15804562.556516] Oops: 0010 [#1] SMP NOPTI [15804562.556583] CPU: 41 PID: 101811 Comm: usb-storage Kdump: loaded Tainted: G O --------- -t - 4.18.0-6.9.0 #1 [15804562.556763] Hardware name: SANGFOR 5280M6/WI2HR-212T1031A, BIOS 06.00.04 07/05/2022 [15804562.556895] RIP: 0010:0x0 [15804562.556945] Code: Bad RIP value. [15804562.557002] RSP: 0018:ffa0000032e9feb8 EFLAGS: 00010286 [15804562.557093] RAX: 0000000000000000 RBX: ff1100fa439a4a48 RCX: 0000000000000000 [15804562.557213] RDX: ff11007e32e94000 RSI: 00000000000000ff RDI: ff11007a245504e8 [15804562.557334] RBP: ff11007a245504e8 R08: 0000000000000000 R09: 0000000000000000 [15804562.557455] R10: ffa0000032e9fbe0 R11: 0000000000000000 R12: ff1100fa439a4b90 [15804562.557576] R13: ff1100fa439a4bb0 R14: 0000000000000000 R15: ffffffffa0d3d310 [15804562.557697] FS: 0000000000000000(0000) GS:ff1100807e680000(0000) knlGS:0000000000000000 [15804562.557832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [15804562.557930] CR2: ffffffffffffffd6 CR3: 000000000481c001 CR4: 0000000000763ee0 [15804562.558051] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [15804562.558172] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [15804562.558293] PKRU: 55555554 [15804562.558344] Call Trace: [15804562.558398] usb_stor_control_thread+0x258/0x260 [usb_storage] [15804562.558501] kthread+0xf8/0x130 [15804562.561607] ? kthread_destroy_worker+0x40/0x40 [15804562.564689] ret_from_fork+0x1f/0x40 [15804562.567630] Modules linked in: dm_round_robin usb_storage iptable_nat nf_nat_ipv4 nf_nat nfsv3 bonding xt_comment rpcsec_gss_krb5 nfsv4 dns_resolver ipt_REJECT nf_reject_ipv4 fuse nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc ramoops reed_solomon act_gact cls_u32 sch_ingress 8021q garp mrp vhost_net vhost tap mlx5_ib(O) mlx5_core(O) mlxfw tls(t) ib_uverbs(O) nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack libcrc32c crc32c_intel ip6table_filter ip6_tables iptable_filter ip_tables ib_iser(O) rdma_cm(O) iw_cm(O) ib_cm(O) ib_core(O) mlx_compat(O) iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vfio_pci vfio_virqfd vfio_iommu_type1 vfio igb(O) i2c_algo_bit i40e(O) dm_multipath mlx4_en mlx4_core tipc ip6_udp_tunnel udp_tunnel tun nbd i10nm_edac nfit libnvdimm k10temp coretemp bridge stp llc watch_reboot sffs(O) cl_lock(O) cl_softdog(O) kvm_intel kvm irqbypass squashfs overlay loop dm_mod sg sd_mod ses enclosure usbhid iTCO_wdt iTCO_vendor_support ahci smartpqi(O) libahci [15804562.567672] pcspkr libata scsi_transport_sas i2c_i801 i2c_core ioatdma dca wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_cpufreq acpi_power_meter sch_fq_codel [last unloaded: i2c_algo_bit] [15804562.608183] Features: eBPF/event [15804562.612890] CR2: 0000000000000000 Begin dump core ... 观察是否存在 [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，升级后即可解决。 6.10.0版本已解决第二类的堆栈问题 TD2023112800180 第一类问题预计2025年6月30日出包合集补丁第二个得看下是否为FTKey，其他的Key可能得手动屏蔽掉，合集补丁6.10.0R2只处理掉了FTkey 升级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不一致的情况。      

1、确认存储网络生效和网络配置、交换机部署是否匹配，不匹配会导致丢包/不通   1、无链路聚合场景：存储口单拉的网线到存储交换机，检查存储交换机是否有多余配置vlan的情况，通常情况交换机上将存储网口单独划入一个VLAN中，防止其他网络的广播组播报文发送到虚拟存储网络中影响存储网络稳定性。   2、单交换机链路聚合：再次强调，虽然名称带有链路聚合，实际上交换机处是无需配置聚合的，如果检查存储交换机有配置聚合，需要清空聚合配置；有堆叠的场景，注意通常堆叠交换机之间是不会有网线直连的；防止存储数据走交换机的中间连线转发，导致性能瓶颈。如果是两台交换机堆叠的组网。建议主机的两个存储口分别连接到两台交换机上，防止交换机单点故障引起虚拟存储网络中断。 *补充：信锐交换机配置mlag，也是通常选择单交换机链路聚合场景；注意不需要配置mlag成员组；这里是指两个交换机配置mlag对接后就不需要在虚拟存储口里面添加mlag聚合组了。 3、双交换机链路聚合：每台主机的存储口是分别连到两个交换机上，检查接线的时候一定要看清楚交换机端口；也是不需要对交换机进行聚合口配置的。 *补充：信锐交换机场景。虚拟存储口与管理口都在交换机上，并且管理口配置了M-LAG的场景。建议交换机的心跳线使用万兆心跳线或者是两台交换机上的存储口分别属于不同的VLAN不互通   4、标准链路聚合：检查对端聚合协商模式与算法是否一致 页面查看组网模式 实体机-网口功能-存储通信口-当前存储通信部署方式：xxx 服务器查看组网模式:  命令为vs_cluster_cmd.sh e "cat /sys/class/net/sf_vs_bond0/bonding/mode" 对于单、双链路聚合聚合口为sf_vs_bond0；单链路聚合mode为7、双交换机链路聚合mode为0 排查示例： 如下图所示，有2台主机是 mode 7，其他主机是 mode 0，模式不同，逻辑产生冲突导致丢包。   原因是：同一个集群存储网络链路聚合的模式不同，发包逻辑存在冲突导致丢包。   交换机查看组网模式：  先理清楚客户的虚拟存储网络是无链路聚合、单链路聚合、双交换机链路聚合，标准链路聚合，（网口复用情况以抓包分析为主，后面给出）。 A）存储单链路聚合+交换机堆叠或者配置 mlag。【mlag指的是信锐的交换机】， B）存储双链路聚合+两个傻瓜式交换机 C）存储无链路聚合+交换机 1 个 D）存储标准链路聚合+交换机 2个并堆叠   E）需要客户提供网络拓扑图判断；单交换机链路聚合模式2台交换机需要配置堆叠或者mlag，双交换机链路聚合2个交换机不需要配置堆叠，如果配置有问题需要先调整配置 （常见问题：ping出现dedup包，说明有环路；丢包50%） 总结：如果服务器组网模式和交换机组网模式不匹配导致存储网络丢包问题，做变更可以找研发确认方案   服务器和交换机侧的组网模式需要一致，参考上述判断方式    

1、管理口丢包情况下的数据包文件 2、HCI网络医生工具检查结果 工具链接点击这里 3、关键的网卡日志信息截图       问题转研发模板 【版本信息】 版本信息，包含补丁信息 【问题现象】 对应网口丢包现象情况 【业务影响情况】  确认影响范围，是个别终端受影响还是核心业务 【客户诉求】 客户的诉求 【当前排查情况】 如报错前后的日志，是否有符合的kb、网卡型号等 HCI网络医生工具检查结果        

1、页面出现VXLAN不同/丢包告警 2、一键检测报错VXLAN不通   可能原因 检查内容 检查操作链接 VXLAN大包不通 页面一键检测：1、勾选系统配置检测-网口配置检测 2、勾选硬件健康检测-网卡检测 查看是否有异常报错 点击跳转 VXLAN聚合口配置异常 检查本端与对端聚合配置是否一致 点击跳转 VXLAN业务复用场景下的性能不足导致丢包 1、网口流量是否过大：检查管理口流量是否突然陡增，聚合口带宽被打满 2、聚合成员口流量是否偏载：检查聚合成员口之间流量差异过大，一侧流量已超过单网口带宽导致丢包，可以通过配置四层算法的聚合传输模式优化 点击跳转 外部网络丢包 1、抓包定位分析是否外部网络问题导致丢包 点击跳转 网卡硬件问题 1、检查存储网卡是否硬件故障 点击跳转   案例库标题 涉及版本 6.2.30升级预警补丁导致VXLAN不通PC长ping管理口间断性丢包或延时高 6.2.30 网卡假死导致VxLAN口某些主机能通，某些不能通 670R3 华为交换机未开启igmp_snooping导致VxLAN组播通信不通 670之前 670之前 集群扩容后新加入主机vxlan不通，后台检查新加入主机无vxlan ip 6.10.0之前 数据面mbuf内存泄漏导致网络中断 681之前 系统内存耗尽导致转发进程dataplane进入 D 状态影响业务 通用        

1、管理口丢包情况下的数据包文件 2、HCI网络医生工具检查结果 工具链接点击这里 3、关键的网卡日志信息截图       问题转研发模板 【版本信息】 版本信息，包含补丁信息 【问题现象】 对应网口丢包现象情况 【业务影响情况】  确认影响范围，是个别终端受影响还是核心业务 【客户诉求】 客户的诉求 【当前排查情况】 如报错前后的日志，是否有符合的kb、网卡型号等 HCI网络医生工具检查结果        

外部网络问题通过抓包定位管理口丢包/不通原因     1、前端页面出现主机离线，或管理口丢包告警  2、排除网卡硬件故障，以及内部服务异常导致丢包，即可初步判断为外部网络异常导致丢包   1.首先了解下几个工具   工具1：确认管理口是否接管(680以后进VN容器执行container_exec -n vn-a)   echo -e "show interface-take-over" | cli       工具2：抓包【HCI-VN】后台抓包方法。有现场的时候离不开抓包 接管了绑pcap抓，未接管直接抓 工具3：网口丢包统计 【HCI-VN】物理出口参数以及网口参数指南。 基本统计： echo -e "show interface eth1" | cli |grep -E "Drop|Err" // 接管情况下 ifconfig eth0// 非接管情况下 详细统计： echo -e "show interface ethx xstats" | cli | grep -E "drop|err"// 接管情况下 realethtool -S ethx | cli | grep -E "drop|err"// 非接管情况下 工具4：黑盒 LOG_ping_statistic.txt// 管理网ping的黑盒 LOG_ethtool_statistic.txt // 采集网口信息   2、不同丢包情况下的判断方式 管理口丢包有现象时： 1.确认是否接管 2.抓包 (确认源、目的；源是否发出、目的是否收到、目的是否回包、源是否收到) 3.丢包时，多次执行网口丢包统计，是否有计数值增长 4.页面查看主机网口流量大小 管理口 是否接管 如何抓包 丢包时怎么查看是否网卡丢包导致 如何确认是物理网络丢包 是 是 绑pcap抓 多次执行 echo -e "show interface ethx xstats" | cli | grep -E "drop|err"查看是否有值增长，有值增长可能是网卡丢包 网卡丢包统计无增长，则可以判定为物理网络问题 是 否 直接抓 多次执行 realethtool -S ethx | grep -E "drop|err"查看是否有值增长，有值增长可能是网卡丢包 网卡丢包统计无增长，则可以判定为物理网络问题   管理口丢包无现象时： 1.确认是否接管 2.如果未接管查看黑盒LOG_ethtool_statistic.txt，丢包时间是否有计数值在增长；执行一次 realethtool -S ethx| grep -E "drop|err" 看哪一项计数值比较大作为怀疑 如果接管了执行一次echo -e "show interface ethx xstats" | cli | grep -E "drop|err" 看哪一项计数值比较大作为怀疑 3.页面查看主机网口流量大小 4.查看LOG_ping_statistic.txt是单主机问题还是所有主机，如果所有主机之间互ping不通，则大概率是物理网络问题导致 管理口 是否接管 如何怀疑丢包是否网卡丢包导致   是 是 执行一次 echo -e "show interface ethx xstats" | cli | grep -E "drop|err" 看哪一项计数值比较大   是 否 执行一次 realethtool -S ethx | grep -E "drop|err" 看哪一项计数值比较大 查看黑盒丢包时间LOG_ethtool_statistic.txt 是否有丢包项增长 无现场时不好确认问题，必要时可部署抓包脚本等待问题复现。抓包监控方法--点击这里   外部网络问题需要协同网络环境设备侧解决，仅提供抓包判断方法 1.以上内容均为单网口总结 如果是聚合口，可以对聚合口成员口分开抓包、分开查看网口丢包统计确认问题 2.网口计数丢包项解释如下 以igb网卡为例： realethtool -S eth5 //585之前的版本使用ethtool NIC statistics: rx_packets: 402042807 //接收包数量 tx_packets: 1889435 //发送包数量 rx_bytes: 71219476828 //接收字节 tx_bytes: 168570198 //发送字节 rx_broadcast: 356939859 //接收广播包数量 tx_broadcast: 238362 //发送广播包数量 rx_multicast: 44838071 //接收组播包数量 tx_multicast: 1488303 //发送组播包数量 rx_crc_errors: 840 //CRC校验和错包，一般是硬件的问题，可以尝试 拔插网线 rx_no_buffer_count: 0 //接收缓存不够，一般是应该程序处理比较慢，需 要看看CPU/内存占用情况 rx_long_length_errors: 0 // 接收到的报文长度超过MTU rx_short_length_errors: 0 // 接收到的报文长度小于64字节 rx_errors: 1316 // 接收方向有错包，需要看其他选项确定是什么 样的错包 tx_errors: 0 // 发送方向有错包 tx_dropped: 0 // 发送方向有丢包 rx_length_errors: 0 // 报文MAC头的长度字段与报文长度不匹配，这里应该说的是帧头 rx_over_errors: 0 // 报文长度错误   问题1：为什么抓包看到没收到包还需要执行网卡丢包统计命令确认是否丢包？ 因为数据包会经过驱动、内核，抓包的数据来源是内核、网口丢包统计数据的来源是驱动。其原理见下图。 问题2：接管后网口又有内核口、又有p口他们的关系是怎样的 他们的关系见下图，参考【HCI-VN】后台抓包方法  

集群中管理口组播有问题，集群中主机之间chping不通或者时通时断   当符合下列现象时，可以初步确定为管理网组播不通导致的管理网异常： 1、主机互相ping能通，主机其他网口功能测试主机连通性正常（存储、vxlan等） 2、chping 主机hostname不通   可以通过chping主机名称确认，组播不通会导致sdnagentd与sdnctrld离线 ，在sdnagentd与sdnctrld日志里可以找到，组播依赖于host_proxy服务，还可通过netstat -anulp命令查看host_proxy代理服务监听的ip和端口。 说明 chping命令主要用于检查集群中主机的管理口和组播通信是否有问题，集群中的组播是通过host_proxy代理服务来进行通信的，源端发送组播，目的端回复单播。   获取集群的主机id vtpclustat   通过chping来判断组播是否丢包或不通，如果出现timeout或者丢包都表示组播有问题。 # HCI 6.8.0及以上版本进入asv容器container_exec -n asv-cchping [主机名称] 说明 也可以不进入容器，将脚本chping脚本上传到HCI后台并添加可执行权限（chmod +x chping），执行./chping [主机名称]     检查主机配置文件和主机名映射关系。 cat /etc/host   获取组播IP地址。 cat /cfs/cluster.ini# 或者netstat -anulp 因为组播依赖host_proxy服务，所以主要查找host_proxy关键所在行的IP   查看集群各主机的组播地址是否有不同。 # HCI 6.8.0及以上版本进入vs容器container_exec -n vsvs_cluster_cmd.sh e 'netstat -anulp | grep 6162' 一般来说同集群不同主机的组播地址是相同的，如果不同，检查是否存在双系统盘，系统盘在开机前后挂载不一致导致的组播地址不一致，案例可参见【HCI-VN】系统盘挂载错误导致组播不通。   通过组播IP对管理口进行抓包。 tcpdump -nei ethX dst [组播IP地址]tcpdump -nei ethX host [组播IP] and host [对端主机IP] and udp and prot 6162# 如果是聚合口ethX也可换成channelX 正常能抓包对应的组播报文如下   查看日志host_proxy日志。 交换机IGMP Snooping抑制组播数据泛洪功能影响 说明 IGMP Snoping（Internet Group Management Protocol Sno0ping，互联网管理协议窥探）：是运行在二层设备上的组播约束机制，通过侦听和分析主机与三层组播设备之间交互的IGMP协议报文建立二层组播转发表项，以管理和控制组播在二层按需转发，从而抑制组播数据在二层网络中扩散（或者泛洪），有时候也叫组播抑制（不规范叫法）。 由于交换机类型或网络配置环境不同，是否开启IGMP Snooping功能也有所差异，使用该功能时请注意查看交换机的文档对该功能是否有特殊说明。例如有些配置了堆叠的交换机不支持IGMP Snooping，开启后可能会导致不同交换机之间组播无法正常传递；也有部分类型如华为交换机在全局或VLAN的二层组播配置错误时未使能IGMP Snooping导致二层组播流量不通的情况。 因此当chping不通进行故障排查的时候可以先尝试将二层交换机的IGMP Snooping功能关闭以便判断故障原因。 不同交换机开启/关闭IGMP Snooping的方法不同，具体参见对应交换机的产品手册。   防火墙规则未放通 查看组播不通主机防火墙规则是否正常以及6162端口是否放通 iptables -nL CLUSTER_MEMBERS_INPUT | grep "ACCEPT" | sed '$d';echo -e;netstat -lnpu | grep 6162 输出IP即为防火墙放通的IP，包含集群中所有主机的IP则正常。以下为正常输出情况： 如果防火墙规则中有未放通的集群主机，需执行redis-acl.sh脚本进行放通。 说明 630前该脚本在/sf/etc/hook.d/cluster/cluster-stable.d目录下，630移到了/sf/etc/hook.d/cluster/cluster-stable-nonblock.d目录中   网络环路 网络中的环路会导致设备对广播、组播以及未知单播等报文进行重复发送，造成网络资源浪费甚至网络瘫痪。若要判断网络中是否存在环路，具体可参见【HCI-VN】网络环路问题判断方法（持续更新）。   host_proxy服务异常 前面提到组播依赖host_proxy服务，若host_proxy服务异常，那组播肯定也有问题，可通过sfvt_host_proxy.log日志确认host_proxy服务是否有问题。 若sfvt_host_proxy.log日志有提示“host_proxy_socket:554 [hp_send_pkg_other_host_msg] send pkg failed, pkgid:”，可参见案例【HCI-VN】host_proxy服务异常导致管理口组播不通处理   pmxcfs和corosync服务异常 查看pmxcfs和corosync服务异常会影响组播的传递，检查pmxcfs和corosync服务状态 # HCI 6.8.0及以上版本需进入asv容器container_exec -n asv-c# 查看pmxcfs和corosync服务状态/sf/etc/init.d/pmxcfs status;/sf/etc/init.d/corosync status 正常情况如下 如果pmxcfs和corosync服务异常或没起来 说明 启动主机的pmxcfs和coro sync的服务不影响业务。 重启主机的pmxcfs和coro sync的服务可能会导致平台短时间内不稳定，但是不影响业务。 # 启动corosync服务/sf/etc/init.d/corosync start# 启动pmxcfs服务/sf/etc/init.d/pmxcfs start# 重启pmxcfs服务和corosync服务/sf/etc/init.d/corosync restart;/sf/etc/init.d/pmxcfs restart   网卡非混杂模式下不接收组播数据包，导致组播不通 网卡非混杂模式下只会接收目的MAC地址是它自己的单播帧以及多播帧或广播帧，而组播数据包的目的MAC地址通常不是网卡的MAC地址，因此组播在经过非混杂模式下的网卡时会受阻导致组播不通。 网卡混杂模式时会接收所有经过它的数据流，不论数据包的目的地址是否为它都会接收，即混杂模式下网卡会接收所有发往它的数据包，包括数据组播包。 因此组播不通时需要查看内核日志和网口信息是否对应时间点有网卡为非混杂模式 cat /sf/log/{日期]/kernrl.log   如果有，需要把对应的网卡手动设置为混杂模式 # 手动修改网卡为混杂模式ifconfig ethX promisc# 查看网卡是否修改成功ifconfig ethX        

1、外部网络丢包 2、网卡硬件问题导致丢包 3、管理业务复用场景下的性能不足导致丢包   可能原因 检查内容 检查操作链接 管理口组播不通 页面一键检测：1、勾选系统配置检测-网口配置检测  2、勾选硬件健康检测-网卡检测    查看是否有异常报错 点击跳转 管理聚合口配置异常 检查本端与对端聚合配置是否一致 点击跳转 管理业务复用场景下的性能不足导致丢包 1、网口流量是否过大：检查管理口流量是否突然陡增，聚合口带宽被打满 2、聚合成员口流量是否偏载：检查聚合成员口之间流量差异过大，一侧流量已超过单网口带宽导致丢包，可以通过配置四层算法的聚合传输模式优化 点击跳转 外部网络丢包 1、抓包定位分析是否外部网络问题导致丢包 点击跳转 网卡硬件问题 1、检查存储网卡是否硬件故障 点击跳转   案例库名称 涉及版本 问题现象 问题原因 解决方案 PC长ping管理口间断性丢包或延时高 通用 PC长ping管理口间断性丢包或延时高 错误包类型是RX_fifo_error，此类错误是网口缓存不够导致 临时修改网口缓存：realethtool -G eth0 rx 2048（实际值决定）临时修改，重启失效。然后再使用观察一段时间 看fifo值是否会持续增加 X710/X722存储复用/四网合一场景下，周期性断网或者抓包断网 6.11.0之前 x710/x722网卡，开启存储口复用功能，对VF口（主要是开启复用之后创建出来的channel17和channel18）进行抓包会导致PF口（其他功能口，一般是vxlan口）收不到包   1、x710/x722网卡开启trust on特性并开启四网创建PF和VF口之后，对VF口进行抓包导致PF口收不到包   2、目前看跟网卡硬件本身的实现有关系，包都被VF收上去了，导致PF异常 版本内的解决方案是将聚合口和其他角色口的mac地址下发到PF口，使包收到网卡之后，能正常通过网卡内部fdb表转发到PF口 6.11.0已修复该问题 插拔一台主机的某个网口整个集群网络会丢包 通用 插拔一台主机的某个网口整个集群网络会丢包 交换机开启MSTP生成树之后，有网口发生down up就会触发生成树收敛，导致所有接口发生丢包 将服务器相关网口设置为边缘端口 DP异常退出导致主机发生离线（管理业务复用） 通用 主机离线 内存不足导致dp超时被杀掉，管理口是被接管的所以主机离线 扩容内存 因MCE内存报错导致dp出core（管理业务复用） 通用 主机离线 主机内存条出现异常，当虚拟机使用到异常内存给dataplane网络服务发包时，传递的异常内存地址导致dataplane访问出core，导致虚拟网络服务重启，从而主机网口有离线、数据口不通告警   临时解决办法   如果是单个虚拟机业务一直中断，其他虚拟机正常，可重启虚拟机临时恢复。 如果内存异常导致主机卡慢、多个虚拟机网络中断以及页面有网口离线、数据口网络不通告警等问题，建议将异常主机的虚拟机全部迁移到其他正常主机，避免再次影响业务。   彻底解决办法   需要更换问题主机内存条        

现象一：告警提示-检测到主机（IP）的硬盘（硬盘SN）被拔出，如果是误拔，请尽快把硬盘重新插回原盘位! 现象二：告警提示-硬盘已经离线，如果是误拔盘，请马上把盘重新插回原盘位；如果不是误拔盘，可能硬盘已经损坏，请更换该盘。 现象三：扩容虚拟存储卷、新建虚拟存储卷或替换硬盘时，无法识别到硬盘。       根据如下流程图进行排查： //raid卡相关操作请参考StorCLI工具常用命令，如“查询硬盘信息”、“设置硬盘直通功能”、“维护外部配置”等。 可能原因 检查项 检查操作链接 raid卡状态识别磁盘异常 ①确认磁盘是否于raid卡上是否在位 ②检查磁盘在raid卡上状态是否正确 跳转链接 物理硬件本身存在异常 ①检查raid卡是否本身硬件存在异常 ②检查背板和sas线是否存在异常 ③检查磁盘本身是否存在异常 跳转链接 软件配置导致异常 ①检查磁盘配置json文件 ②检查是否卡慢盘标记等导致异常 ③检查一体机磁盘是否签名 跳转链接 存储网络不通 检查存储网是否丢包或者不通 跳转链接          

  主机CPU资源耗尽   主机内存资源耗尽    //如检查为CPU、内存耗尽导致，无法评估是什么服务占用，可以跟专家确认或拉通研发确认  检查CPU资源 a）控制台检查：在控制台的【首页】或者【实体机】页面关注服务器的资源使用率情况，只需看CPU使用率或内存使用率是否持续在95%及以上，如是，则异常。 b）检查CPU资源使用过高超过阈值告警日志 c）检查主机详情界面CPU使用率趋势图 d）后台检查每个CPU核数的繁忙度，关注%idle参数。%idle数值代表CPU核数的空闲率，越低表示该核数越繁忙，如果有半数以上的核数的CPU的%idle持续在15%及以下甚至逼近0%，则为异常  命令：mpstat -P ALL 1 说明： 1）-P ALL：表示监控所有CPU核心。 2）表示每隔1秒输出一次统计信息。 3）历史日志路径：/sf/log/blackbox/today/LOG_cpuocp.txt   2、  检查内存资源  a）控制台检查：在控制台的【首页】或者【实体机】页面关注服务器的资源使用率情况，只需看CPU使用率或内存使用率是否持续在95%及以上，如是，则异常。  b）检查内存资源使用过高超过阈值告警日志  c）检查主机详情界面内存使用率趋势图 d）后台检查主机内存的使用率：关注free参数和swap分区的used 命令：free -h  说明：  1）如果free已经在主机总内存容量的5%及以下则为异常；  2）如果swap分区已经被used，说明该主机内存在某个时间段有出现内存不足；  3）如果free -m或者 free -k能监控到used的大小在持续增加，则说明当前存在内存不足的问题。  4）历史日志路径：/sf/log/blackbox/today/LOG_free.txt        1、  关闭部分业务虚拟机 同客户侧确认，看是否有不重要的业务虚拟机，关闭，释放CPU/内存资源。 2、  迁移虚拟机运行位置 a）确认集群内是否有其他主机的CPU/内存负载低，将部分虚拟机迁移运行位置到其他资源较为空闲的主机上 b）检查集群资源调度DRS，是否启用并正常配置，如果服务器的CPU或者内存不足，需要考虑扩容CPU/内存资源  3、  重启平台异常服务  //如检查为CPU、内存耗尽导致，无法评估是什么服务占用，可以跟专家确认后拉通研发确认  a)检查CPU 命令：top    ##首先用top检查是否有占CPU核数较多的资源  #PID对应的值为进程IP，如图，进程id为23557的一个kvm进程占用了201%的CPU资源（2核） 命令：ps auxf | grep PID    ###其次结合ps进程找出详细进程（PID为实际进程ID、通过top命令确认）  #通过ps可以发现，占用2核的进程，是虚拟机为“应用交付1”的设备 定位出对应设备后，可以考虑迁移该设备的运行位置、或者关闭该设备。 定位出部分服务占用高，考虑重启服务（不确认的情况下跟专家或研发确认）   b)检查内存  命令：sfd_ps_mem.py   命令：sfd_mem_calc.sh 相关案例：    slab服务占用较多内存：超融合HCI-深信服技术支持   外置存储异常导致内核vmalloc分配内存不断增加超融合HCI-深信服技术支持            

后台检查/、boot、log、local等分区是否在96%及以上   后台检查/、boot、log、local等分区是否在96%及以上 命令：df -h | grep -v loop | grep -v con 说明： 1、图示/sf/data 和 /mnt/这两个分区不需要关注 2、其他分区正常使用率不高于95%     a）确认对应目录占用情况 命令： 1、cd /sf/log （标红部分换成对应的异常目录，如果是/sf/log满了就更为/sf/log）  2、du -lah --max-depth=1 | sort -h (从小到大排序并分析) 3、如果占用较大的是一个目录，则需要按照步骤1、2，继续cd到对应目录下，du再次进行分析  b）删除占用大的异常目录或文件用rm删除   【rm的文件或目录拿捏不准的情况下，先跟专家或研发侧确认下】 命令：删除文件：rm ***** -f   (高危操作，***** 为文件名删除前确认好文件为无效或无用文件；如担心误操作，先不要加最后的-f)  删除目录：rm ***** -rf      (高危操作，***** 为目录名删除前确认好目录为无效或无用目录；如担心误操作，先不要加最后的-f)  c）常见分区清理指引    / 根分区超融合HCI-深信服技术支持   /boot 分区超融合HCI-深信服技术支持   /local分区 ：   loop、drs、platform_data不能动   aDeploy、dump、kdump目录下的文件可以清理，   其他判定是人工建的文件可以清理   /tmp/ 分区满 /run/shm空间占满 /log分区： 1、分层收集vs_iostat信息收集导致/sf/log/空间占用 2、run/lock导致日志分区满，导致虚拟机启动失败          

容灾主站点虚拟机cdp客户端启动失败，并且HCI集群CFS分区文件数被占满，查看集群/cfs/dr-sync/目录下存在大量文件。 无 1、CFS分区满的集群为托管云容灾策略的备战点集群，存在虚拟机已开启CDP策略。查看集群/cfs/dr-sync/目录下存在大量文件。 1、托管云容灾CDP策略，CDP传输链接失败后为主动清理残留的配置文件，导致文件数一直增加。 【方案一】清理/cfs/dr-rsync/目录下残留的文件；并且解决CDP传输失败的问题。 【方案二】及时升级到新版本HCI6.11.1；并且解决CDP传输失败的问题。 集群 否 1、虚拟机CDP启动失败，并且托管云容灾策略的备战点集群CFS分区满，存在虚拟机已开启CDP策略。查看集群/cfs/dr-sync/目录下存在大量文件。 2、解决方案： 2.1 清理/cfs/dr-rsync/目录下残留的文件；并且解决CDP传输失败的问题。 2.2 及时升级到做新版本HCI6.11.1；并且解决CDP传输失败的问题。 集群前台日志，集群后台信息

1、外部网络环境异常时，存储口会出现丢包/不通 1、前端界面有存储掉线告警、或存储聚合口聚合口丢包 2、HCI控制台或者后台存储口互ping探测丢包，丢包率不为0%则为异常   存储私网交换机未关闭STP或LLDP   查看内核日志有down/up相关的日志。 cat /sf/log/[日期]/kernel.log   检查存储网有丢包信息。 vs_cluster_cmd.sh e 'grep -nr packet /sf/log/blackbox/[日期]/LOG_vs_ping.txt |grep -v " 0% "'   网口down/up的时候抓包收到了STP或LLDP包信息。  tcpdump -i ethX not ip and not arp and not ip6 -nne  # 其中ethX的X换为具体的网口号   存储网络环境异常导致持续丢包或不定时丢包 抓包分析判断方法见存储网丢包排查三板斧       点击跳转   存储私网交换机未关闭STP或LLDP： a）关闭存储交换机的STP功能。 注：STP的作用是防止网络中的环路，关闭前请确保网络拓扑的设计不会引发环路问题。 b）关闭存储交换机的LLDP功能，建议是在存储交换机全局关闭，如果全局无法关闭，则建议在HCI后台执行以下命令在存储网口下关闭。 # HCI6.8.0及以上版本要先进入vn容器container_exec -n vn-agent lldptool set-lldp -i ethX adminStatus=disabled c）原因分析：若存储交换机开启STP协议，当网络拓扑发生改变的时候，拓扑收敛慢，即生成树协议需要50-52秒的时间才能完成拓扑收敛，这个过程中可能会暂时中断某些端口的通信，导致短暂的丢包现象。而LLDP的处理和特定网卡类型（Intel X710或X722系列网卡）的使用在某些网络配置中（使用单交换机链路聚合部署存储私网并对接信锐交换机，且信锐交换机使用堆叠或M-LAG时）可能导致数据包的漂移和丢包问题。   存储网络环境异常导致持续丢包或不定时丢包： 外部网络问题需要协同网络环境设备侧解决，提供抓包判断方法