vCenter Server Appliance 6.0 in VMware Workstation

For demo’s, presentations, breaking environments or just killing time I have a portable testlab on my notebook. Yes I know there are also options for permanent labs, hosted labs and Hands-on labs for these same purposes. Great places for sure, but that is not really what I wanted to discuss here.

As I am break.. ehhh rebuilding my lab to vSphere 6.0 I wanted to install VCSA 6.0 in VMware workstation. Nice, import a my vmware downloaded VCSA-versionsomething.ova (after e-mail address number ####### registered over there) and we are done! …….. Well not quite.
First the vCenter download contains the OVA, but it is a little bit hidden. The guided installer will not help you here. You will need to mount or extract the downloaded ISO and look for vmware-vcsa in the vcsa/ folder.

VCSA Location
Copy the vmware-vcsa file to a writable location (when just mounted the ISO) and rename vmware-vcsa to vmware-vcsa.ova. And now we can import the ova to VMware Workstation. When the import finishes, do not start the VM yet. Certain values that are normally inserted via the vSphere Client or ovftool are to be appended to the VMX file of the imported VCSA. Open the vmx in the location where you let Workstation import the VM. Append the following lines: = “ipv4” = “static” = “” = “8” = “” = “”
guestinfo.cis.vmdir.password = “vmware-notsecurepassexample”
guestinfo.cis.appliance.root.passwd = “vmware-notsecurepassexample”

Note: Change the net and vmdir/appliance.password options to the appropriate values for your environment.

If not appended when you start the VCSA an error: vmdir.password not set aborting installation is shown on the console (next to root password not set) and network connection will be dropped even if you configure these on the VCSA console (via F2).

Save the VMX file.

And now it is time to let it rip. Start up your engines. And be patience until…lo and behold:

VCSA Running in workstation

And to check if the networking is accepting connections from a server in the same network segment open up the VCSA url in Chrome for example. After accepting the self signed certificate unsecure site (run away!) message you will (hopefully) see:

VCSA in Workstation

Next we can logon to the Web client (click and accept the unsecure connection/certificate) and logon via [email protected] and the password provided in the VMX (in the above example vmware-notsecurepassexample). As a bonus you now know where to look when you forget your lab VCSA password ;-).

VCSA 6 Web Client

(And now I notice the vCenter Operations Manager icon in the Web Client Home screen. Why is this not updated like vRealize Orchestrator 🙂 )




Design Choice: vCenter Windows or vCenter Server appliance?

A question that is again popping up lately is whether customers must go for the vCenter Server Appliance (VCSA) or a Windows based vCenter system. Yes I have my favorite, but I will often go for the consultant answer: it depends. But on what does this depend? I will try and sum up some of the arguments to take in to account.

But first, what is this VCSA your talking about?

You may or may not know vCenter can be deployed in two ways, the commonly known vCenter installation on a Windows based host(s) or deploying vCenter as a appliance. The appliance is a 64-bit Linux based (SUSE Linux Enterprise for the distro interest) virtual machine with an embedded database (vPostgres) or the option to use an external Oracle database. The appliance has been around since it’s introduction with version 5.0, but has not been really production worthy since the 5.5 version. With the 5.5 version the vCSA supports managing 100 hosts and 3000 VM’s with the embedded database versus the 5 host and 50 VM’s with the previous version. The 5.5 limit for the external Oracle database is even higher (100 hosts and 10000 VM’s), but to be honest I haven’t seen that combination around.


The appliance is build with the following vCenter services: vCenter services (vCenter, Inventory, SSO, Web Client) and services such as syslog collector, dump collector, AutoDeploy (and capable of doing DHCP/TFTP).

vCSA services

What are the arguments to consider?

  •  For organizations that are having a DBMS install base of MSSQL there is currently no support of using this in combination with the vCSA where the Windows based happily works with MSSQL (via ODBC DSN). If there is no experience, no business investment or no DBA’s wanting to manage an additional DB flavor you can stop right here (or wait when a next version of VCSA will hopefully support MSSQL as an external database).
  • Windows vs Linux install base and license. You got your Windows based organizations and you got your Linux based organizations. More often they are mixed. Got Windows data center licenses sorted out for your organization, another Windows VM is often not an issue. Need to save some licensing or just don’t want to invest in new, VCSA will probably be more of your taste. Beware that you can’t install Update Manager on VCSA, this still needs to be set up on a Windows host which can be an existing. Same goes for your trusty toolset, PowerCLI needs Windows PowerShell, RVTools need .Net. These tools can be easily put on a management server or admin workstation (where the toolset are supposed to be on the first place), they connect to VCSA just as vCenter on Windows. Need remote CLI? Added by deploying the vSphere Management Assistant (vMA) appliance. For Windows only based IT departments a knowledge investment is needed to support Linux based appliances.
  • vCenter Orchestrator. Windows vCenter installers installs vCenter Orchestrator on your Windows system or you can use the Windows installer to install Orchestrator on another designated Windows server. vCenter Orchestrator is not installed on the VCSA, but there is the vCenter Orchestrator appliance you can deploy next to it.
  • Linked mode. Want a single management plane, or in other definition a Single Pane of Glass, for multiple vCenter instances linked mode is required. VCSA does not support Linked mode where vCenter on Windows does. There is an other option, leveraging the built-in SSO Replication by joining all (or some you want to share) SSO instances under a common domain. A benefit next to the automatic synchronization, is that you will be able to see the inventory of all SSO instances from whatever Web client.
  • Experience with appliances. I think appliances add simplicity for deployment of the vCenter systems, but can be a hassle to (re)configure and for example do database back-up dumps when you don’t have any experience with Linux. Don’t worry, VCSA has an admin Web interface or the vSphere Web client for configuration tasks and when you need the console commands are documented. The procedures are on Documentation Center, Knowledge Base and widely blogged about in the community. Go ahead and learn appliances as there are a lot of good ones.
  • Monitoring/Back-up. Monitoring of vCenter server services and system parameters. If you use a Windows based or agent type of monitoring, the Windows based monitoring does not work for a Linux appliance. Check if your monitoring solution supports Linux. Same goes with thinking about your back-up strategy and how to back-up the VCSA.
  • Physical vCenter. When there are reasons to install the management of your virtual infrastructure on a physical server outside the virtual infrastructure, than Windows vCenter is the only option. VCSA is a virtual appliance which needs to be deployed on virtual environment. Depending on the requirements, you could also go with an VCSA deployment in an other vSphere cluster than the one vCenter is managing.
  • IPv6. IPv6 is not supported on the VCSA and is supported on Windows. If you happen to use IP addresses in the vCenter configuration or connecting to vCenter these are IPv4 only. To connect to vCenter system in an IPv6 environment you must use the fully qualified domain name (FQDN) or host name of the vCenter Server. FQDN is preferred to be used in any case.
  • vCenter Server Heartbeat. Use this solution to protect your vCenters, you cannot use this with the VCSA. But on the other hand, you should be working on a replacement solution (you have some time) as VMware announced EOA of all vCenter Server Heartbeat versions. See details here: Leveraging vSphere HA instead for example.

Note: These arguments are not ordered by importance, that’s is up to the organization in question.

And what do you think?

I have a favorite, but do keep in mind that there is no one size fit’s all. I happen to like the appliance way of deployment, simplicity at your fingertips and no abuse from Windows admins logging on and hogging the vCenter resources (sizing) with OS / RDS footprint. Or worst destroying to system with all those I needs this and this tool for my work.

Yes you need Windows for Update Manager, which can be combined with other update management tools. And yes you need your Windows based tool set somewhere, are those supposed to be on the vCenter server in the first place?
When a design decision is made to use the Windows based vCenter, please use it as an infrastructure server. Don’t abuse it as an administrator playground (aka RDS server, aka steppingstone, aka PowerCLI test heaven). I like to remove the GUI aka use core when Windows is the design choice (PowerCLI Get-WindowsFeature *gui* | Uninstall-WindowsFeature –Restart). From Windows version 2012 switching from GUI to core does not require a reboot.

What do you think? I’m interested in your views. Let me know in the comments.


VMware vSphere Auto Deploy and the GUI fling

As in my earlier IO Analyzer blog post, flings in VMware labs are an excellent place for very useful tools and extra’s for your VMware environment. You can find the VMware flings page at

One of the flings I want to blog about is the Auto Deploy GUI. This fling is a front end graphical user interface to the Auto deploy server. The standard auto deploy proces is heavily VMware PowerCLI based. This can be a problem at some organisation where IT personnel is not yet PowerCLI/Powershell familiar. No excuse, but it can be helpful to lower prerequisite knowledge and add a GUI to the process. This way it might be easier for those organizations to accept VMware auto deploy.

Let me be clear…… this is no excuse to not learn PowerCLI. So please up your PowerCLI/Powershell skills as you will use that at a lot of places (also outside of the VMware infrastructure) and makes you life a lot easier (well, that is… after you learn it).

What is Auto Deploy?

Before you add something to a infrastructure, the Auto Deploy components should be known. vSphere Auto Deploy facilitates a infrastructure for automatic server provisioning and network deployment of the ESXi hypervisor. The deployment can be on local storage, statefull on HDD, SD or USB or stateless to the hosts ram. It works in conjunction with:

– vCenter,
– host profiles,
– TFT server,
– Auto Deploy server and Image Builder,
– a PXE boot infrastructure with a DHCP service.

These service can be installed on the vCenter host or hosted/integrated on specific services.  When using the stateless host option be sure to have a high available Auto Deploy infrastructure.

Auto Deploy and host profiles are available from the Enterprise plus Edition.


Auto Deploy server can be installed on a Windows based server, or can be used on or with the vCenter Server Appliance (vCSA).

Why a VCSA, when the 5.1 version with embedded database is for small deployments (maximum of 5 hosts) I hear you ask? Automation and centralized management! …And the fact the vCSA 5.5 will support a lot more hosts…..

As we need a Windows based service for the GUI and normally would need a Windows server for Update Manager, we can combine those on Windows based server.

For this blog post I’m using a 5.1 vCSA installation and Windows based server operating on Windows 2008R2 running Update Manager and Auto Depoy services (including DHCP for PXE boot).

Setting up Auto Deploy services

Here we had a choice (why always these choices…..) to use the vCSA vCenter server components together with Auto Deploy service or you a standalone Windows server for auto deploy services working together with the vCSA for vCenter services. The last makes a little more sense as the Auto Deploy GUI also needs Windows components, and so will Update Manager. If you happen to want to use auto deploy on the vCSA the service needs to be started. Like stated above I’m doing a Windows based installation in conjunction with the VCSA for vCenter services.

How the lab is build:

– VCSA5.1 downloaded and setup.
– Also downloaded the vCenter VIM installer to install Auto Deploy on the Windows host (You will also need this installer if any other vCenter service need to be on a Windows system. For example Update Manager).
– Windows 2008R2 Set up. All defaults.
– DHCP Role added to Windows 2008R2. You can setup your IPv4 scope here, but I will set it up when I’m ready for the TFTP to service. (And don’t forget other devices that offer DHCP such as your internet router, separate the traffic. I have added a LAN segment and let the W2K8R2 DHCP only serve this network. ESXi VM should be connected to this same network).
– Downloaded TFTP Server from Solarwinds (Free version at
– The TFTP server needs .Net Framework 3.5, and so does Auto Deploy Gui so install it to the server (Add Feature).
– Installed TFTP server on Windows 2008R2 and setup starts it. The folder c:TFTP-Root is used default.
– Install PowerCLI.
– Install Auto Deploy service. The default installer will register Auto Deploy with the VCSA.
– Setup a DHCP scope with option 66 = Boot Server Host Name to the IP of the Windows server. And add option 67 = Nothing Yet. We are gonna add the BootFile name later.
– Let’s check if the DHCP scope can serve a ESXi host. Create a VM to the DHCP served LAN segment. And start it up. DHCP is received, TFTP is looked up. And fails because it can’t find Nothing Yet. But we know DHCP is ok.


We can setup the boot image by opening the vSphere client and connecting to the vcenter. Click Auto Deploy (Administration). This will open the following screen:


Now click the download TFTP Boot Zip link and save to (and extract) to the TFTP-Root directory. You will probably need to change the file download to enabled to the IE security settings for Internet zone.

Change the DHCP option 67 to “undionly.kpxe.vmw-hardwired”. (still the PXE boot will fail because no ESXi image is yet prepared)

Setting up Auto Deploy with GUI

First we install the GUI this is really straightforward. This adds an plugin under Solutions And Application to your environment.


(This actually also has the link to download TFTP Boot zip).

Next up configuring your environment.

1. First up VMware depot, Right click and check or add VMware depot url to­‐depot-­‐index.xml. (default it is in)
2. Next HA depot. Right click HA depot url. This should read http://<vchostname>/vSphere-­‐HA-­‐depot/index.xml. Else add it.
3. If you need a specific custom component (for example a Nexus VEM) you can add a zip depot.
4. This will fill up the Images in the Image Builder screen. Here you can build up your organization specific images (with specific software packages). For now I leave the defaults and move on.
5. Now we create the first deploy rule. Click the add rule and fill in the name,
6. I set it to the ESXi5.1 standard image, select where it must land (I select a host folder I created), select an host profile we skip (not yet created, if you have select your appropriate profile), in the rule set you can setup up a specific pattern (for example asset tag or vendor) very useful but not for this demo. I select apply all.

This will start up tasks to inject VIB’s to the cache. After this the rule is created.


7. Activate the newly created rule by right clicking and selecting active.

Start up the test VM created earlier (or reboot when it’s still is failing) and see if the host is added to the Auto Deploy Host folder.


Yup this time it found an image. Loading and you will notice a cache loading of ESXi next.


Received a DHCP address for the booted host. Let see if vCenter shows the host added to the correct host folder.


Success, base image and add to a vCenter managed infrastructure is done. Warning is about the unconfigured state and to non-persistant storage for the scratch partition.

What’s next?

To use your ESXi hosts in auto deployment scenario you will have to set up host profiles and add this to a deployment rule (or more if you have several environments).
Configure a host to be setup according to your environment (DNS, NTP, networking, name it….). Create a host profile from this host and fill up an answer file. Check compliancy to be sure this one’s correct.

Add this profile to the deployment Rule and voila you ESXi is deployed and setup in a profile.

– Enjoy your Auto deploy infrastructure with the Auto Deploy GUI! Be sure to learn PowerCLI another time!