Deploying VCSA via the CLI

I was recently deploying a series of VMware vCenter Server Appliances for a customer who wanted to migrate to that platform from their windows based vCenter 5.5 environment.  Rather than deploying all of these by hand, we figured that this was an excellent time to check out the VCSA command line install options.

The first thing that we had to do was to figure out our architecture.  In this case, it was pretty easy.  Each site was getting a vCenter appliance and a PSC appliance.  We decided that we wanted our PSC appliances to replicate with each other, so that we could use the enhanced Linked Mode functionality in vSphere 6, and so designed a ring topology to reduce the impact of a given site being offline.

The first thing that we had to do was to prepare some JSON answer files.  To do that, open your vCenter Server Appliance install ISO and browse to vcsa-cli-installer\templates\install and examine the bounty contained within.

Copy the example .JSON file(s) that most closely matches your environment (why make extra work for yourself?) and name it something meaningful, then open that bad boy up in a text editor.  Go through that config file and set it up to work in your environment.  It's a little arduous because you're probably going to need to modify almost every line, but once you do it you'll have a perfectly good answer file that you can use over and over again.  Also, you'd need to type all of that eventually anyway, so now you can front-load your efforts.

Once the JSON is created and saved, you can move forward with the actual deployment.  Most environments will likely use a vCenter with an external PSC, so if that't what you're working with, make sure to deploy the PSC first.  If you're working with a simpler environment with an internal PSC, then just go right ahead with the main appliance deployment.  Either way, deploy it from the command line like this:

.\vcsa-deploy.exe --accept-eula <path to your PSC answer json file>

After the PSC is deployed, run the command again, but this time point at the answer file for your VC appliance.

.\vcsa-deploy.exe --accept-eula <path to your VC answer json file>

After that deployment finishes, you'll have a nice clean vCenter 6 environment, ready to use.  You'll want to sign in as administrator@vsphere.local (using the password that you specified in the json) and then you can move forward with configuring things (joining the domain, etc.)!

2/16/17 Update: Jeff has put together a post with a nice description of how to set up a vCenter/PSC Ring Topology over on his blog.  Check it out for details about how we set this up!

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more