So, let's power off the VM and try a cold migration ... but - surprise(?) - even this will be rejected by vCenter, with the same error message:
vCenter rejecting an inter-vDS migration |
One way to cope with that is to remove the vNIC from the VM, do the migration and then add a new vNIC to the VM. However, this has consequences that might be undesirable: The new NIC will have a new MAC address and will be detected as a new device by the guest OS which might led to even more problems, another reboot being necessary etc.
There is another, smoother way to do it: In our environment we have created an extra vDS that serves the only purpose of enabling inter-vDS migrations. We called it TransferSwitch, another good name would be MigrationSwitch, and we have added all hosts of all clusters that are managed by vCenter to this vDS, but without any physical uplinks. A migration of a VM from one vDS to another then becomes a three steps process:
- Connect the VM's NIC to the TransferSwitch
- Migrate the VM to the target host
- Connect the VM's NIC to the destination vDS
Love this idea. Doing the same for my company. Thanks!
ReplyDeleteVery elegant solution...thanks for the tip. Much appreciated!
ReplyDeleteGood idea! Thanks!
ReplyDeleteLegend!
ReplyDeleteNo chance of a live migration though? Always have to power of the VM to migrate to another Cluster?
ReplyDeleteIf the hosts of the two clusters are "vmotion-compatible" then you can also vmotion from one cluster to the other. That means compatible CPUs, a shared vDS or standard port groups using the same labels and VLANs, and shared storage in versions <5.1. Since 5.1 you don't necessarily need shared storage.
ReplyDeleteThank you for taking the time to post this. Much appreciated!
ReplyDeleteVery useful set of tips, thanks for sharing!
ReplyDelete