November 13th, 2014 by JFrappier

Jonathan Frappier Virtxpert

That is a wrap on getting the basics of a home lab up and running in VMware Workstation.  Within Workstation we have a working Windows 2012 Domain Controller, two virtual ESXi hosts both capable of running nested 64-bit virtual machines thanks to the RVI support in the processor of the 8-core home lab system build and vCenter running.  In vCenter we have our datacenter and cluster created with both virtual ESXi hosts added.  The cluster has DRS enabled, a virtual distributed switch setup with both hosts attached and port group and VMkernel interface setup and running and demoed using vMotion to move a virtual machine from one host to another.  Not bad for 4 virtual machines barely consuming any memory on the host computer!

All that though, was leading up to this; setting up vRealize Automation and Application Services.  In my next series I will go over some of the basics of getting vRealize Automation setup in your home lab so you can start to get a feel for the various roles, requirements and setup.  Here is some handy reading in the interim (ignore anything that says vSphere SSO can’t be used)

Thank you for following along with the home lab series setup, I know there may be a few holes but again the goal was to get this setup to have an environment as the foundation to test other tools.

Workstation Home Lab Wrap-Up – On to vRealize Automation

Posted in Tech Tagged with: , , , , , , , , , , , , , , , , , , , , , ,

November 13th, 2014 by JFrappier

Jonathan Frappier Virtxpert

One of the first steps generally in setting up vCloud Automation Center or vRealize Automation would be to deploy the identity appliance, however you can also use an existing vSphere SSO implementation.  In fact, VMware has gone so far as to publish a technical white paper on how to configure vSphere SSO for high availability for use with vCloud Automation, now I won’t be doing that just yet but know its possible.

Here is the support matrix for currently supported authentication providers for vCloud Automation Center 6.1, as you can see vSphere SSO 5.5 U2b, U1c and U1b are all certified and supported.  A quick check on the vCenter server version (vSphere Web Client >> vCenter >> vCenter Servers >> vxprt-vc01; Version Information portlet) shows that the vCenter Server Appliance that was deployed is 5.5.0 build 2183111; cross reference on the VMware KB (1014508) shows that the build number correlates to vSphere 5.5 Update 2b – certified to work with vCloud Automation Center / vRealize Automation 6.1

vCloud Automation Center with vSphere SSO support matrix

vCloud Automation Center with vSphere SSO support matrix

Given we are running in a lab environment with limited resources, I am going to go ahead and use the vSphere SSO implementation bundled with the vCenter Server Appliance.  If you would like more information on deploying the vCloud Automation Center / vRealize Automation Identity Appliance, check out Emad Younis’ post on his blog.

Whether or not to use your vSphere SSO implementation for production deployments would have several factors (if resource constraint is one of them please talk to your boss about why you’re deploying vRA in the first place).  For enterprise deployments it may make sense to leverage an existing vSphere SSO deployment since your employees are likely to share a common Active Directory already.  Yes it becomes a single point of failure for both vCenter and vCloud Automation Center / vRealize Automation (unless you deploy the HA solution referenced above), but if SSO for vSphere is down, or the identity appliance is down, you’re still not getting much done until that is restored.  It may make sense to simplify support in that regard.

For organizations supporting external users, you may want to separate the authentication domains so they are not co-mingled, creating a separate security domain.  Another reason may be politics – maybe one group manages vCenter and another vCloud – if that is the case, again please talk to your boss.

I’d love to hear some of your pros and cons for separate identity appliance or using vSphere SSO.  Up next we’ll deploy the vCloud Automation Center / vRealize Automation appliance.

vSphere SSO or vRA Identity Appliance – vRealize Automation Series Part 1

Posted in Tech Tagged with: , , , , , , , , , , , , , , , , , , , , , , ,

November 12th, 2014 by JFrappier

Jonathan Frappier Virtxpert

vCenter is built, now we can start doing some of the cooler things VMware vSphere has to offer; up first – Dynamic Resource Scheduler.  DRS can be run in either manual, partially automated or fully automated mode.  Partially automated will make initial placements of new virtual machines and virtual machines during power on operations and suggest how to rebalance the cluster.  Fully automated, well its fully automated.  It will balance cluster resources based on how aggressive you want it to be.  For a deeper dive into DRS, check out the Clustering Deep Dive book, basically the bible for all things HA and DRS.

To enable DRS, log into the vSphere web client and perform the following steps:

  • Click on vCenter >> Hosts and Clusters
  • Right click the cluster you created, in my case CL01 and select Settings
  • Click on vSphere DRS and click the Edit button
  • Click the Turn ON vSphere DRS checkbox
vSphere - Enable DRS

vSphere – Enable DRS

  • Give I have only two hosts, I have left DRS Automation to “Partially Automated” – in a real use case, there is little reason not to set it to “Fully Automated” – of course you need to understand your environment and its impact before making that decision
  • If you Click on DRS Automation you can see advanced features and further explanation on the various settings.
  • When finished, click OK.  The cluster will be reconfigured.

So enabling DRS – not to hard; understanding all of the settings and how it impacts your environment – well that is typically the harder part.  As for our home lab setup, we are ready to setup vMotion – a requirement for DRS to be fully automated!

Enable DRS – VMware Workstation Home Lab Setup Part 12

Posted in Tech Tagged with: , , , , , , , , , , , , , , , , , , , , ,

November 12th, 2014 by JFrappier

Jonathan Frappier Virtxpert

So you’ve got vCenter up and running and hosts added, it’s time to enable the cool things vCenter can do – namely vMotion, HA and DRS.  I’ve gone back and forth on how I wanted to present vMotion and networking in the home lab.  On one hand many existing deployments are likely running 1Gbps, though newer ones are likely to start with 10Gbps as prices have dropped.  After a quick Twitter chat I decided to move forward as I would if I had 10Gbps networking and not have separate physical interfaces in my host for different traffic types.

When we setup our ESXi templates there was only a single NIC, let’s add a 2nd NIC to the VM’s.  For purposes of this labs (and maybe I’m still old like this) I will keep my management network on a standard switch and my VM network and vMotion traffic on a distributed switch.

  • Right click on your ESXi virtual machine and select settings
  • Click the Add… button and select Network Adapter
  • Select NAT, click Finish and click OK
  • Restart the host from vCenter (right click and select reboot) or from the DCUI (F12 >> root password >> F11)

Once the ESXi virtual machine has been restarted, you should see two interfaces in the vSphere Web Client.  Repeat for your 2nd host.

Virtual ESXi hosts with two nics

Virtual ESXi hosts with two nics

In the vSphere Web Client, click on the network tab in the navigator so we can create the VDS.

  • Right click on dc01 and select New Distributed Port Groups…
  • Name the port group vmotion and click next
  • Keep the defaults and click next, then finish, we’ll use this port group in a bit
  • Right click on dc01 and select New Distributed Switch
  • Name your switch, if you’ve not caught on yet I like short names so my VDS will be called vds0101 (Now wait I thought it was going to just be vds01…why 4 digits all of a sudden!  Easy, its VDS #1 (vds01) in datacenter 01 vds0101 :) )
  • Select your VDS version, I will go with 5.5
  • I’ll keep defaults the rest of the way here even though I only have 1 uplink right now available in my hosts, next, next finish.
  • Right click on the VDS and select Add and Manage Hosts
  • Select Add Hosts and click Next
  • Click the + New Hosts button
  • Select both hosts, click OK then click Next
  • Keep Manage Physical Adapters and Manage VMkernel adapters selected and click next
  • If you’ve followed along here, you should have vmnic1 not connected to any switch so far, that is what we will use for the VDS uplink.  Select vmnic1, click assign uplink
  • Assign to Uplink 1 and click OK; repeat for all hosts
VDS Assign Uplink

VDS Assign Uplink

  • With vmnic1 assigned to the VDS click next
  • On step 5, Manage VMKernel network adapters, you will see that we only have the existing VMkernel adapters that are currently used for management on the standard switch, no worries we can create a VMkernel interface from this page that we will assign vMotion traffic to
  • Select vxprt-esxi01 and click on + New Adapter
  • Click the browse button, select vmotion and click OK, then click next
  • Under enable services click the Enable vMotion Traffic checkbox and click Next
  • Assign an IP address from your IP space, typically you have a separate VLAN defined for vMotion traffic on your switch so you might have a management IP address of for vxprt-esxi01, my vMotion IP might be (I like my last octet to match so vxprt-esx01 would always have a last octet of .11 in any VLAN it is a part of).  In this case I am going to jump into the space so I will assign to this interface, for vxprt-esx02 and so on.  Again in the lab I’m not likely to have more than a few ESXi hosts so I’m not to worried about going into the 250s
  • Repeat for vxprt-esxi02
  • Make sure vmk0 is set to Do not migrate and click Next
  • On the analyze impact it should be no impact, click next then finish

Your hosts will be added to the VDS and vMotion will be enabled on the newly created VMkernel adapter.  To test, I have created an empty virtual machine on vxprt-esxi02 in the silver datastore, I am going to vMotion and Storage vMotion that virtual machine to vxprt-esxi01.  Here you can see the screenshot



  • Now, right click on the virtual machine and select migrate
  • Select Change both the host and datastore (we don’t have shared storage setup yet)
  • Select the cluster and click next
  • Select vxprt-esxi01 and click next
  • Select vxprt-esxi01-silver-local and click next
  • Click finish

You can see the progress of the vMotion in the Running Tasks window.  After a few minutes you should now see your virtual machine on vxprt-esxi01

VM on new host after vMotion

VM on new host after vMotion

vMotion Setup – VMware Workstation Home Lab Setup Part 13

Posted in Tech Tagged with: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

November 11th, 2014 by JFrappier

Jonathan Frappier Virtxpert

The home lab is getting close!  With the vCenter Server Appliance deployed and basic configuration done, its time to get vCenter setup – AD permissions, Data Center, Cluster and adding hosts to the cluster.  While there are only 2 hosts so far in the home lab, its still good to get an idea of all of the functions / features so here we go.

vCenter can be a bit of a memory hog, and given our limited resources I really don’t want to force my home lab box into memory crunching.  With 32GB of RAM in the host, 2x ESXi virtual machines each with 4GB of RAM and 1x Domain Controller with 2GB of RAM I am using roughly 19% of my total physical memory available (according to Windows) – that is pretty efficent given that I have assigned about 32% of the total system memory to virtual machines alone, never mind Windows 8.1 running, my anti-virus, etc… etc…  However when I boot the VCSA which has 8GB assigned, my utilization jumps to almost 50% and I have a lot more virtual machines to deploy!  After finishing the VCSA setup wizard I shut the virtual machine off, edited the VM settings to only assign 4GB of RAM – thanks again to William Lam for the research on that.  Now power back on the VCSA, in my environment I went from 50% down to 33% – a nice savings for sure.

So, time to log in and get vCenter setup, navigate to assuming you are using the same IP scheme as me.

A quick aside, you may be wondering why I am using IP’s instead of FQDN’s – my host OS, where I am doing all my work from is not using my lab DC for DNS, thus I have no way to resolve the names without editing my host file.  If you want to access vCenter by name, simply add an entry to your host file or point your DNS to the IP of your domain controller.

When the vSphere Web Client login page comes up, log in as [email protected] with the password you set during the VCSA configuration wizard.  Once logged in, the first thing you want to probably do is get rid of that pesky welcome screen, however if you are new to the vSphere Web Client take some time to check it out before disabling it and check out my other tips on the vSphere Web Client.  So here we go…

vCenter Setup:  Permissions

  • Once logged into the vSphere Web Client click on Administration >> Configuration
  • If your domain is not listed, click on the green + icon
  • Select the first radio button under Identity Source Type:  Active Directory (Integrated Windows Authentication)
  • Ensure use machine account is selected and click the OK button
vCenter Setup:  vSphere Web Client - AD added to SSO

vCenter Setup: vSphere Web Client – AD added to SSO

  • Select your domain and click the the CD looking icon with the blue arrow, this will set your domain as the default so you can log in as adusername instead of [email protected]
  • Click on Users and Groups, change the Domain pull down menu to your domain; ensure you can see users in your Active Directory and do not receive any error messages
  • Click on the home link >> vCenter >> vCenter Servers; click on your vCenter server – in my case vxprt-vc01
  • Click on the manage tab >> permissions
  • Click on the green + icon, then click the Add button
  • Ensure the domain pull down is your Active Directory Domain
  • In my AD I have created a group called vcAdmins and an administrative user for myself; jfadmin which is a member of the vcAdmins group.  In the search box type vcAdmins or which ever group name you wish to assign full administrative privileges to.
  • Highlight the group, click the Add button then click OK
  • In the Assigned Role pane select Administrator
vCenter Setup:  assign AD group permission

vCenter Setup: assign AD group permission

  • Click the OK button and ensure the group was added
  • Log out of vCenter and log back in with a user account that is part of the vcAdmins group
  • Once signed back in, click on vCenter and confirm you can see the vCenter server in inventory

vCenter Setup:  Create Datacenter

Now that we are logged into vCenter with an administrative user, it’s time to setup our datacenter.  Now a data center is really just a construct/container in vCenter.  If I wanted I could create multiple data centers inside vCenter even if all of the compute resources were in the same physical location, even in the same rack, even sharing the same network.  What I would not be able to do as of vSphere 5.5 is vMotion or “live migrate” virtual machines from one data center to another.  In my lab I will be creating a single data center.

  • Click on Hosts and Clusters
  • Ensure you are on the summary tab and see vCenter in the Navigation pane
  • Right click on your vCenter and select New Datacenter…
  • As you can see from the wizard, there isn’t a lot we can do in terms of settings at the data center level, name your datacenter, I prefer short names so I am going with dc01; click the OK button

A quick aside here; keep in mind when naming components in vCenter that down the road you may need to integrate other products.  For example in the past I have seen problems when trying to use Vagrant to bring up virtual machines in vSphere because of spaces in the names datacenters or clusters.  Keep your naming simple but identifiable.  I also prefer all lower case for my naming scheme.

vCenter Setup:  Create Cluster

With the datacenter created, we can now create our clusters.  Clusters play a big role in vSphere so while they are simple to create, managing the settings at the cluster level are vital to understand.  We’ll get into that in a future post but just know a cluster is where your add resources such as compute/servers and configure VSAN, EVC, HA and DRS, assuming you have the appropriate licensing.

  • Right click on your newly created datacenter and select new cluster
  • You can see that there are quite a few options here for the cluster, we won’t enable them all now but have a peak through and see what is available
  • Name your new cluster, again I prefer simple so cl01 will be my cluster name; click the OK button

With different physical hosts, EVC is one item you may have enabled right away.  EVC “standardizes” on a processor feature set so that virtual machines can move between different physical hosts with different processors, assuming those processors can share a common processor feature set.  You cannot mix Intel and AMD processors.  In this home lab build with all virtual ESXi hosts, our hosts processors will all be identical.

vCenter Setup:  Add hosts to cluster

Now with our cluster build, we can now add the two virtual ESXi hosts we created in workstation earlier.  There will be warnings/errors after adding the hosts, don’t worry those are expected and we’ll take care of them!

  • Right click on the cluster you just created and select Add hosts…
  • Type the hostname of one the ESXi hosts you created in DNS, in my case vxprt-esxi01 and vxprt-esxi02, click next
  • Type the username (root) and password you set during setup, click next
  • When prompted to accept the certificate, click yes
  • Review the information and click next
  • On the license screen you can use the trial license or if you have license keys, enter the key here and click next
  • Click next on the lockdown mode screen without selecting the Enable lockdown mode checkbox (lockdown mode disables access to the DCUI)
  • Click finish, the host will be added to the cluster
  • Repeat for the remaining virtual ESXi hosts you created

If you added local storage to your first ESXi hosts like we did in a previous posts you should see that host added with no warnings.  The 2nd ESXi hosts has no storage available for logs because it was only setup with a 1GB drive for the OS.

You now have the basics of a working vCenter setup, up next is some of the more advanced features like vMotion and HA!

Home lab vCenter setup - datacenter, cluster, hosts

Home lab vCenter setup – datacenter, cluster, hosts

vCenter Setup – VMware Workstation Home Lab Setup Part 11

Posted in Tech Tagged with: , , , , , , , , , , , , , , , , , , , , , , , ,