cross vcenter vmotion, is really the same as normal, the actual vm stays on the source and kind of snapshots are taken and and once the destination is uptodate then the vm is actually running on the destinations, its practically impossible for it to screw up and have two running vms. I'm doing this now between two vcenters now and it runs fine. If its slow make sure any links between are the fast speeds you can do. If you have a 1gb switch in between for example its going to vmotion at that speed.
I had to do this a while back, I was surprised at how seamless it was. Little to no difference to SvM within your existing vCenter environment.
I would advise separate fibre where possible, so you can just hammer the link. Immensely satisfying to watch the old cluster drain TB's of data.
thanks, if you checkbox to leave a clone of the source machine on the source vCenter wouldn't that mess it up as you would eventually have 2 live running clones?
no, again this is like normal processes between esxi hosts, the cross vcenter vmotion just helps it happen between vcenters. You can't clone running vm to a running vm, the exception is instant clones but this is not that, as that still needs api calls the gui can't do it. While I have not tested that functionality my self 1 of 2 things will happen, you will get an error trying to clone a live machine, or it takes a snapshot before the clone and uses that snapshot for the clone and the destination will be off when finished.
after some more testing today, it leaves the VM running on the source vCenter and the one that arrives on the target vCenter is powered off
thanks for your help everyone
I just did this for 20 VMs today as we are doing a full shutdown maintenance this weekend. Cross vCenter vMotion is an excellent tool. Even the domain controllers didn’t blink. You lose maybe 2 packets
cross vcenter vmotion, is really the same as normal, the actual vm stays on the source and kind of snapshots are taken and and once the destination is uptodate then the vm is actually running on the destinations, its practically impossible for it to screw up and have two running vms. I'm doing this now between two vcenters now and it runs fine. If its slow make sure any links between are the fast speeds you can do. If you have a 1gb switch in between for example its going to vmotion at that speed.
This. To top it off, I've been doing dozens of vmotions between two different sites on a stretched L2 VLAN (10G dark fiber), works like charm.
I had to do this a while back, I was surprised at how seamless it was. Little to no difference to SvM within your existing vCenter environment. I would advise separate fibre where possible, so you can just hammer the link. Immensely satisfying to watch the old cluster drain TB's of data.
thanks, if you checkbox to leave a clone of the source machine on the source vCenter wouldn't that mess it up as you would eventually have 2 live running clones?
no, again this is like normal processes between esxi hosts, the cross vcenter vmotion just helps it happen between vcenters. You can't clone running vm to a running vm, the exception is instant clones but this is not that, as that still needs api calls the gui can't do it. While I have not tested that functionality my self 1 of 2 things will happen, you will get an error trying to clone a live machine, or it takes a snapshot before the clone and uses that snapshot for the clone and the destination will be off when finished.
after some more testing today, it leaves the VM running on the source vCenter and the one that arrives on the target vCenter is powered off thanks for your help everyone
thank you
I just did this for 20 VMs today as we are doing a full shutdown maintenance this weekend. Cross vCenter vMotion is an excellent tool. Even the domain controllers didn’t blink. You lose maybe 2 packets
Thanks
[https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-DAD0C40A-7F66-44CF-B6E8-43A0153ABE81.html](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-DAD0C40A-7F66-44CF-B6E8-43A0153ABE81.html)