Issue/Introduction

When a distributed switch is deleted, the product deletes its port groups and corresponding VLAN subinterfaces, and unbinds and removes bonds managed by the platform. Even if a user originally created a bond from the host command line, once managed its configuration is indistinguishable from a platform-created bond. The current product cannot identify the creation source and therefore removes it with the platform configuration.

Symptoms

• After a distributed switch/L2 is deleted in the UI, the physical bond with the same name disappears from the host or its member NICs are detached.
• The customer might expect a bond manually created on the host not to be deleted from the page, which differs from current product design.
• Log keywords: APIDeleteL2NetworkMsg, BondingDeletionMsg, /network/bonding/delete, and bondName.
• Key differentiator: the event deletes a distributed switch, not an L3 network.

Environment

Field logs from ZSphere 4.10.13.66. Reconfirm the deletion path for other versions.

Possible causes

First use events/audit records to confirm the actual resource type deleted by the customer, and then confirm whether the bond was managed as an uplink of that distributed switch. If a distributed switch was deleted and the logs enter the bond-deletion path, this is current design behavior. If only an L3 network was deleted but a bond was removed, or the removed bond did not belong to that switch, this conclusion does not apply.

Issue classification

• Type: Product design behavior/difference in user expectations, not a bug.
• Known issue: No. TIC-6185 was resolved as Just Q&A/Done on 2026-08-10, with no related product bug.
• Root cause: The customer deleted a distributed switch. By design, the platform removes its port groups, VLAN subinterfaces, and managed bonds. The platform cannot distinguish whether the bond was originally created from the host command line or the UI.
• If the customer requires a manually created host bond to remain when the switch is deleted, evaluate it as an Improvement/requirement, including source marking, dependency display, and deletion warnings.
• Confidence: High, based on the operation event, backend deletion path, and confirmation of existing product logic by the module owner.

Resolution

Check 1: Save the current host network topology

• Read-only commands:

  ip -d link show
  ip -br addr
  ip route
  bridge link
  bridge vlan
  cat /proc/net/bonding/* 2>/dev/null

• If the bond is absent and the members are independent NICs: Confirm the data-plane symptom and correlate it with the control-plane operation.
• If the bond still exists: This might be only a platform inventory change or transient state; do not determine the root cause from this article.

Check 2: Check deletion-path logs

• Read-only search (adjust the path to the field log directory):

  grep -RniE 'APIDeleteL2NetworkMsg|BondingDeletionMsg|/network/bonding/delete|bondName' \
    /usr/local/zstack/apache-tomcat*/logs 2>/dev/null

• If the same call chain goes from distributed switch/L2 deletion to deletion of the specified bond: Confirm that the platform removed the uplink bond through the switch-deletion flow.
• If the call chain is absent: Also investigate manual commands, NetworkManager, or another automation system.

Check 3: Confirm the deleted object and management relationship

• In events/audit records, confirm that the operation object is a distributed switch, not an L3 network.
• Confirm that the platform managed the bond as an uplink of that switch. Whether it was originally created from the UI or host command line does not change the deletion logic.
• If a distributed switch was deleted and the bond belongs to it: This matches current product design behavior.
• If only an L3 network was deleted, the bond did not belong to the switch, or another switch object on the page still references the bond: This article does not apply; escalate to R&D.

Recommended actions

Before deletion, confirm whether the switch's port groups, subinterfaces, and bond must remain. If the underlying bond must be retained, do not delete the distributed switch directly; first create a manual migration plan. If deletion already affected service, use BMC/out-of-band access and the pre-deletion records to restore the bond, members, mode, VLAN, and bridge relationships, while also checking the physical switch aggregation configuration. Do not make blind remote changes when the bond carries the management network.

Long-term solution

If the customer wants manually created host bonds to remain, submit an Improvement for evaluation: record bond source/ownership, display deletion impact, provide a strong pre-deletion warning, or allow the user to keep the bond. Also evaluate how residual bonds, bridges, and subinterfaces affect later NIC reuse and switch recreation.

Additional information

When to escalate

• The bond carries the management network, storage network, or multiple L2 networks.
• Rebuilding a bond/bridge/VLAN, modifying switch configuration, or changing the database is required.
• The event shows only an L3 network deletion, or the deleted bond did not belong to the target switch.
• The customer requests a change to existing deletion logic or retention of manual bonds; route it for product requirement evaluation.

Information to collect

ZSphere version, complete operation time/user, deleted L2 UUID, bond UUID/name, host UUID, network configurations before and after deletion, management/storage/service network dependencies, control-plane logs, KVM Agent logs, and physical switch configuration.

Related issues

• TIC-6185, Resolved/Done; closed as normal product behavior.
• Status verified on 2026-08-10.