Deploying VCSA on new cluster?

[burvil]

I'm running into a chicken-and-egg problem.  I have set up 3 Dell R630s as hypervisors, and have installed Vsphere ESXi 6.0.0 on them; this cluster has new VLANs, and is that way to isolate from our other clusters, as this is specifically for testing; we'll also have other similar clusters that will need to be separated for other reasons. Similarly, I intend to only use VSAN, and not SAN, NAS or localdisk for this cluster.  I've also deployed VCSA on one of our existing ESXi (5.1) clusters, but realized that without access to the new VLANs, the VCSA won't work.  At the same time, without a datastore on the new cluster, I can't deploy VCSA. We currently have a similar setup, where the Vcenter VM for our other vcenters are VMs in the cluster they control.  I just don't know how they were setup, as I wasn't really involved at that point.

Is the only solutions to:

a) setup a temporary local disk datastore for VCSA, and transfer it later?

b) add the new VLANs to the existing cluster, so the VCSA I've deployed will work?

[npadmani]

Let's say your 3 ESXi hosts management network is configured with VLAN 100.

Why don't you put your VCSA VM on a Virtual machine port group configured with same VLAN ID 100.

that way VCSA will be able to see all three hosts.

[burvil]

I realize I can do that.  The issue I'm seeing is with the storage.  I'd prefer to only use VSAN storage for this cluster, not local disk, SAN or NAS.

If:

a) the VCSA needs a datastore and

b) that datastore needs to be on VSAN

c) I need to configure VSAN with the three hosts in order to configure a datastore

This seems like a circle, that I need to get past by choosing one of the two options I posted earlier....  I'd prefer not to, so I'm hoping someone might have some other alternatives, or maybe there's something I'm missing here.  If I have to, I'm starting to lean towards adding the new VLANs to the existing cluster; at least that gives some redundancy.

[npadmani]

as you have mentioned in first post, you have already deployed VCSA on one of these three hosts, so I am guessing that you have done it on local datastore of that host.

using that form a VSAN cluster, and then transfer your VCSA VM from current location to VSAN datastore using storage migration. (I haven't personally done this but conceptually I don't see any issues either)

[burvil]

as you have mentioned in first post, you have already deployed VCSA on one of these three hosts, so I am guessing that you have done it on local datastore of that host.

===================================

No, the VCSA is deployed on existing cluster, i.e. not on the three hosts.  Put another way:

Cluster 1:

- Existing

- Uses SAN/NAS datastores

- 2 Dell R810s

- currently has older VLANs (Vmotion, etc.)

- VCSA (to control cluster 2) is deployed here

Cluster 2:

- New

- Would only use VSAN

- 3 Dell R630s

- new VLANs (for Vmotion, etc.)

- VCSA is not deployed here, but the VCSA would control these hypervisors

- hasn't been set up yet, since VCSA not operational yet

Since I have limited number of disks on the servers for Cluster 2, I'd like to use those for VSAN.  Moreover, it seems a waste to dedicate one or two disks for local storage, when those disks could contribute to the VSAN pool.  As such, I'd like to avoid using local disk datastores for Cluster 2.

[Paul_Sheard]

did you get a solution to this? I am in exactly the same boat..

I've tried the bootstrapping method which all works ok, but when I then try to migrate the standard switches to distributed I get an issue with the vsan vss.. this is mainly because the vcsa lives on this vcsa datastore..

I have 4 hosts, so could use one disk on the 4 host to create a vmfs, deploy psc and vcsa to this and then create a vsan on the other 3 hosts, then move the psc and vcsa to the vsan datastore..  not sure if I can move the psc and vcsa disks to the vsan datastore from a local vmfs on another host.. did you try this?

[burvil]

In terms of my original question, I realized that the VCSA only requires one portgroup to work (i.e. associated with its own IP address), since the VCSA requires only one network interface.  With that, I didn't have to add the other portgroups to the legacy Vcenter.  In fact, I took them off, as I had added them, thinking I needed them.  I removed them months ago, and the VCSA has been working fine since then.

As to your question, my understanding from VMware support is that VMware highly recommends you *not* to put the VCSA on VSAN, since you will have chicken and the egg problems when trying to troubleshoot VSAN if the VCSA itself is having problem accessing the VSAN datastore. I think the only real, feasible solution to your problem may be to put the VCSA on another cluster, controlled by another Vcenter. 

[Paul_Sheard]

If they don't recommend it.. then this VMware document contradicts this fact

https://www.vmware.com/files/pdf/products/vsan/VMware-TechNote-Bootstrapping-VSAN-without-vCenter.pd...

The bootstrapping vsan without vcenter document is all well and good UNTIL you want to migrate the standard switches that are created when following the document over to distributed switch. The fact that the vcenter sits on the vsan datastore makes migration of the vsan network over to a distributed switch impossible.

How on earth can a document that shows the methodology of bootstrapping a vsan to allow the deployment of vcenter on to this very same vsan datastore, then state in the document that you can migrate from the standard switches created during this process over to distributed switches.. when in fact you cannot?

[Paul_Sheard]

Thanks for your reply btw, much appreciated.