Cross-Switch vMotion - VDS to NSX-T Network Migration

Network security infrastructure requires continuous protection while enabling rapid deployment of security updates and configuration changes. This KB article addresses security challenges in maintaining micro-segmentation, threat prevention, and network policy enforcement across distributed environments.

Source KB: https://knowledge.broadcom.com/external/article/336640

KB Number: 336640

Orchestrator Integration: Automation Workflow

Goal: Automate cross-switch vmotion - vds to nsx-t network migration configuration and validation to reduce manual effort and ensure consistency across environments.

Workflow steps (VMware Aria Orchestrator)

• Create a workflow: 'Cross-Switch vMotion Orchestration with Network Policy Translation'
* Inputs: vmName (string), targetHost (string), targetNetwork (string), networkType (string: VDS/NSX-T)
* Step 1: Pre-migration validation comprehensive checks:
- Query VM current configuration: network adapter count, portgroup assignments, IP addresses, MAC addresses
- Identify source switch type and version (VDS version or N-VDS, NSX-V vs. NSX-T)
- Query target ESXi host and validate supported switch types
- Cross-reference KB 336640 compatibility matrix: ESXi versions, vCenter version, switch types
- Verify vCenter version supports cross-switch vMotion (6.7 U3g+ required to avoid HTML5 client bug)
- Check if VM has connected devices that may block migration (ISO mounted, USB device)
* Step 2: Capture source network configuration state:
- Document current NIOC (Network I/O Control) settings on source VDS portgroup
- Export QoS marking policies applied to VM's vNIC ports
- Retrieve traffic filter rules (not DFW, but switch-level filters)
- Record Security policies (promiscuous mode, MAC address changes, forged transmits)
- Export Spoofguard configuration if NSX-V source (IP allow-list, enforcement status)
- Log Security Group memberships (especially dynamic groupings based on VM name/tags)
* Step 3: Spoofguard pre-migration handling (critical per KB 336640):
- If source is NSX-V with Spoofguard enabled:
- Query Spoofguard IP allow-list for target VM
- Document approved IP addresses (may be from DHCP snooping or IP discovery)
- Disable Spoofguard temporarily on NSX-V for this VM (prevents traffic blackhole post-migration)
- Log disabled status and original configuration for post-migration re-enablement
* Step 4: NSX-T target environment preparation:
- If target is NSX-T segment, query segment profile configuration
- Create or validate Segment Profile that recreates NIOC/QoS policies from source VDS:
- Segment QoS Profile for bandwidth limits and DSCP marking
- Segment Security Profile for security policies (spoofguard, port security)
- Segment Discovery Profile for IP/MAC learning settings
- If segment profiles don't exist, create them now via NSX-T policy API
- Pre-populate NSX-T IP discovery database with known VM IP addresses (accelerates Spoofguard re-enablement)
* Step 5: Security Group membership preservation:
- If VM was part of NSX-V dynamic Security Group (e.g., "Web Servers" based on VM name contains "web"):
- Create equivalent NSX-T Group using same membership criteria
- If dynamic criteria not compatible, add VM to static NSX-T Group using IP address
- Validate VM will maintain firewall policy coverage post-migration
- Document pre-migration SG memberships for validation after migration
* Step 6: Distributed Firewall rule impact analysis:
- Query all DFW rules where VM is source or destination (directly or via Security Group)
- In zero-trust model, loss of Security Group membership = traffic denied
- Create temporary DFW rule exceptions if needed to allow migration traffic
- Plan post-migration DFW rule validation and adjustment
* Step 7: Execute vMotion with enhanced monitoring:
- Initiate vMotion via vCenter API: relocateVM_Task with target host, network, and datastore parameters
- If using vSphere Web Client (Flash), expect possible precheck failures per KB 336640 (HTML5 bug)
- Monitor vMotion progress: pre-copy phase, switchover, post-copy
- Real-time network traffic monitoring: watch for packet loss or latency spikes during switchover
- Timeout threshold: abort if vMotion exceeds 15 minutes (indicates problem)
* Step 8: Post-migration immediate validation:
- Verify VM powered on, VMware Tools responsive
- Check VM connected to correct target network (NSX-T segment)
- Test network connectivity: ping default gateway, DNS resolution, external connectivity
- Validate VM IP address unchanged (should retain same IP)
* Step 9: Spoofguard re-enablement on NSX-T:
- If target is NSX-T with Spoofguard required:
- Trigger DHCP renewal on VM (if DHCP) to populate NSX-T IP discovery
- For static IP, manually add to IP discovery database via API
- Wait for IP discovery to complete and populate Spoofguard allow-list
- Enable Spoofguard on NSX-T segment
- Validate Spoofguard allow-list contains correct IP addresses (prevent traffic block)
- Monitor VM traffic for 5 minutes post-Spoofguard enablement (catch any blocks)
* Step 10: Security policy reconciliation:
- Verify VM appears in correct NSX-T Security Groups (dynamic or static membership)
- Test distributed firewall rules: generate traffic matching allow rules (should pass), generate traffic matching deny rules (should block)
- Validate micro-segmentation policies apply correctly to migrated VM
- Check for any firewall rule hits that shouldn't occur (indicates misconfiguration)
* Step 11: Network performance validation:
- Measure network latency: should be consistent with pre-migration baseline
- Test throughput: iperf or similar tool to validate no bandwidth degradation
- Verify QoS policies active: DSCP markings present in packet captures
- Check for any packet drops or errors on new vNIC port
* Step 12: Rollback capability (if validation fails):
- If critical validation fails (no connectivity, wrong Security Group, Spoofguard blocking):
- Trigger reverse vMotion back to source switch
- Note: Rollback on unsupported ESXi versions is disruptive per KB 336640 (requires VM power cycle)
- Restore original Spoofguard configuration on NSX-V
- Re-validate VM operational on source network
- Generate incident report with failure analysis
* Step 13: Documentation and compliance:
- Update CMDB with new network assignment (NSX-T segment, IP address, Security Groups)
- Log migration event with KB 336640 reference, success status, validation results
- Update network topology diagrams if VM moved between network zones
- If migration successful, schedule cleanup of old VDS portgroup if VM was last consumer

Expected outcome

Orchestrated cross-switch vMotion with automated Spoofguard management eliminates traffic blackhole risks, network policy translation ensures NIOC/QoS continuity, Security Group mapping maintains micro-segmentation, comprehensive validation catches configuration issues before they impact production, successful migrations reduce from 45-minute manual process to 8-minute automated workflow.