Assignment/Mapping Hosts to Datastores

[Jody3]

Hello Community,

We recently created a new VCenter 6.5 but we still have our old VCenter 5.5 so we now have two.

We've moved a few Cisco UCS blades into the new VCenter and the SAN used for both VCenters is HP 3Par 7400.

In the old VCenter, we had multiple Clusters and they in-turn had multiple Hosts and the 3Par datastores were assigned to the individual hosts, via Host Set, based on department, usage and need.

In the new VCenter, we arranged it so that there is only one Cluster and it will have multiple Hosts. As we move the blades into it the new VCenter they will be arranged by their hardware features.

The old VCenter mappings were such that you couldn't vMotion any VM from one Host to another Host if they were in different clusters because the datastores were assigned by Host Sets.

So the question is this, what is the recommendation, for our new VCenter and single Cluster configuration, for the alteration of our datastore mapping as we transition from old to new? Because once the datastores are in the new single Clustered VCenter we will still NOT be able to vMotion freely from any Host to any other Host based on the original mappings.

[ASHOKA_Shankar]

For host mapping setup please refer to the implementation guide - https://support.hpe.com/hpsc/doc/public/display?docId=c03290624

[Sheldon Smith · Accepted solution]

Host sets and volume sets have nothing to do with vMotion.
vMotion happens between datastores visible to a vCenter cluster. There is normally a one-to-one relationship between vCenter datastores and 3PAR virtual volumes. Virtual volumes are exported to the hosts in vCenter. To simplify things, the vCenter hosts are typically put in a host set and frequently the virtual volumes in a volume set. That does not limit a datastore/virtual volume from being used by hosts in more than one vCenter cluster. Go search the VMware Technical Network forums for more on sharing datastores between clusters of a vCenter.

Let's say you have cluster A with hosts A1 and A2 and datastore/virtual volumes A_DS1 and A_DS2. Stuff (a technical term) can be vMotioned (can 'vMotion' be a verb?)) between hosts A1 and A2.
Let's add a second cluster B with hosts B3, B4 and B5 and datastore/virtual volumes B_DS3 and B_DS4. More stuff can be vMotioned using any of the B hosts.

Let's add an extra datastore, map it to hosts A1, A2, B3, B4 and B5, call it Common_DS1. Now, all five hosts can see the common datastore, and allowing for differences of host hardware, VMs can be migrated between the hosts.

Finally let's make a new cluster N, with hosts N6, N7, and N8. We can present: N_DS1, N_DS2 and N_DS3 (with VMFS6), and A_DS1, A_DS, B_DS3, B_DS4 and Common_DS1 (which were formatted with VMFS5).
You can migrate from the A, B and Common datastores to the N datastores, letting you take advantage of the VMFS6 features.

As for organizing VMs in datastores, that's up to you.