问题说明
删除分布式交换机时，产品会删除该交换机下的端口组、对应VLAN子接口，并解绑、删除已经被平台纳管的bond。即使bond最初由用户在宿主机命令行创建，纳管后其配置形态与平台创建的bond相同，当前产品无法区分创建来源，因此仍按平台配置一起清理。
现象
- UI删除分布式交换机/L2后，宿主机同名物理bond消失或成员网卡被拆开。
- 客户可能认为“底层手工创建的bond不应被页面删除”，与当前产品设计预期不一致。
- 日志关键词：
APIDeleteL2NetworkMsg、BondingDeletionMsg、/network/bonding/delete、bondName。 - 关键区分点：事件中删除的是分布式交换机，不是删除三层网络。
适用环境
ZSphere 4.10.13.66现场日志。其他版本必须重新核对删除链路。
可能原因
先从事件/审计确认客户实际删除的资源类型，再确认bond是否已经作为该分布式交换机上行被平台纳管。若删除的是分布式交换机且日志进入bond删除链路，属于当前设计行为；如果仅删除三层网络却删除bond，或删除的bond不属于该交换机，则不能套用本结论。
问题定性
- 类型：产品设计行为/用户预期差异，不是Bug。
- 是否为已知问题：否；TIC-6185已于2026-08-10按Just Q&A/Done Resolve，无关联产品Bug。
- 根因：客户删除了分布式交换机；平台按当前设计清理交换机下端口组、VLAN子接口和已纳管bond。平台无法区分该bond最初由用户命令行创建还是由UI创建。
- 若客户要求删除交换机时保留底层手工bond，应按Improvement/需求评估，包括来源标记、依赖展示和删除提示。
- 置信度：高，依据操作事件、后台删除链路及模块人员对既有产品逻辑的确认。
排查步骤
检查一：保存当前主机网络拓扑
- 只读命令：
ip -d link show
ip -br addr
ip route
bridge link
bridge vlan
cat /proc/net/bonding/* 2>/dev/null- bond已不存在、成员变独立网卡：确认数据面现象，继续关联控制面操作。
- bond仍存在：可能只是平台inventory变化或短暂状态，不能按本篇定根因。
检查二：核对删除链路日志
- 只读检索（路径以现场日志目录为准）：
grep -RniE 'APIDeleteL2NetworkMsg|BondingDeletionMsg|/network/bonding/delete|bondName' \
/usr/local/zstack/apache-tomcat*/logs 2>/dev/null- 同一调用链从分布式交换机/L2删除进入指定bond删除：确认平台按删除交换机流程清理上行bond。
- 没有调用链：还需排查人工命令、NetworkManager或其他自动化系统。
检查三：确认删除对象和纳管关系
- 在事件/审计中确认操作对象是分布式交换机，而不是三层网络。
- 确认bond已经作为该交换机上行被平台纳管；其最初由UI还是宿主机命令行创建，不改变删除逻辑。
- 若删除的是分布式交换机且bond属于该交换机：命中当前产品设计行为。
- 若只删除三层网络、bond不属于该交换机，或页面仍有其他交换机对象引用该bond：不符合本篇，升级研发核查。
处理建议
Note:
本节涉及高风险操作，须由具备权限的管理员人工执行。
删除前先确认该交换机下端口组、子接口和bond是否仍需保留；需要保留底层bond时，不要直接删除分布式交换机，应先由人工制定迁移方案。若已经删除并影响业务，通过BMC/带外按删除前记录恢复bond、成员、模式、VLAN和bridge关系，同时核对物理交换机聚合配置。承载管理网时禁止远程盲改。
长期方案
如客户希望保留宿主机手工创建的bond，提交Improvement评估：记录bond来源/所有权、展示删除影响范围、删除前强提示或允许选择是否保留。需要同时评估残留bond、网桥和子接口对后续网卡复用及交换机重建的影响。
补充信息
升级人工条件
- bond承载管理网、存储网或多个L2。
- 需要重建bond/bridge/VLAN、修改交换机配置或数据库。
- 事件显示只删除三层网络，或被删除bond不属于目标交换机。
- 客户要求改变现有删除逻辑或保留手工bond，需要转产品需求评估。
需要收集的信息
ZSphere版本、完整操作时间/用户、被删L2 UUID、bond UUID/名称、主机UUID、删除前后网络配置、管理/存储/业务网依赖、控制面日志、KVM Agent日志和物理交换机配置。
相关问题
- TIC-6185，Resolved/Done；按正常产品行为结案。
- 状态核验日期：2026-08-10。