Hello, I'm currently working through a migration strategy and I'd like some advise on possible options from anyone who might have done something similar.
Useful info here is that the source site exists now but the target site is yet to be build. This project is seen as a good opportunity to go to vSphere 6.0, but we want to use VMware Replication to get the initial data across from source to target, which restricts our initial target point to a 5.x system.
Effectively, phase one will set up a Replication Appliance in the source and target DCs and replicate machines over. These will both be 5.5. as the source and target vCenters need to be of the same major version.
In Phase 2, I'd ideally then like to migrate workloads to vSphere 6.0 hosts. The Replication environment and the new vSphere 6.0 environment will share a storage platform in the new location.
Assuming we have got the data to the target vCenter 5.5 system (and it will be an ongoing thing), what advise / options are there for then getting those machine across and starting them up in the 6.0 environment? Could we just migrate them across into a shared datastore and then start them up from on the new 6.0 hosts that share that storage? The idea is that they won't run form the target 5.5. platform - this would be a stage environment effectively.
Any advice welcome,
M
After you get all your virtual machines at your 5.5 infrastructure at target site, you can just move your vSphere ESXi 5.5 hosts to the vCenter 6.0 and then migrate (vMotion) the virtual machines to the vSphere ESXi 6.0 hosts.
Hi Richardson,
Thanks for your response.
I guess the issue here is that we have hundreds of workloads, so we will be migrating / staging a set of machines, then wanting to bring those up in the v6.0 environment while migrating another set, so the migration host really needs to be in place throughout.
The thinking was that we could perhaps do some kind of storage migration, or perhaps sharing VMFS datastores across the 5.5 and 6.0 hosts as below?
Could we then just import the VMs into 6.0?
As a cluster file system, VMFS lets multiple ESXi hosts access the same VMFS datastore concurrently.
Since the migration will be staged, you can just use a "swap" datastore shared between your ESXi 5.5 and 6.0 hosts, and replicate the source virtual machines to that shared datastore.
Once the virtual machine is replicated and running at ESXi 5.5 target host, you can just shutdown the virtual machine, unregister the virtual machine from the ESXi 5.5 host, on the vCenter 6.0, browse the datastore where the virtual machine is stored, register the virtual machine on the ESX 6.0 hosts, power on the virtual machine and if you want, just Storage vMotion the virtual machine to a different datastore not shared with ESXi 5.5 hosts.
Hi, you can do it in stage even without downtime.
Let's say you have ESXi 5.5 on vCenter 5.5 and some new ESXi 6 on vCenter 6.
An option would be to add the ESXi 5.b to vCenter 6 and vMotion from ESXi 5.x to ESXi 6.
Make sure the datastore is shared across both ESXi 5.x and ESXi 6.
If you can't share all the datastore, you can just share at least to one or two of the ESXi 6 for migration purpose - so you will have 2 migration steps:
1. vMotion to ESXi 6 staging which has shared datastore
2. Storage vMotion from ESXi 6 staging to ESXi 6
If you are using VDS (vSphere Distributed Switch), you will need to create VDS 5.x on ESXi 6 so it backward compatible with ESXi 5.x and you can have both ESXi 5.x & ESXi 6 on same VDS for the staging/migration purpose.
Upgrade the VDS to 6 once you have upgraded all the ESXi to version 6.
When you add ESXi 5.5 to vCenter 6, you will disconnect the ESXi 5 and add it on vCenter 6 - if you are using VDS, you will need to migrate to VSS (vSphere Standard Switch) first
For this scenario the high level steps would be:
Another scenario would be sharing datastore across ESXi 5.5 and ESXi 6, remove from 5.5 inventory and add inventory into ESXi 6 (or you are referring to import I guess). But the VMs need to be powered off before we can remove it from inventory.
Most of my customers choose the scenario without downtime