Issue/Introduction
When a host joins a virtual switch, the product synchronizes the host bond according to the uplink configuration on the page. If the page specifies active-backup while the host and physical switch originally use LACP, the host changes to active-backup and the aggregation modes no longer match. If the management IP depends on that bond, both the management and service networks can be interrupted.
Symptoms
- After adding an uplink or adding a host to a virtual switch, the page task fails and the host immediately becomes unreachable.
- VM/QEMU processes on the host might still be running, but the management and VM networks are abnormal.
- In a SAN environment, locks might appear because the original process is still running. The lock is a protection result, not the initial root cause.
Environment
Verified on ZSphere 4.10.26.7. This is an operation/configuration mismatch and is not proven to be version-specific.
Possible causes
Do not clear SAN locks first. Use BMC/out-of-band access to confirm that the host and VMs are alive. Then perform read-only checks of the aggregation mode in the page configuration, host bond, and physical switch Port-Channel/Eth-Trunk, and determine whether the management IP depends on that bond.
Issue classification
- Type: Human operation/configuration issue (Man-Made Fault), not a Bug, Env Issue, or Improvement.
- Known issue: No. TIC-6154 is a resolved field case and was Closed/Done on 2026-07-24.
- Root cause: The aggregation modes on the page, host bond, and physical switch were not aligned before the change. The product changed the host to active-backup based on the page configuration, while the switch remained in LACP mode.
- Confidence: High, provided that the operation audit, three-way configuration, and recovery verification agree.
Resolution
Check 1: Confirm the host and VM status out of band
- Read-only commands (run through BMC/out-of-band access):
virsh list
ip -br addr
ip route
- If VMs are still running and the management IP is on a bridge whose egress depends on the target bond: Do not clear locks or forcibly start the VM elsewhere. Continue to check the bond.
- If the host itself is down: This article does not apply. Troubleshoot hardware/OS startup.
Check 2: Read the host bond and bridge relationships
- Read-only commands:
cat /proc/net/bonding/bond0
bridge link
bridge vlan
ethtool bond0
- If Bonding Mode is active-backup while the switch still uses LACP: The mode-mismatch evidence is established.
- If the host still uses 802.3ad/LACP and negotiation is normal: Do not cite TIC-6154. Continue to check VLANs, ports, routes, or firewalls.
Check 3: Compare configurations before and after the operation
- Read-only page checks: virtual switch uplink name, bond mode, member NICs, and operation audit time.
- Read-only switch checks: member ports, LAG mode, and LACP neighbor/aggregation status.
- Page active-backup + host active-backup after the operation + switch LACP: This completes the root-cause chain.
- If the pre-operation state is unavailable: You can determine only that the current configurations do not match, not who changed them.
Recommended actions
This section involves high-risk operations and must be performed manually by an administrator with the required permissions.
Only through BMC/out-of-band access and during a maintenance window, network and system administrators must coordinate to restore the host bond and physical switch to the same mode. Record the original configurations and rollback commands on both sides first. After LACP negotiation recovers, verify the gateway, management node, platform host status, and VM network in that order. If the original VM process is still running, do not clear the SAN lock or forcibly start the same VM on another host, to avoid dual writes to shared storage.
Long-term solution
Perform a three-way consistency check before adding an uplink. Changes to a bond carrying the management network must use a maintenance window, out-of-band access, and two-person review.
Additional information
When to escalate
- BMC/out-of-band access is unavailable.
- The original host still has running VM processes and SAN locks are involved.
- The switch aggregation mode or rollback method is uncertain.
- All three modes match, but the network is still unreachable.
Information to collect
ZSphere version, operation audit, screenshot of the page uplink configuration, /proc/net/bonding, IP/route/bridge output, switch LAG/LACP status, VM runtime status, and recovery verification results.
Related issues
- TIC-6154, Closed/Done.
- Status verified on 2026-08-06.
