Hi
we are in the progress of moving a lot of VM's from a vSphere 5.5 environment to a vSphere 6 environment and we want to have this done with the least amount of downtime. We have looked at vSphere Replication to manage this job, but then the question come:
has anybody tried this ??
IS it possible to Replicate between 5.x and 6.x ??
AS fare as I have read we will not be able to use compression but is that the only thing ?
Looking forward to hear if it's possible.
Thanks in advance.
Regards,
Kim
See the FAQ:
Can I use vSphere Replication to replicate a VM between vCenters running different versions of vSphere Replication (eg. VR 5.5 to 6.0)?
To replicate between vCenters, vSphere Replication requires the same major version (eg. 5.5.x > 5.5.x) of vCenter and vSphere Replication at both source and target. This is the only officially tested and supported configuration. Check the VMware Product Interoperability Matrix if you have any questions about matching vCenter and vSphere Replication versions.
Hi,
It is possible to use vSphere Replication to protect VMs running on ESXi 5.1.x or 5.5.x to datastore attached to ESXi 6.x. However, as the other answer said - the source site ESXi needs to be managed by vCenter 6.x (matching with the version at the target site).
Is it an option to remove the source ESXi from source site vCenter and attach it to the destination site vCenter?
Regards,
Martin
Is this migration between 2 sites? Have you looked at creating a "jump datastore" (a datastore exposed to both environments)? You could also look at moving hosts between environments.
It's not that vSphere Replication wouldn't accomplish this, just that there might be an easy way that wouldn't involve downtime.
Thanks for all the suggestions and I feared that it not would be possible between 2 different version.
Our 5.5 vCenter is at the same physical location as the 6.x and for now we have just added one additional HBA in one of the servers in our 5.5 environment but it's old servers and then you are only able to move as many VM's as the host can contain. This means a lot of service windows due to downtime and therefore the vSphere Replication would have been nice, because then we could move all the VM's of one customer at a time (we are a service provider) instead of the host beeing the limit. Then we just have to add HBA's in more servers.
KIm
How many VMs we are talking about? I'm almost sure that a jump host/datastore is still the better option, since the downtime will be only to shutdown the virtual machine on the old host and power on the virtual machine on the new host... that assuming that is not possible vMotion between old and new hosts due to processor incompatibility, BUT if you have compatible hosts and/or can enable EVC on destination host, I'm 100% sure that you can do that migration without downtime just moving the old hosts to the new vCenter management and migrate the virtual machine to the jump host/datastore and then move them to the new destination host.
Hi Porto.
Perhaps I should have clarified things earlier
Our setup is like this:
We are using a vCenter 5.5 upd. 2 I think (is at vacation right now )
we have 12-15 different clusters spread around 4-5 different physisical locations and they are mostly running on old hardware IBM which is not possible to upgrade to vSphere 6.x.
We want to consolidate all the clusters on one location into just one cluster.
When we moves VM's into the new vSphere 6.x we also want to upgrade virtual hardware and VMware tools.
The ESXi hosts in the 5.5 and 6.x environment is using different CPU's.
Therefore I only see one option : install additional HBA's in our 5.5 environment on selected hosts and then have that jump server using the same of the datastores in our 6.x environment and then unregister in our 5.5 environment and reregister in 6.x and then upgrade all regarding the VM. Svmotion it to a vSphere 6 datastore and a new vSphere 6 host.
Hopefully this more clear now and the proper way to do it ?
KIm
UPS
Forgot to answer your question - we have 1200 - 1500 VM's which needs to be moved.