Mixing Datastores, Protocols, VCenters VSAn/VxRail Migrations

[haggisnneeps]

Hi,

We have an old system and a new system

Old is IBM v7000 with all FC hosts attached. VCenter1.oldsystem.local. mix of esxi 5.5 and 6. old hosts. vcenter 5.5

New is VxRail VSAN. NewVcenter2.newsystem.local vcenter 6

We would like to migrate a load of VMs off the old onto the new. We only have enterprise plus licensing for the esxi/vcenter 6

We cant do shared nothing migration because of different SSO domains and licensing

Since the IBM storage supports ISCSI too, we would like to create a LUN on old system and migrate VMs in batches by storage vmotion then unregister from old and register on new then storage vmotion to VSAN disks

To do this though, requires we have a LUN presented as FC to Old VCenter hosts/clusters and ALSO presented to new VCenter hosts as ISCSI LUN

Is this going to casue corruption on the datastore?

We would prefer, if possible, to migrate all the VMS "Hot" and have no downtime - is there a way to do it? We have VEEAM and VMWare Converter available

[daphnissov]

We cant do shared nothing migration because of different SSO domains and licensing

Well, you wouldn't be able to do this regardless if your source vCenter is at v5.5.

To do this though, requires we have a LUN presented as FC to Old VCenter hosts/clusters and ALSO presented to new VCenter hosts as ISCSI LUN

Is this going to casue corruption on the datastore?

I've not simultaneously presented the same LUN to two separate sets of hosts via two separate block protocols. Are you sure your IBM system will even support this with ESXi? From a data integrity standpoint, VMFS is cluster aware and performs low-level locking. I would not think corruption would be an issue here.

We would prefer, if possible, to migrate all the VMS "Hot" and have no downtime - is there a way to do it?

No, that's not going to happen. Even if you used VMware Converter or a Veeam Quick Migrate, you're still going to have switchover time.

[haggisnneeps]

Yeah coz basically the VEEAM and Converter methods are the same as manually unregistering/re-registering?

Was hoping there was maybe something we didnt know about to do this or we are missing something

Came across an article about VSAN iscsi target service - would this allow us to migrate directly onto the VSAN instead of the in-between hop of the "shared" LUN?

Thanks

[daphnissov]

Yeah coz basically the VEEAM and Converter methods are the same as manually unregistering/re-registering?

There's a lot more going on here than just that, but the quickest approach will still have you powering off and registering on your VxRail cluster.

Came across an article about VSAN iscsi target service - would this allow us to migrate directly onto the VSAN instead of the in-between hop of the "shared" LUN?

No, that's separate functionality altogether.

[sk84]

Came across an article about VSAN iscsi target service - would this allow us to migrate directly onto the VSAN instead of the in-between hop of the "shared" LUN?

No, that's separate functionality altogether.

In addition: It's not supported to connect a vSAN datastore to another ESXi host via iSCSI.

[haggisnneeps]

ok but if i am connecting a vsan host to another datastore thats ok?

via iscsi on a single host in the vsan cluster - sharing 25GB nics and that datastore contains VMs that are in use on the old vcenter and those hosts connect to that datastore via FC

Then once the VMs are on that shared storage, we do the unregister/and register and then storage vmotion them onto the vsan (as per the Original Post)

If all thats OK then i suppose its all we got

Thanks again

[daphnissov]

ok but if i am connecting a vsan host to another datastore thats ok?

via iscsi on a single host in the vsan cluster - sharing 25GB nics and that datastore contains VMs that are in use on the old vcenter and those hosts connect to that datastore via FC

Would it technically work? Yes, it should. Is it supported by DellEMC on VxRail even as part of a migration? Dunno, that you'd definitely want to ask.

But I think the more critical questions are regarding the storage situation on your IBM array:

Will it work to connect to a given LUN via FCP and iSCSI simultaneously? Don't know. Probably.

And is it supported? Really don't know at all.

Some big question marks for you to investigate through official channels here if you want to go about this migration in a safe way.

[haggisnneeps]

So could we then just disconnect all these hosts from the "old" vcenter and connect them to the new vcenter and transfer the licenses across? Then we can just do normal vmotions?

[haggisnneeps]

ok so i suppose the last loose end to tie up would be nesting

Could i nest a 6.0 or 6.5 host inside a vcenter 6.7 managed VM Host environment and migrate 5.5 hosts into it?

Would there even be any benefit other than everything would now be on the VxRail and we could then do other migrations at leisure?

clutching here 🙂

[daphnissov]

You can't do "normal" vMotions because you still wouldn't have the same storage. See my previous responses for challenges there. The other challenge even if you did is the matter of different networks. You can't join the vDS on the new vCenter side because it will be at a higher version than the 5.5 hosts can use, which means the old hosts would be on vSS. And you can't vMotion and change the port groups simultaneously because those APIs didn't exist until 6.0.

[daphnissov]

Could i nest a 6.0 or 6.5 host inside a vcenter 6.7 managed VM Host environment and migrate 5.5 hosts into it?

I don't know what you're asking here, but it doesn't matter.

We've already fleshed out all your options at this point and you've got some homework to do yourself.

[haggisnneeps]

Hi Thanks agai for ll your help it has been incredibly useful

It has pushed us down a path where we think we have found a way to do this - or a couple of ways. Maybe.

1) Fling seems to be able to do it and also says there is a way to do it using PowerCLI ..We will try Fling but not PowerCLI (yet)

2) VEEAM can also do a quick migration ( we haven't figured out whether its a version limitation that stops us from doing a hot migration) but when it takes the VMs across, it cant automatically assign a mapped NIC to one of the port groups on the DVSwitch so there is manual intervention to get the NIC up

we can alleviate this by creating Standard vSwitches on the VxRail that will be the same as the originating Standard vSwitches but it will still be cold migration (its the community version of VEEAM - like i say i don't know if the full Enterprise version would allow a hot migration)

So Fling is what we are about to try -  albeit not "supported"

So we know there is no "supported" method of doing this. We will see if there is a "working" way of doing it

Ill let you know how it goes

[haggisnneeps]

FYI presenting a LUN via FC, putting the files on there and then presenting to the other side via ISCSI didn't work very well. Didn't work at all actually.

Both sides saw the disk and locked it and we had to reboot the VxRail node it was presented to via ISCSI to remove it

[haggisnneeps]

And the fling in question is the cross VCenter Workload Migration Utility

[daphnissov]

As I said earlier, due to your old version of vCenter, the Fling will not work. PowerCLI the same. They all use the same underlying APIs and those don't exist in 5.5.