vSphere / Lab For Beginners: Part 4 – Virtual Distributed Switches & Migrating Networking (VSS to vDS)

Aside 24/10/201602/05/2017 Alec Dunn (LegoYoda) Beginner, Community, Labs, VCSA, VMware, vSphere 6.5, Beginner, Community, home lab, HomeLab, how to, Install, Install GUide, iscsi, lab, VCSA, virtual center, VMware, vSphere

Where are We?

By this point we should be in the position of having our lab cluster up and running, configured for storage and able to authenticate against a real domain with all the control that gives us. We haven’t yet enabled any of the advanced features like vMotion though as this would have required network configuration that we would have removed in this stage.

What’s Next?

VMware provides two different ways to configure networking Virtual Standard Switches (VSS) and Virtual Distributed Switches (vDS). So, what’s the difference? Standard switches are, simple, easily configurable switches that have to be configured individually on every ESXi host you have. They also dont need Virtual Center to work. Additionally, for features like vMotion to work they must be configured identically across all hosts. This a management pain and when you scale, it doesn’t!

Virtual Distributed Switches are a centeralised switch that hosts can be members of. They are managed from vCenter and provide unified management of the estates networking and advanced features not in VSS (such as pVLAN tagging).

So, in this part of our tutorial we are going to do a few things.

Create a new Virtual Distributed Switch
Migrate the initial VSS configuration and virtual machine networking over to the vDS
Create a vDS VMKernel Port Group and enable vMotion (because we havent set this up in VSS at this moment).

A small note. In a real environment you would be running with network uplink redundency and would be able to do this in 2 stages. In this example we only have 3 NICs and we will have to migrate components one at a time using the ‘spare’ physical NIC. This means that there is a lot of repition in this part of the blog. It’ll help to understand the process!

Why Do I Want to Do This?

Simply because in the real world you’re unlikley to encounter many enterprises using VSS configurations. vDS setups are more flexible and more widly in use. From a lab perspective it also means you get to play with more advanced features once you’re familar with vSphere so you may as well enable that functionality now.

Step 1: Create a new Virtual Distributed Switch

First we have to create the actual switch within vCenter. So, log on to the vCenter Web Client as before with administrator rights and swititch to the networking tab on the left. Select you Data Center and then click the Actions dropdown. Expand Distributed Switch and select New Distributed Switch.

This brings up a familiar looking wizard. Give your switch a friendly name (it’s good practice to denote that it’s a distributed switch in the name). Click Next.

You can now select the version (feature level) of you vDS. In this example we’re going for the newest to enable all features. In the real world you may want to select an older version if you are integrating with an older VSphere suite. Select the newest version. Click Next.

We now get to choose the number of uplinks we want to assign to the switch. Uplinks map to physical network adapters. The default is 4 and we are going to go with this (even though the lab in this example only has 3 Physical NICs). You can have more uplinks than Physical NICs no problem (they just wont work or don anything).

We also get the option to Create a default Port Group (A port group is analgous to a set of network ports you’d plug wires into, grouped together for a similar task). This first Port Group is the one you’d probably assign for connecting Virtual Machine vNIC to (to enable communication). Give it a friendly name and click Next.

You now get a summery page detailing what has happened and, interestingly, what your next actions should be. Click Finish.

So, we’ve now created a basic Distributed Switch, created a set of uplinks for it (as yet NOT assigned to a Physical NIC) and created a default Purt Group which we shall use for VM connectivity.

Step 2: Add Hosts to the vDS

Now the vDS is created we have to assign our ESXi hosts to the switch and create the additional port groups we are going to need (for Storage and vMotion in our case). To do this navigate to the Networking tab in the Webclient, select the distributed switch we created above, Select the Manage tab (configure in version 6.5), selct settings and then Topology you’ll now need to click on the icon.

This will bring up the Add and Manage Hosts configuration Wizard. This is a Wizard we will keep returning to whenever we make a change to the vDS.

Firstly we will need to add our hosts to the vDS. Select Add Hosts and click Next.

Here you’ll need to select all the hosts you have in your lab and click OK.

You’re shown a confirmation screen. Click Next. Continue to the end of the Wizard and Finish (without altering any configuration). Remember, we’re just connecting the hosts at this point, taking it step by step.

Step 3: Crete Other Port Groups

Now we’re going to create the remaining Port Groups we will need for ther lab. These include:

A portgroup for iSCSI storage that we will migrate our ‘storage’ VSS to.
A portgroup for vMotion to enable this feature.

Each portgroup will have a dedicated uplink associated with it (and each uplink will have a dedicated physical NIC).

So, from the vSphere Web Client, navigate to the Networking tab, select the Distributed Switch we have created and right click on it. Select Distributed Port Group and then New Distributed Port Group.

You’ll now be presented with a simple wizard:

Give the Port Group a friendly, descriptive name. Click Next.

Keep the default options for the switch (we can do configuration and explination in detail another time). Click Next.

The Summary screen is shown. Click Finish.

Repeat this Wizard three times. I have created three Port Groups called:

StorageDPG (for iSCSI traffic and access to storage).
VMNetworkDPG (for Management and VM communication) [Renamed default Port Group from Step 2].
vMotionDPG (for vMotion traffic).

At the end of the process you should have something like this.

Back in the Topology view for the vDS you should now see something like this. IT shown the Distributed Switch with it’s uplinks (notice there’s still no physical NICs associated with them). You can also see t he portgroups on the left (currently with no details or items assigned to them).

Now, we have to add Physical NICs to the Uplinks.

Step 4: Add Physical NICS to Uplinks

Click on the icon fromt he topology view to initiate the Add and Manage Hosts wizard again.

Click the Green plus symbol labelled Attached hosts.

Select all the hosts in the lab cluster (all of the ones shown below in this example).

The confirmation will be shown as below. Click Next.

On the next wizard screen select the Manage Host Networking option and click Next.

Now ensure only Manage Physical Adapters is selected and click Next. In this step we are only going to add the spare adapter.

Select the currently not used (or extra) vNIC and click the Assign Uplink button. Assign it to Uplink 1. Note: In the example below if we try to assign one of the vNICS from vSwitch0 or Storage we would end up disconnecting the physical link from the switches BEFORE migrating the networking over to the vDS. This would mean that either Management+VM networking or (worse) storage to the running VMs (Including this vCSA) would die. This causes a horrible mess and is why you should probably run dual NICS / switch in reality (so we could connect half to the new vDS and leave half where they were and do a seemles switchover).

As mentioned above this lab example doesnt have this so we have to perform a rolling migration with our currently unassigned NIC. If you’re messing around in a lab that has multi physical NICs but no spare (but vMotion has been configured) then use the NIC assigned to the vMotion interface as the ‘spare’ as this isn’t a critical componant of keeping a VM alive.

Check everying is assigned to the correct (free) NIC. Click Next.

The next screen shows an impact summary and should alert you is you’re about to do anything stupid. We’re not. Click Next.

Click Finish and the process should complete momentarily. Back at the Topology screen you should notice that the Uplinks sections of the diagram now shows adapters assigned to Uplink 1. In tis example, 2. One for each host.

Step 5: Migrate Networking

Again, click the Add and Manage Hosts button from the topology view and ensure, this time, that just Manage host Networking is selected.

Select both hosts again.

Now ensure Manage VMkernel adapter and Migrate virtual machine networking options are selected.

Now select the VMK0 adapter currently assigned to vSwitch0 (Management Network) and select the Assign Port Group button.

Assign this to the newley created VMNetworkDPG vDS port group and ensure the same is done for the second (and any other additional) hosts in your environment. Click Next. Leave the storage adapter alone for the moment.

Check that nothing will be broken in the Analyze Impact window.

Now, on the Migrate vm Networking window expand and ensure all the VMs currently in the lab are migrated over to the new Port Group. In the example be low you can see the three VMs already in my lab (including this VCSA) ready to migrate from the VM Network VSS Port group to the VMNetworkDPG vDS Portgroup.

Review the settings to ensure everything is as it should be. Finish the wizard.

You should now see, in the topology view, the three VMs attached to Uplink 1 and, crucially, you should still have network connectivity to the LVCA web interface.

Next, restart the Add and Manage Hosts wizard to move the next set of items over.

Select all the hosts in the lab.

Select Manage physical adapters and Manage VMkernel adapters.

Now assign the NIC in use by vSwitch0 (which we migrated the networking OFF off in the last step through the wizard) to Uplink 2. Do this for all hosts in the environment.

Now click the Assign Port Group button and ensure that the vmkernel port currently used for storage in the VSS is migrated to the StorageDPG . Notice how we are rotating the next VSS switch to the DPG to free up the final adapter in the next step.

A final check on the Analyse Impact screen and it is showing a warning. In this instance it is simply telling us that we are switching physical NICs in this operation. We know this to be the case as were having to shuffle non resilliant connections.

Check the summery screen and Finish

Once complete we, again, should still ahve access to our VMs (the storage is still connected) and the StorageDPG portgroup and vmk ports anre connected to Uplink 2

For one final time. Restart the Wiard and select Manage host networking

Add all the hosts from the environment.

Ensure the Manage physical adapters and Manage VMkernel adapters options are selected.

Assign the final unused NIC from the VSS to Uplink 3. This should be the NIC assigned to the Storage switch in the old networking.

On the Manage VMkernel adapters screen click the New adapter button.

One the Select target device screen click browse to select an existing network.

Now select the vMotionDPG portgroup that was created right back at the start of this stage of the guide. Note in the screenshot belowthe WRONG network is hilighted…

For the Port Propeties tick vMotion traffic under enable services.

Assign the new VMkernel port for vMotion an IP address and appropriate subnet.

Now assign this new VMK port to the vMotionDPG distributed port group on all hosts. NOTE: In the picture below I got it wrong for host esxi01. Host esxi02 is CORRECT.

One final Analyse Impact screen is shown. Move on to thee Summary screen and complete the wizard.

Like before, you should be able to see the two new VMkernel ports assigned to the vMotionDPG port group.

That’s it. We have migrated all the networking from VSS to vDS and created a final DPG and VMK port for vMotion capabilities. We now have centerally managed networking from within vCenter with the ability to migrate VMs across hosts. We also have the storage and regular network traffic controlled fromt he same area.

Step 6: Cleanup

Now everything is controlled by the vDS we just need to clean up the older VSS configuration. To do this from the Web Client select the individual host from the Hosts and Clusters view, select the 1st host, the manage tab, networking and then virtual switches. This will list the vDS and the two (obsolete) standard switches (vSwitch0 and Storage). Select the 1st VSS and click the red ‘x’ to delete it. Now do the same for the final VSS. NOTE: In version 6.5 select the switch, click actions then select remove.

Remember that you will have to do this for all the hosts you have as VSS and not centerally controlled.

What’s Next?

Next we will roll through some of the feaures in vCenter such as HA, DRS and vMotion. this will be in part 5 of this beginners series.

vSphere / Lab For Beginners: Part3 – Domain Based Authentication

Aside 01/10/201602/05/2017 Alec Dunn (LegoYoda) Beginner, Labs, VCSA, VMware, vSphere 6.0, 6.5, Beginner, esxi, home lab, HomeLab, how to, Install, Install GUide, lab, VCSA, virtual center, VMware, vSphere

So, What Do We Currently Have?

At this point we have a functioning vCenter server containing a datacenter construct and a cluster with some ESXi servers. These are all authenticating using the built in SSO (Single Sign On) server and all networking is done via VMware Standard Switches (VSS). These should all be configured exactly the same for basic networking across all hosts.

We could go and start deploying VMs now and creating additional vmKernel ports to enable vMotion etc. BUT VSS configs are a pain to manage and scale out (as everything has to manually be configured identically) and dont provide anyof the advanced features or centeralised management that virtual Distributed Switches do (vDS). Also, you’d be hard pressed to find a real world deployment using just standard switches.

What We’re Going To Do Next?

This post is going to deal with one of two things that you should do right now as it’s far, far easier to configure these features before going forward than it is to try and change later when VMs are running and using all the vSphere features.

Configure vSphere (ESXi and vCenter) to use domain authentication for added, more flexible, more real world security).
Configure vSphere with a custom group to allow users to be given very specific roles and permissions.

We will configure advance networking in the next part of this series.

Why Are We Doing It?

Simple, because this is one of two changes to the basic config that are typical of what you’ll find in real world deployments and enable more features and flexibility in your lab whilst being easier to manage.

Stage 0: Stop the VCSA root Password From Expiring and Configure NTP

In this blog post we are going to configure the vSphere environment to use AD Authentication vs the inbuild SSO authentication. But what if something goes wrong and both authentication sources require remediation. Simple, you log in as root to your appliance and you can fix stuff. True, but…. By default the root password in VCSA will expire after a year which can leave you high and dry. It’s simple to fix so, before going any further, lets configure it to never expire.

Navigate to your VCSA’s admin web interface. This is a specialconfiguration interface with basic appliance settings. it’s avaialble at https://<VCSA-Appliance>:5480

Log on to the appliance’s web configuration interface using the root user and the password defined in the setup script from Part 2 of this blog series.

Navigate to Adminsitration and ensure that No is selected under Password Expiry Settings > Root Password Expires. Click Submit.

Now we can quickly configure the time service to the same values as we did for the ESXi hosts. Select Time from the menu and then the Edit button.

Click on the dropdown for Mode and select NTP from the list of options.
Now enter uk.pool.ntp.org (Assuming this is the server you entered into the ESXi NTP configuration earlier) under the Time Servers area and click OK.

The VCSA is now configured to use NTP as it’s time source.

Stage 1: Configuring For Active Directory Authentication

What You’ll Need

In order to connect the VCSA to an Active Directory for authentication you’ll need to have an account in the Active Directory set up to allow vCenter to be joind to the lab domain. For this example I recomend creating a service account to perform this function.

I have created and will be using the following in this example: svc_ldap@lab.local

NOTE: It does not need to be an admin user as a standard AD account can join 10 computers to a domain. This is only going to join 1.

Join The VCSA To The Domain

Open a browser to https://<vCSA_Address>/vsphere-client/

Log on to the appliance using the administrator@vsphere.local account and the password set up when you deployed the appliance.

From the Navigator pane select Administration to open the admin sub menu.

Select Deployment > System Configuration

This will open System Configuration. Select Nodes then hilight the VCSA from the list (of one). Now Select the Manage tab and click the Join button.

This will bring up the Join Active Directory window. Enter the information required to join the domain. In the example below:

Domain: lab.local [The full name of the domain you wish to join]
Organization Unit: <optional> [The DN path of the AD area you’d like the VCSA to be placed.
User Name: svc_ldap@lab.local [the service account created earlier]
Password: <password> [The password]

Click OK.

Unless there is an error noting obvious will happen. You will have to reboot the appliance to see the changes applied. Once it has rebooted, navigate back to the same place and notice that the domain is now listed as joined.

Now we should configure Active Directory as an Identity Source within vCenter. This will allow us to use domain credentials to logon to vCenter and control access via domain group membership. To do this navigate to Single Sign-on > Configuration and open the Identity Sources tab.

Click green plus to start the process to add an identity source.

the simplest method to use is the one listed below. So, in the Add identity source window, select Active Directory (Integrated Windows Authentication) option. Ensure the domain name is correct (i.e. the same as the domain we just joined inthe steps above). and select the Use machine account option. Clock OK. toadd the identity source.

NOTE: this will only work if the VCSA is joined to a domain already. This is what we achieved in the previous step so it will work for us.

We can now use Active Directory as an authentication source but, right now, we still need to configure vCenter to give permissions to users/groups to allow this to happen. Firstly off it makes sense to give a domain account administrative access to vCenter so we can stop using the administrator@vsphere.local account.

Navigate to Single Sign-On > Users and Groups and select the Groups tab.

This window allows tyou to create a new group for use in vSphere or add users / groups in to an existing group. Scroll down and select the Administrators group (this is the default group vSphere has for high level access to vSphere). You’ll see that the only member of this at the moment is the accoiunt you’re logged in with right now.

Click the Add Member (under the Group Members heading). From the Domain drop down ensure you select the Active Directory domain you want (In our example lab.local). You can now select the user or group from the domain to add to the group. I’ve added both (shown below). If you’re following best practice you should probably create a group in Active Directory, add users to that group and add this group at this step.

Now, when we look at the group, we should see our new entries listed.

To test this worked log out of the web client and try logging back in as a domain user (as shown below. You have to use the format <user>@<domain>.<whatever> in VMware products

If Successful you’ll be back in the main Web Client window and you should be able to see and do whatever you want. You’ll also have your domain username shown in the top right

Stage 2: Creating Groups With Custom Permissions

Being able to add users and groups from SSO and a Windows domain to the built in vSphere groups is great and all that but, what if you want to offer more granular permissions or restrict a user / group to a single task in Virtual Center. This is where Roles/Global Permissions can come in handy.

What’s The Process Then?

Simply it’s this:

Create a new group.
Add Users and Groups to this group.
Create a new role with custom permissions
Assign the created group the new custom role

Create a New Group, Assign Users

As in stage 1 navigate to Users and Groups and the Groups tab. Now Create a new group by clicking on the green plus sign. In this example I’ve named it as below. This gives a good explination of the purpose of this demo.

Once the group is created add in a user from Active Directory that will eventually have the rights we’re about to define. In this example I have pre-created a domain account called No Access. It’s just a basic domain user account I’m going to use for this process.

Create a New Role In vCenter

Now Navigate to the Access Controls > Roles section of vCenters Administration settings. From here we will create a new role which simply has permissions to Create a Datacenter.

The Roles screen is displayed. Click the green plus to create a new role.

Name the role and assign the permissions you want granted to users of this role. In this example I’m Createing a role called Create Data Center and assigning only one permission, that of Create Datacenter. Click ok to create the role.

Assign Users This Permission

Now we need to assign this permission to users or groups. In this example we will assign the role to the previously created vSphere group (above). Navigate to Administration > Global Permissions.

Select the Manage tab and click the green plus to add the new permission. Note that this screen lists all the currently active permissions.

Now Add the previously created group from the vSphere.local domain (notice that this vsphere.local group contains lab.local users) and click OK.

Finally select the created Create DataCenter role from the dropdown on the right and click OK. You have now created a permissions group, added domain users to it, created and new role and finally assigned this role to the new group.

You can see the effect of this immediatly by simply logging out of the vSphere Web Client and logging back on again with the user assigned to the group. So, in this example, I would log back on with the NoAccess@lab.local user and I should find that I can log on but all actions on all objects within vCenter are now greyed out except for the ability to create a datacenter.

NOTE: In vSphere permissions are additive. So, if you add a user to the above Create DataCenter group but they are also a member of an admin group they will get all the administrative permissions as well as any specific others. Its worth remembering this.

What’s Next?

next up we’re goingt o configure the advanced networking features of vSphere by configuring Virtual Distributed Switches and migrating our lab networking off the standatd switches.

vSphere / Lab For Beginners: Part 2 – Installing & Configuring Virtual Center

Aside 23/06/201602/05/2017 Alec Dunn (LegoYoda) Beginner, Community, Labs, VCSA, VMware, vSphere 6.5, automated, Automation, Beginner, HomeLab, how to, Install, Install GUide, VCSA, virtual center, VMware, vSphere

Where Are We and What’s Next?

At this point in our lab build we have our ESXi hosts up and connected to some storage but nothing else. We need a tool to manage all our hosts and provide accss to all the cool features that VMware and Virtualisation is known for such as moving VMs between hosts, advanced networking, HA, load balancing etc.

Within vSphere this is Virtual Center. Currently available in two formats. One being an installable that can run on a Windows Server and one being a deployable appliance that is simply pushed out to a host without any other OS requirements. For this guide we are going to be deploying the appliance version (known as the Virtual Center Server Appliance, VCSA). This is because it’s now the recomended version to use from VMware and the Windows version is probably going to be phased out sometime in the near future. The VCSA also doesnt require a Windows licence and the patching that goes with it either. and finally, for a lab environment, the requirements are a little lower so it’s a better fit.

Virtual Center Server Appliance: It’s More Than One Thing!

One thing to note before we proceed is that the VCSA is actually MORE than one component. but, for the purposes of simplicity I’m refering to the suite as one entity in this beginners guide. If your curious the VCSA is actually split in two. The vCenter Management Server (responsible for managing the environment and the ‘thing’ you actually log on to) and the Platform Services Controller [PSC] (which deals with mutiple things like sign on, certificates, licensing etc.) The PSC can be installed with the VCSA or split out to a seperate box for high load installs. In this lab we’re goingt o use the embedded PSC.

Before You Start: Sort Out DNS

vSphere in general relies heavily on name resolution to work correctly. Indeed, installing the Virtual Center Server Appliance without having DNS in place first (i.e. using the IP address) can cause issues further down the line such as the inability to change the hostname without the system falling over or other such quirks.

So, before going any further we are going to create a DNS server on your first ESXi host. In my case I have installed a Windows 2012 R2 Active Directory VM on our first ESXi host and configure a domain and DNS. I’m not going to cover how to configure Active Directory in this post but before going any further you should ensure that a domain for you lab exists (in this example ‘lab.local’) as well as forward and reverse DNS lookup zones with entries for your ESXi servers and Virtual Center Server Appliance. In my case:

Reverse Lookup Zone: Three static entries for ESXi and VCSA and the autocreated entry for the AD server.

Forward Lookup Zone Entries: For the two ESXi servers and the Domain controller.

and the entry for the VCSA about to be deployed.

If you are starting from scratch and need to create a new VM to install a Windows server / Active Directory to you can follow the steps below. Otherwise skip to the ‘Deploying the VCSA’ step.

Creating A New VM From Within ESXi

Log on to your first ESXi host via the https://<esxiHost>/ui URL as root and select the Virtual Machines entry on the left. Now Select Create / Register VM on the right.

This opens a New Virtual Machine Wizard. Selct Create New Virtual Machine. Click Next.

Enter a name for your VM and select the Compatibility, Guest OS Family and Guest OS Version. For Compatibility it is best to select the version that matches you ESXi version. It is also important to select the right Guest OS family (Windows, Linux etc.) and version as this determines the makeup of key elements of the the virtual hardware of the VM (disk controllers etc). Selecting incorrect family and /or versions can cause performance issues or, at it’s worst, a failure of the VM to turn on. Once specified, click Next.

Select your datastore where you would like to store the VM and click Next.

Here you can configure the VMs resources tot he size you require. CPU, Memory and Disk can all be set here. For compatibility reasons I would recomend leaving everything as default except for disk space and RAM. It should be noted that with most VMs, unless they are performing an explicitly parallel workload the rule is ‘1 x vCPU every time’. WHY is more advanced but, for now. leave it as a 1 CPU VM and click Next.

You’ll be given a summery of the options you specified. Click Finish and the wizard will close and the VM will be created.

Notice, back on your main screen, the recent tasks pane at the bottom of the screen will show the progress and, hopefully, success status of the VM creation. You are now able to start the VM and install an OS to it.

With all of the above in mind and DNS entries set up for you ESXi and to be installed Virtual Center Server Appliance we can deploy the VCSA into our environment and get going.

Deploying The VCSA (Automated)

In vSphere 6 the VCSA can be deployed the traditional way, clicking through wizards etc. or using a configfile and a simple command line to automate the whole process. We’re going to be using the automated method for this guide as I firmly believe that Automation is the way forward and the principals followed here carry forward in to the more advanced areas of vSphere and are worth exploring right away.

NOTE: The following is shown using a Windows PC as the client. This can also be done via a Mac. It’s just the kick off command that changes.

What You’ll Need

For this section of the guide you’ll need:

A Windows PC on the same network as the ESXi hosts previously set up.
Windows Powershell
The VCSA ISO file (I used VMware-VCSA-all-6.0.0-3634788.iso from VMware site).
The ability to mount .iso images (Native to Windows 10).

Optionally, if you want to follow the command line driven configuration of datacenters and hosts you will need.

VMware PowerCLI (installed on your Windows PC)

Step 1: Mount the VCSA ISO and Configure Settings.

Mount your VCSA ISO. In Windows this is done by Right-Clicking the VCSA .iso file and selecting Mount.

Navigate to <CD Drive>:\vcsa-cli-installer\templates\install and copy the embedded_vCSA_on_ESXi.json file to somewhere simple to access (such as c:\temp)

Open the .json file and edit in the values as you require for your environment. I’ll explain the requirements for the values after this example (shown).

NOTE: The files here are slightly different between vSphere 6.0 and 6.5. Both are shown below.

JSON Config For vCenter 6.0

{
    "__version": "1.1",
    "__comments": "Sample template to deploy a vCenter Server with an embedded Platform Services Controller to an ESXi host.",
    "target.vcsa": {
        "appliance": {
            "deployment.network": "VM Network",
            "deployment.option": "small",
            "name": "VCSA6",
            "thin.disk.mode": true
        },
        "esx": {
            "hostname": "192.168.1.10",
            "username": "root",
            "password": "aRandomPassword",
            "datastore": "Datastore1"
        },
        "network": {
            "hostname": "192.168.1.15",
            "dns.servers": [
                "192.168.1.254",
                "192.168.1.20"
            ],
            "gateway": "192.168.1.254",
            "ip": "192.168.1.15",
            "ip.family": "ipv4",
            "mode": "static",
            "prefix": "24"
        },
        "os": {
            "password": "anotherPassword",
            "ssh.enable": true
        },
        "sso": {
            "password": "evenMorePasswords",
            "domain-name": "vsphere.local",
            "site-name": "Home-Lab-SSO"
        }
    }
}

So, what are the values that need filling in? From the top:

appliance:deployment.network - This is the name of the network created in part 1 of the guide.  If you didn't change anything it's 'VM Network'.

appliance:deployment.option - This dictates the amount of CPU, DISK and RAM allocated to the VCSA based on VMware's t-Shirt sizes.  Small is good for up to 100 hosts and 1000 VMs and is perfect for a lab.  There is a Tiny option but you can hit the VM limit in a lab quite quickly.

appliance:name - The text name that you wan to call the VCSA.

appliance:thin.disk.mode - Either true or false.  vSPhere can, simplistically, allocate all disk space requested to a VM at creation or as it is used (more efficient).  I recomend true in this instance.

esx:hostname - This field is populated with the IP address / hostname of the ESXi server you want to deploy this VCSA to.  NOTE: Use IP if DNS is not set up corretly at this stage but preferably use DNS as this can stop known issues arising later if you want to rename the appliance or do anything that relies on FQDN.

esx:username - The username you want to use to connect to the specified ESXi host.  Usually root.

esx:password - The password for the account specified in the field above. Note this is stored in plain text.

esx:datastore - Then EXACT name of the datastore on the ESXi host to deploy the VCSA on. NOTE: This is case and space sensitive.

network:hostname - This is the hostname this VCSA server. NOTE: vSphere is very, very picky about DNS.  In this example I assume you have deployed a domain controller or have DNS set up WITH an entry for this VCSA server alreaddy created. e.g. labvcas.lab.local pointing to the IP address you want to give this appliance.  If DNS resolution is not ready yet an IP address MUST be used here otherwise the install will fail.  However, this will trigger known issues if you ever want to rename your apliance or change its identity. It is HIGHLY recomended to get DNS sorted at this stage.

network:DNS.servers - This setting requires a list (can be one) of DNS servers for name resolution.  I have set these to be my default gateway (for internet name resolution) and then the IP address of the AD server i intend to build in the lab.

network:gateway - This is the default gateway to the internet in IP format.

network:ip - This is the IP address of this VCSA server you're going to be deploying. 

network:ip.family - specifies wether the above address is in IPv4 or IPv6 format.  Default is IPv4.

network:mode - Choose between static or DHCP.  Static is prefered for predictability.

network:prefix - This field is the subnet mask of the network for the VCSA in slash notation. (i.e. 24 = 255.255.255.0).

os:password - This specifies the root password for the VCSA and is needed for access to the console or SSH access. NOTE: stored in plain text.
os:ssh.enable - A true or false value specifying wether you want to enable SSH access to the VCSA.  AS this is a lab I have enabled it in the example.

sso:password - This sets the default password for the administrator SSO (the in built authentication system) account.

sso:domain-name - The domain name for the SSO component install. NOTE: This cannot be the same as an existing orsoon to be existing Windows domain.  I have used vsphere.local (so the admin account is administrator@vsphere.local). 

sso:sso-name - The name of the SSO site.  NOTE: Spaces not allowed.

Once all of the values have been filled in for your envionment you are ready to deploy the VCSA and automatically configure it with the settings in the JSON file.

JSON Config for vCenter 6.5

Note that the value you will need to fill in stay the same but the filehas additional sections at the end that are required for the install to sucessfully complete.

{
 "__version": "2.3.0",
 "__comments": "Sample template to deploy a vCenter Server Appliance with an embedded Platform Services Controller on an ESXi host.",
 "new.vcsa": {
 "esxi": {
 "hostname": "esxi01.lab.local",
 "username": "root",
 "password": "Password1!",
 "deployment.network": "VM Network",
 "datastore": "Datastore1"
 },
 "appliance": {
 "thin.disk.mode": true,
 "deployment.option": "small",
 "name": "LABVCSA"
 },
 "network": {
 "ip.family": "ipv4",
 "mode": "static",
 "ip": "192.168.1.15",
 "dns.servers": [
 "192.168.1.20"
 ],
 "prefix": "23",
 "gateway": "192.168.1.254",
 "system.name": "labvcsa.lab.local"
 },
 "os": {
 "password": "Password1!",
 "ssh.enable": true
 },
 "sso": {
 "password": "Password1!",
 "domain-name": "vsphere.local",
 "site-name": "HomeLabSSO"
 }
 },
 "ceip": {
 "description": {
 "__comments": [
 "++++VMware Customer Experience Improvement Program (CEIP)++++",
 "VMware's Customer Experience Improvement Program (CEIP) ",
 "provides VMware with information that enables VMware to ",
 "improve its products and services, to fix problems, ",
 "and to advise you on how best to deploy and use our ",
 "products. As part of CEIP, VMware collects technical ",
 "information about your organization's use of VMware ",
 "products and services on a regular basis in association ",
 "with your organization's VMware license key(s). This ",
 "information does not personally identify any individual. ",
 "",
 "Additional information regarding the data collected ",
 "through CEIP and the purposes for which it is used by ",
 "VMware is set forth in the Trust & Assurance Center at ",
 "http://www.vmware.com/trustvmware/ceip.html . If you ",
 "prefer not to participate in VMware's CEIP for this ",
 "product, you should disable CEIP by setting ",
 "'ceip.enabled': false. You may join or leave VMware's ",
 "CEIP for this product at any time. Please confirm your ",
 "acknowledgement by passing in the parameter ",
 "--acknowledge-ceip in the command line.",
 "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"
 ]
 },
 "settings": {
 "ceip.enabled": true
 }
 }
}

Step 2: Deploy the VCSA

Open a PowerShell window and run the vcsa-deploy.exe from the VCSA ISO with the path to the JSON file appended to the end (as shown).

For vCenter 6.0

<DRIVE>:\vcsa-cli-installer\win32\vcsa-deploy.exe c:\temp\<json-file> --accept-eula

For vCenter 6.5

<Drive>:\vcsa-cli-installer\win32\vcsa-deploy.exe install C:\temp\<json-file> --accept-eula --acknowledge-ceip

There will be a prompt asking you to accept the SSL certificate of the ESXi host you’re deploying to. Type yes and press Enter.

The isntaller will now deploy the VCSA image, boot the VM and configure based on your settings. NOTE: Depending on your storage this can take a VERY long time to deploy and an equally long time to configure and boot for the first time (up to 30 mins).

Example output (note the DNS error near the top NOT killing the process)

Once the deployment is complete you should be able to open a browser window to the VCSA and log in using the administrator@vsphere.local account.

https://<IP-Address-VCSA>/vsphere-client/

Ignore the security certificate warning and add it to your exceptions list.

Enter your logon credentials as specified in the JSON file earlier. Press Logon.

You have now deployed and logged on to the VCSA. The main screen (below, known as the vsphere Web Client) should now be visible. Next up we need to add the ESXi hosts to the VCSA so it can manage and configure them.

Step 3: Create a Datacenter, Cluster and Add ESXi Hosts to VCSA

Going forward I will be showing the processes to set up the basics of vCenter via the GUI as, at this point, it gives a better understanding on how things fit together. You sgould know that all these steps are possible via the command line (PowerCLI) which is quicker but requires you to know what you want to do.

Now that you are in the VCSA webclient we can start to configure it to manage our environment. All vSphere administration and configuration is done via the VCSA. Indeed, once a host is added to the VCSA it will warn you that nothing should be changed if you log on locally to a host.

First order of bnusiness is to create a new Datacenter. This is a top level logical container for clusters of ESXi hosts.

Right click on the VCSA in the left hand pane and select New Datacenter from the contexrt menu.

Enter a friendly name for this Datacenter and Press Ok.

You’ll now see that the created Datacenter object appears in the left hand pane of the vSphere web client. Again, right-click and select New Cluster from the context menu.

This brings up a nicly detailed set of options that can be turned on for a cluster. Give the cluster a sensible name and make sure you turn on DRS and HA. EVC is optional but nice.

DRS (Dynamic Resource Scheduling) is VMware’s technology for load balancing VMs across all the hosts in the cluster. It can mopve VMs between hosts to allow better usage of available resources. It’s an awesome feature and should definitly be turned on. You can leave the defaults for it’s actual configuration and feel safe it wont break anything.

HA (High Availability) monitors VMs to see if they are responsive. If a host goes down (for example) and HA is turned on the VMs on the downed host will be powered up on the remaining hosts in a crash consistent state. Not essential for a LAB environment but worth playing with none the less.

EVC (Enhanced vMotion Compatibility) is a nice little feature that allows the movement of VMs across hosts that have CPUs from different generations with different capabilities. It does this by limiting the CPU feature set used to the lowest common denominator in teh cluster. Especially handy in Labs if you’re building them up over a period of months an years and might have different hardware.

After Pressing OK you should now have the Datacenter and Cluster Object visible in Virtual Center.

Now we need to add a host to the cluster. Right click on the Cluster and select Add Host. This will bring up a wizard to add in a host. Type the IP (if no DNS is set up) or the Hostname (if DNS is set up) of the first host you want to add and select Next.

NOTE: As always I reomend using the hostname to add your host in as vSphere is sensitive to DNS working correctly for advance functions and adding by hostname implicitly verifies that everything is working correctly

Type the username (root) and the password for this account and click Next.

You may get the standard certificate warning when connecting to a host for the first time. Click Yes.

A Summary page is displayed. Click Next.

You now should assign a licence. As this is a lab we’re going to use the trial period evaluation mode licence. Select it and click Next.

You now have to chose wether to enable Lockdown mode. Lockdown mode, as it says, prevents users from logging directly in to the host. i.e. all access has to be via vCenter. As this is a lab and we’re going to want to play around, keep this disabled. Click Next.

Continue now through the wizard to the end accepting the defaults. This will put any VMs on the host (just vCSA really) in to the clusters default resource pool (this is fine). When your done, repeat for the other hosts you have installed ESXi on. You’ll end up with something like this.

Step 4 – Removing those Errors and Warnings

You’ll probably notice that now the cluster is set up there may be some warnings displayed. Most probably it’s the ones shown below (if you dont have some or all of these, no matter, skip that part). At this point it’s usually relating to:

SSH Enabled: We deliberatly did this so no worries there.
No CoreDump Target: We need to fix this.
Syslogs on Non persistent storage: We need to fix this also.

Fixing the “Syslogs on non persistent storage” is possible in one step. Select the first host in the cluster and click:
For vSphere 6.5: Configure > System >Advanced System Settings.
For vSphere 6.0: Manage tab. Then select the Settings sub-tab and Advanced System Settings from the left hand list.

Scroll down and select the setting labelled Syslog.global.logDir

Right click this setting and select Edit Option

Change the value to match something like that shown below. I’ve redirected the logs to Datastore1. NOTE: when editing this value the “[ ]” MUST be kept and the name inside them is case and space sensitive. It must match EXACTLY the name of the Datastore. Click Save. Repeat for the other hosts in the cluster. I like to target each host to a different Datastore. If you only have the one Datastore target the logs to a seperate folder to avoid confusion.

Now reboot the vCenter appliance and the error relating to the logging should dissappear.

Fixing the CoreDump Error via Command Line

IConfiguring the Coredump location is done via the ESXi command line. You’ll need to log on to the ESXi Shell via SSH (use PuTTY (Windows) or iTerm (Mac)) and run the following commands to check, look and set the coredump partition. SSH should be enabled already on your ESXi hosts sa we ensured not to turn it off in setup.

So, if ESXi is complaining that no coredump partition is set you should be able to run the following command and verify this is the case.

esxcli system coredump partition get

This wil show something similar to that shown below (showing that a partition is configured but not active in this case). NOTE: it may also show a blank entry for both, this is fine.

If the configured partition is not the device you wanted or is blank you can run the following commands to show the available partitions and then set the system to use the desired one.

esxcli system coredump partition list

this will show a list of the available partitions the system can use. make a note of the “mpx.vmhbaxx.Cx:Tz:Lx” part of the partition you’ll want to use as it is required in the next step.

We can relate this string back to something more physical by checking the storage adapters section on the host in vCenter. In this case you can see that vmhba33 maps to the USB Storage Controller (i.e. the USB stick ESXi is instalaled on).

If you need to set a new partition as the target (i.e. Configured was blank). You can now run the command:

esxcli system coredump partition set --partition="mpx.vmhbaxx.Cx.Tz.Ly"
esxcli system coredump partition set -enable true

This will configure the coredump to the partition of your choice. You’ll need to reboot ESXi to make the change active.

If the correct partition was configured, but not active, simply set it to active by entering the command below and rebooting ESXi:

esxcli system coredump partition set -enable true

After the reboot you can check everything is correct by running:

esxcli system coredump partition get

Now you can see that the active partition is the same as the configured one and everything is ready to carry on.

Fixing the SSH Is Enabled Error

The final warning we see was about the ESXi Secure Shell (SSH) being active. As mentioned before we probably want this running in a lab but, if you want to know how to remove it, the steps to disable this are shown below.

Simply select the host with the warning in the left pane of the vCenter webclient and then select the Manage tab. Now select the Security Profile item in the left bar (you’ll need to scroll down), select services area and click edit button. Select SSH and Stop the service.

Next Steps

Thats the end of the deployment and basic setup of vCenter and ESXI. You should now have a working ESXi cluster and vCenter and be able to deploy simple VMs all on a single network and get going. Next up we will cover the configuration of more advanced networking and authentication within vCenter (using a distributed switch over multiple standard switches, joining the lab to a domain) and how to set up vMotion and other cool features of vSphere.

vSphere / Lab For Beginners: Part 1 – Installing ESXI To USB

Aside 14/06/201602/05/2017 Alec Dunn (LegoYoda) Beginner, Community, Labs, VMware, vSphere 6.0, 6.5, Beginner, Community, esxi, home lab, HomeLab, how to, Install, Install GUide, iscsi, lab, VMware, vSphere

This post is all about how to install the first part of any vSphere / HomeLab setup. the basic ESXi client. It’s intended for beginners who haven’t used vSphere before or those who know a little but are installing on their own for the first time.

Assumptions

This guide assumes that you’re installing on to a physical piece of hardware that will boot from a USB key. Although the process is pretty much the same for SD cards, local storage etc). It also assumes that you’re installing from an ISO image and no optical drive.

All software used in this guide can be obtained with a free trial licence so you get going quickly and have a limited playa round.

For advice on choosing hardware suitable for a lab or test environment check out the Open Home Lab project (community run) or ‘Part 0’ of this series for information on the kit this lab weas built on.

Note: This guide was based off vSphere 6.0 however. This processw is the same for vSphere 6.5 based installs of ESXi. Differences are called out and noted.

What You’ll Need

For this part of the guide you’ll need:

Aa blank USB key (8GB or more, 16GB recomended [for logs])
An installed copy of VMware Workstation (Windows) or Fusion (Mac)
An ESXi Install.iso image
Some shared storage (iSCSI via a NAS shown in guide).
- any NFS share would also be viable but not shown here.
2 x ‘computers’ to act as hosts for ESXI and run our workloads
- These will run ESXi from USB.

Trial versions of the software can be downloaded form VMware’s website.

What Are We Going To Do?

The aim here is to install ESXi 6.0 (the beating heart of vSphere) on to a USB stick and then get our hosts to boot ESXi from that. We’re then going to set the hosts up so they can communicate and have access to some shared storage. Then they will be ready to run VMs.

Step 1: Create a Blank VM In Workstation

Open up VMware Workstation and create a new VM from File > New Virtual Machine. This bring up a handy Wizard.

Workstation provides an option to attach an ISO to a new VM and boot straight to it when it’s created. This is perfect for Installing ESXi as, with a few clicks, we’ll have the installer booted and ready to go without any faff!.

Select Installer disc image (.iso): as the option and then browse to the ESXi .iso file you have downloaded from VMware. It’ll probably have an unfriendly name. e.g. VMware-VMvisor-Installer-6.0.0.update02-3620759.x86_64.iso. Click Next.

Now name the VM something friendly (its not being kept so dont worry too much). and, if you can, make the location somewhere fast and local to speed up install times. Click Next.

This VM isn’t going to do much apart from boot an ISO image (we’re installing to USB remember) so make the disk size 2GB and click Next.

Make sure you tick the Power on this VM after createion option and click Finish.

The VM used to boot the ESXi installer will now be created, turn itself on, and then load the installer program. Probably less than 30 seconds!.

Step 2: Install ESXi to USB Stick

When you open a console to you’re VM you should probablu see something like this. Notice there is a countdown timer so, if you’ve been a biy slow, the default option will already have been selected for you…

Once you’ve selected you want to install ESXi you’ll be presented with a chance to back out. Don’t! Go forth and install (Enter).

Before you go any further you’ll want to ensure that you’ve plugged in your USB key that you with to install ESXi on to and connected it to the VM via VM > Removable Devices > [Your USB Drvice] > Connect.

Accept the EULA, you know there’s nothing important contained in it right? (Press F11).

Now you have to start paying attention. Use the cursor keys to select the USB key from the list If it’s not shown check that you’ve connected the key to the host via the VM menu. Press Enter.

The installer will now scan the disk to see if it’s blank or already has something on it. Wait a few moments.

In My case I already had ESXi installed on this USB stick so I got the warning shown below (sorry about that). I chose Install as I wanted to show this as if it were a blank drive going forward.

You should now select a keyboard layout. Ensure you get this right as it’s a total pain if you set a password down the line and then change the keyboard layout. Press Enter.

Now enter a password for the root account. This should be secure as it give total access to ESXi. Press Enter.

ESXi will now do some checks to work out what it needs to configure during the install. Just wait a moment.

Now is your final choice to back out. Check it’s going to install to the correct device (you memorised the HBA number from earlier right?). Press F11 to begin the install.

The isntall will begin and progress will be shown. It only takes about 10 mins to a normal (slow) USB stick.

At the end of the process you’ll be greeted with a success screen as shown below. Remove your USB key and turn off the VM in workstation. You don’t need to press Enter to reboot as we’re done with the VM now. We just care about the contents of the USB stick.

Step 3: Booting ESXi and Initial Configuration

NOTE: Going forward I’m using a host with no monitor attached. Instead I have an Intel vPro CPU installed allowing me to use Intem AMT KVM to view the servers boot process. If you’re intalling to a regular computer ensure you can see the servers output and have a working keyboard to hand before continuing.

NOTE: Most systems are not set to boot from USB by default. You should chnage the boot priotory in your systems BIOS / UEFI at this point.

Insert the USB key in to your server / computer / host / PC and power it on. ESXi will load (take about 10 mins) and then will present you with a screen as shown below.

The first thing you must do after installing ESXI is get the basic management network configured. This is the initial IP and NIC assignment that ESXi uses to send all traffic between hosts, VMs and your system. By default it’s set to DHCP and you dont want your IP address changing all the time!

Press F2 to bring up the logon prompt. Enter root as the username and the password you set in step 2. Press Enter. If your log on was ucessful nothing wil appear to happen (yes really). Press F2 again.

The system customisation screen will now be displayed. This is the area that, in the event of a massive SNAFU in configuration you will always come back to in order to fix things (generally networking).

At this stage we are interested in Configuring the Management Network. So, select this opeion and press Enter.

This shows the Configure Management Network screen. We’ll need to configure all of these options but, to start, select Network Adapters. Press Enter.

This is where you can select the NIC that you want to use for the basic management network. You can select more than one for failover if required but advanced configiuration is far easier from within Virtual Center (covered later).

In this example there are three NICs in my host (onboard lan and an intel Dual port PT adapter [the onces labelled “J6B2….”). Select the most appropriate one for your system. Press Enter to return to the Configure Management Network screen.

Now select IPv4 Configuration. Press Enter. This brings up the network settings screen for the NIC assigned to the management network (previous step). As noted when we booted the host this will be set to DHCP as default. It is recomended to change this to static and then configure the network settings based on your environment.

The example below shows my setup. Press Enter. You will rturn to the Configure Management Network screen.

Select IPv6 Configuration and disable IPv6 (restart required). I’m doing this to simplify things later on and remote and long format IPv6 addresses from troubleshooting steps. If you want to use IPv6 there is no reason why you can’t leave it on. Press Enter. You will return to the the Configure Management Network screen.

Select DNS Configuration and enter information relevent for your network. In the example below the primary and secondary DNS entries are my Acrive Directory servers. It’s crucial that the primary DNS server actually EXISTS at this point. So, in your environment this may be your internet router. You should also set the Hostname at this point. Press Enter. You will return to the Configure Management Network screen.

Select Custom DNS Suffixes and enter the suffix you are creating for your lab. This doesn’t have to exist at the moment but if you’re planning on building a domain on the lab enter here what you’re calling the domain. In my case lab.local. Press Enter. You will return to the Configure Management Network screen.

Now we have finished configuring the Management Network. Press Escape and the following confirmation should appear. Press Y to reboot the ESXi host.

NOTE: If you chose to leave IPv6 ENABLED you will simple be asked to Restart the Management Network. Again, press Y and wait a second.

The host will now restart (a process that takes about 10 mins

Once the host has rebooted you wil have to log in again to be presented witht he main options screen. We’re going to skip over some of the options here as they relate to tests or service restarts. Select Troubleshooting Options. Press Enter.

This display the Troubleshoting Mode Options screen. Select Enable SSH and Press Enter. this allows us to connect to the ESXi host using PuTTY or similar (iTerm on Mac). This is handy in a lab as it enables cut-paste of commands.

NOTE: This is only being enabled here as we’re building a lab and it’s useful. This should obviously not be enabled in a production environment unless there is actuall a problem.

Press Esc to return to the main menu and log out.

This is the basic configuration of ESXi done. It will now be reachable via https://<IP Address>. From here you can download the vSphere client for Windows to gain access and install Virtual center. However, this is useless if you’re on a Mac and the Windows client is going to be replaced soon. There is a better way….

Step 3: Install the ESX UI Utility

That better way is the ESXi Embedded Host Client. This is an HTML 5 based management component that isntalls directly on to the host and allows management and configuration of the ESXi hosts from any modern web browser.

NOTE: As of vSphere 6.0U2 this is included as part of the main install and the following step is not technically required. However, I would always install the latest version and I even came across a bundles version that would not allow me to configure iSCSI until I had upgraded.

Download it here: VMware Embedded Host Client

Essentially, this is a plug-in for ESXi. These are known as “VIBs” (vSphere Installation Bundle). Once You’ve downloaded the file and extracted it we need to install it. The easiest way to do this is to copy the VIB over to the ESXi host using WinSCP. Place it in simple to get to location (such as /tmp/).

Now, as we enabled SSH in the previous step we can open a PuTTY session to the esxi host and install the UI utility.

I ran the command esxcli ssoftware vib install -v /tmp/esxui-signed-3843236.vib

Output from that command should look something like the screenshot below.

Once finished you can enter the url https://<IP of ESXi>/ui/ and you’ll get the lovley new html5 interface. VMware have intimated that this is the way everything is going in the next version of vSphere but, for the moment, this remains an unsupported method of connection. IMO it works and is FAR better than the old method.

You’ll want to log in at this point. Use the username root and the password you set up earlier. Click Login.

Welcome to ESXi!

Step 4: Configure Time Synchronisation

ESXi and the rest of the vSphere infrastructure relies heavily on time synchronisation for proper and reliable operation. Becasue of this it should be configured now before anything else is configured. This needs to done per installed host.

Click Manage in the left pane under the host and select the system tab and select Time & Date option. Select Edit Settings.

Select the Use Network Time Protocol option. Change the NTP service startup policy and NTP servers to as shown below and click Save.

Back in the main area select the Actions button and expand NTP service option. Select start.

NTP will now start and time will be configured on the ESXi server. Repeat for all installed ESXi server you have.

Step 5: Configure Storage

Once we’re at this point we have a functioning ESXi system with networking but we are still missing one crucial piece of the puzzle. Storage!

Note: vSphere shines and is most useful with shared storage (it’s a requirement for anything vaguley real world) but there is nothing to stop you playing around with one host and locak storage. You just wont be able to do much.

For the lab to be useful we’ll have to configure some shared storage. You can use a SAN, NFS shares or iSCSI without issue. For this lab I’m going to be demonstrating iSCSI running from a Synology NAS (DS1513+). However, if you dont have iSCSI capability use NFS from whatever share you feel like. I’ll write an NFS section later. I’m not going to go over how to set up your storage as that is generally device specific. We are going to start from within the ESXi Host UI and configure from there.

Example Setup Details

Going forward my example setup consists of 4 iSCSI targets each representing a datastore. These are called Datastore1, Datastore2, Datastore3 and ISO Store. These reside on A synology NAS presenting iSCSI over 192.168.2.200 (note the different subnet to the management network). This is to ensure segregation of storage traffic from data traffic. It also allows me to monitor my system more easily.

iSCSI Configuration Process

Log on to the ESXi UI via the URL https://<IP Address of ESXi>/ui/ log in as root user with the password you set earlier. On the left pane, select storage.

In the right hand pane select the Adapters tab and notice that there is only one adapter listed. This is the USB adapter (if you have a host with a physical HBA this will probably be listed here at this stage, I don’t). Click the Configure iSCSI item.

This brings up the screen to configure a new Adapter for iSCSI. For now Enable iSCSI and click the Save Configuration button.

Notice that this now adds another adapter in the list.

iSCSI requires a network connection over a vmkernel port to function correctly and, as mentioned at the start, I am running iSCSI on a seperate subnet. This requires a little network configuration before we start. Fronm the left pane, select Networking.

Select the Virtual Switches tab and then click the Add Virtual Standard Switch item.

Call it something relevent (such as Storage) and select an uplink (NIC). I’ve chosen the 2nd NIC in my system. leave everything else as standard. Click Add.

Switch to the Port Groups tab select the new vSwitch and click the Add Port Group item.

Call this Storage and assign it to the Storage virtual switch. Click Add. This essentially, binds the uplink to the portgroup to the switch to create a dedicated path way for storage traffic.

Finally, we need to create a VMkernel NIC. VMware uses these to pass certain types of traffic within the system. There is already one created for management by default (called vmk0) but we need to create one for storage traffic.Select the VMkernel NIC’s tab and select the Add VMkernel NIC item.

Select the Storage Port Group and change the IPv4 Settings to Static. You’ll need to click the little arrow to actually show the fields to enter the address. Now add in the networking information for the port. You will need an IP address on the same subnet as the iSCSI storage as well as the subnet information and gateway. You do not need to specify the type of traffic for the kernel port when configuring for storage. Click Create.

Now head back to the storage information by selecting Storage from the left pane. Select the Adapters tab and select the Configure iSCSI item to bring back up the configuration screen.

Click the Add Port Binding item in the Network Port Bindings section and select the storage (vmk1) interface we just created.

Now select the Add Dynamic Targets from the Dynamic targets section. Add in the IP address of the iSCSI server.and click Save Configuration. In my case this is the IP address of the network port on my NAS which handels iSCSI traffic. The port is default at 3260 inless you’ve configured your iSCSI server with something different.

Click Save Configuration. VMware should rescan all your adapters and, if configured correctly. you should see your iSCSI LUNS listed in the Devices tab.

Finally, select the datastores tab and click refresh. This should refresh the screen and show that there are now datastores available to the ESXi Host.

Wrap Up

That’s it. You now have an ESXi host ready to be used for creating VMs and your lab. At this point I would recomend repeating the steps above for all the other physical hosts you have. Then you are in the position where you can install Virtual Center and really start to use the softwares power. I’ve got a sectionon how to isntall the VCSA in Part 2 of this beginners guide.

On The Subject of HomeLabs

Aside 24/05/2016 Alec Dunn (LegoYoda) Community, Labs, VMware Community, HomeLab, vmug, VMware

So, Were you thinking about building a home based VMware lab? Are you unsure about the best way to go about this? Do you need information on upgrades or the way forward? Or perhaps you’e got a killer lab already and want to share your knowledge with the world.

You should probably head on over to The Open Home Lab project. A wonderful new site set up by the VMware community (masterminded by Alex Galbraith of Tekhead.it) to help people starting out and to share knowledge around the subject of labs and checking out cool stuff.

Go Check it out at:The Open Home Lab Project

Installing Minimal vRA 7: Part 4 – Running Initial Content Creation Item

Aside 07/02/201609/06/2016 Alec Dunn (LegoYoda) vCAC, VMware, vRA, vRA7, vRealize Cloud, Install, Install GUide, troubleshooting, vCAC, VMware, vRA

ow that the IaaS server is installed and vRA is up and running you can go and do STUFF with it! But what if you don’t really know what ‘stuff’ is supposed to look like? Well, at the end of part 3b of this series we pressed the button marked Create Initial Content. This creates a nice catalogue item you can click on in vRA.

So, what we’re going to do in this stage is log in to vRA as the user configurationadmin (created by the install wizard in part 3b), run the initial content creation catalog item and then watch how this creates some ready made blueprints based on your vSphere environment for you to use and modify.

I should point out here that there are two types of catalog item in vRA. Either a published Blueprint (allowing the creation of a VM) or an Advanced Services item which is a way of instantiating vRO workflows with parameters from vRA (and yes, that is as powerful as you would think).

Before Step 0: Before You Start

You should ensure that you have at least one (preferably 2 or more)VMware machine templates ready and waiting in vCenter as this step will use them to create vRA Blueprints. If there’s no templates, the process will run but do nothing interesting!

Step 1: Log on to vRA

To start, we need to log on to the default vRA tenant as the specially created user configurationadmin. This was created at the end of the installer wizard.

Open a browser and navigate to https://<vraappliance>.<domain>.<whatever>/vcac

You’ll see the logon page. Log in as configurationadmin with the password you specified in the installer wizard.

After a few moments the vRA default tenant portal should appear. If you click on the Catalog tab at the top to see the current Service Catalog. You should see the vSphere Initial Setup item ready to be requested.

click on the Sphere Initial Setup item.

Once you click, a multi stage form will appear asking many questions. This is part of the power of vRA you can create single click items or complex workflows that appear simple to the end user.

The first window is all abut Tenant Settings. Tenants in vRA are like organisations. Logically distinct entities that have their own Service Catalog with their own set of actions and Blueprints published for them. Generally they are aligned to a specific vCenter or compute resource. The form give you these options:

Do you want to use current tenant (y/n): This is simply asking if you want the blueprints to be created in the default tenant. You could do this but in this exampleI want to create a tenant as if it were a real life business unit/organisation. Select No.

Do you want to create a new tenant (y/n): If you click yes (we we will) the process will create a new tenant for you.

System tenant administrator password: This is the admin password for the default tenant (i.e. the one we’re logged in to) that you created in the installation wizard. Type this here. NOTE: this is NOT the ‘configurationadmin‘ users password.

Tenant name: What would you like to call the tenant? Enter this here. NOTE: make it easy to type and simple. vRA tenants are accessed by appending the tenant name to a url e.g. https://vra7.lab.local/vcac/org/<tenant name>

First Name: Type in your (or a friendly) first name.

Last Name: Type in your (or a friendly) last name.

Email address: Type in an email address for approval and status mails to be sent to. NOTE: this doesn’t have to be right but you’ll have to manually remember to check for pending approvals if you don’t use a real address (I don’t in the lab).

Username: Type a sensible username. This will be created and then used by you to log on to this new tenant.

Password: Type a sensible password for the above username.

Click next and continue with the process.

Now we’re at the vSphere setting section. The screen below doesn’t show it but you need to add this information in manually (my first screenshot was messed, this is a summary shot with the correct information). You’ll need to enter:

Endpoint name: This is the name you gave to the Proxy Agent back in step 3b. This MUST match EXACTLY what you typed before or it wont work. Fi you check back (or remember) this is the part where I said you should name the agent and the endpoint the same thing. NOTE: This is case sensitive.

Endpoint host: Enter here the FQDN of your vCenter.

Endpoint compute resource: The name of the resource you wnat to coneect to. e.g. the cluster name of your lab. In my case, ‘HomeLab’.

Username: The username of the account hat has admin rights on the vCenter server you used in the previous step.

Password: The password for the above.

Now you’re ready to run the action. So click next / ok to continue.

You’ll now get a standard vRA “Request Submitted Successfully” message as shown below. This means the action is being processed and you should be able to track it progress.

For me, the initial part of this took a good 10-15 mins. You can check on the status of a request by selecting the Requests tab. This lists all vRA requests chronologically in the order requested. It’s a good idea to check here now as, although the process can take a while to complete, if you’ve typed a setting incorrectly it will fail FAST and the status of your request will change to Failed.

NOTE: This screen does not auto update. You have to click the refresh icon at the bottom.

After about 10 mins, refresh and check that the request is still in progress. If it is, check for notifications in your inbox. This is done by clicking the Inbox tab or going back to the home screen as there is an inbox widget on that to.

You should see an item asking for approval. Open it, read it and approve it. The next bit is very fast and, by the time you’ve clicked on the requests page again, should now be complete

Now you’ll want to see what the process has created so log out of the default tenant and in to the one you had created using the above process with the system admin password you specified. In our case that means navigating to: https://vra7.lab.local/vcac/org/pepsicac7

Now click on the Catalog tab and you should see a shiny set of blueprints, one for each template you have available in your vCenter.

Now it’s time to play around. Try to provision a few VMs via the blueprints and see if you can edit the settings.

NOTE: when I initially tried out my blueprints they all failed with an error message “cannot find the template xxxx” simply editing, changing nothing and then saving the blueprint caused everything to work. Seems vRA7 still isn’t without it’s oddities.

Next up in part 5 of this series I’ll do a quick tour of the interface and manual configurations screens for vRA. However, the install is essentially complete now so go forth an play around.

I’ll be adding in a how to series also in the near future for common operations.

Installing Minimal vRA 7: Part 3b Iaas Install and Automatically Installing Pre-Requisits

Aside 27/01/201607/11/2016 Alec Dunn (LegoYoda) Automation, vCAC, VMware, vRA, vRA7, vRealize Cloud, Install GUide, Minimal Deployment, vCAC, VMware, vRA

Stage 0: I Should Have Clicked the Button

This post, right here, is one of the reasons why vRA 7 is leagues ahead of vRA /vCAC 6.x. In vRA 6 you had to manually ensure that each of the many, MANY pre-requisites for installing the IaaS server on a Windows machine were exactly right before trying. If even the slightest detail was incorrect you had to start over again (and I mean from the vRA appliance forward. It broke everything). vRA 7 has a nice pre-req checker that tells you if your out of compliance with any of the requirements and wont let you continue until you’re done. Crucially, it has a button labelled “Fix” that I didn’t know about that will sort EVERYTHING for you automatically. I didn’t know about this the first time so spend a good few hours manually sorting all the pre reqs before starting. This was a waste of time…

So, if you want to get going quickly and easily keep reading. If you wan to see what is required first hand in getting a server ready for an IaaS install (and it is interesting to see how it all fits together) I would like to direct you to the alternative version of this bog “Part 3 a”<<<COMING SOON>>>

Ready?

Stage 1: Getting Your Server Ready

NOTE: I’m assuming that you have provisioned a vanilla Windows 2012 R2 server ready to be used as the IaaS server. It must be:

Part of the same domain as the vRA appliance
Be registered in DNS
Have no ports blocked between it and the vRA VA (personally I just turn the FW off in the lab).
Meet the minimum system requirements of 2 x vCPU, 8GB RAM, 30GB HDD space (in addition to Windows)
- For a lab environment you CAN drop the RAM after install but not before completion.

Stage 2: Install IaaS Management Agent

Before starting the main install of the IaaS server you need to install the IaaS Management Agent on the IaaS server (It looks for it in the initial setup). You can get this by navigating to the URL https://<VRA Appliance FQDN>:5480/installer on the iaas server.

This brings up a page with various packages available for download from the vRA7 appliance server. We’re interested in the top one at this time. Click the link to download the Management Agent Installer.

Save this file somewhere easy on your IaaS server and then run the installer to start the wizard. Continue through until you reach the Management Site Service window.

Install to an appropriate location and continue…

At this stage you’ll be asked to fill out a few important fields. The main thing to note here is that if you get the vRA appliance address incorrect (or the UN/pwd) you will be unable to load the SHA1 fingerprint and continue.

You also have to tick the box confirming that you know the fingerprint is correct. I’m not checking this in this guide but you should do in a production environment (steps on how to do this will be in the “enterprise” deployment blog).

Once you’ve got the URL, Username and Password correct you’ll be able to load the fingerprint and continue.

Next you’ll be asked to ender the active directory account created earlier that will be used to run the Management Agent Service. This must have local admin rights as well as Logon as a service and logon as batch job rights.

NOTE: If you need to enable the logon as a service right for the account but dont know how to Follow this link to the Microsoft TechNet article describing how to achieve this.

Entering the Service account information

Stage 4: Starting the IaaS Install Automation Wizard

Now we’re finally ready to start the main IaaS install and configuration using the new Wizard process. To start, navigate to the following URL in a browser from the IaaS server:

https://<appliance>:5480

This will bring you to a logon screen where you need to log on as root with the password specified in Part 1 of this blog series.

Once you successfully logon for the first time the Wizard should automatically start.

IMPORTANT: The Wizard will only start ONCE. if you get part way through the process and quit you will not be able to initiate setup via this method again. If this happen you’ll have to use the old fashioned method of install and configuration.

After the EULA you get to select your instillation type. For this exercise we are installing vRA 7 in the Minimal Deployment type so ensure this is selected. You also get the option to deselect the Infrastructure as a Service option to not install the IaaS server portion of vRA (and thus rely on Advanced services and Orchestrator). We want to be able to use the ‘easy’ Blueprints in the test environment so we’re going to install it (i.e. ensure it’s checked as an option).

Now there is the first of two prerequisite check screens. This is checking for the pre-reqs for the install to begin. the screen below shows you how the screen looks if you have NOT deployed the IaaS Management agent on this server already (or if it’s not contactable).

You’ll be unable to proceed unless the agent shows up and can contact the vRA 7 appliance. As we have already installed and configured the agent you should see something like this…

Note: In the above screenshot time sync was out as my windows box wasn’t using the same time sync as the ESXi host. The install fixes this which is why the NTP configuration option is important. It must be set to the same as the source for the appliance.

Next up is the important bit. The prerequisite checker screen. vRA 7 IaaS is still very specific in what you need to be able to successfully install the componant on the Windows server. There’s a LONG list of things that have to be ‘just so’ listed in the manual. If you want to know how everything hangs together and what needs to be changed check out “Part 3a” of my guide where i do everything manual because I thought I had to. If not… Click the Run button and the wizard will go off and start checking the system for you.

Once you’ve click to start the process the screen will show the status. First off you’ll see something like that shown below. The name of the IaaS server is displayed and a “waiting….” style message appears. On my lab this took 3-5 mins.

Soon after you’ll probably be greeted with something like this telling you that your server isn’t configured right…

Now, in vCAC / vRA 6.x this would mean checking every setting it said was wrong (or guessing) or reinstalling if everything looked ok (but wasn’t). In vRA 7, however, VMware have made this bit far, far better that before.

You can simply click the “Fix” button on the pre-req checker screen and the wizard will go off and fix pretty much everything for you (A restart will be required). It looks like this:

I tried this twice and it worked perfectly both times. Your mileage may vary but i gave it a vanilla Windows 2012 R2 server and it behaved brilliantly. Anyone coming from vCAC / vRA 6.x will understand how big of a deal this is!

If y0ur server requires a reboot let it come back up and re navigate to: https://<vr_server>:5480 and log back in as root. The Wizard will (should) restart where it left off. You should find that the wizard restarts at the pre-req checker stage. Re run, ensure things are ok and continue on…

Once you’re done you can continue on to the vRealize Automation Host specification page. you can enter the host manually if you want or, as I prefer, click the Resolve Automatically option and the wizard should resolve the FQDN itself. NOTE: The screenshot below has the Enter Host option selected the one we’re talking about appears beloe.

I actually think this is a good test that everything is working correctly before going any further as the management service SHOULD be able to see the appliance at this point. If you can’t then you might want to fix that first! (Remember NOT to cancel the wizard).

It will look something like this if it’s working:

Once the appliance information has been entered it’s on to specifying the administrator password for the default tenant account. The default tenant account is the part of vRA when you can log in and configure everything important vRA related INCLUDING creating other tenants and setting up permissions for others to use them.

This is the only tenant that can do this so be sure not to lose this password or set it to something completely esoteric for no reason.

We now need to specify the configuration parameters for the IaaS server (the one you’re on).

The IaaS web address should be the same as the DNS entry you’ve set up (i.e. the servers FQDN if you get windows do it when you joined the domain).

The Install IaaS Components on drop down should only have one entry (this server).

The Username field should be set to the domain account you set up right at the beginning that has local admin rights on this server. The password is, obviously, the one you set.

Security Passphrase is very important. Communication to the SQL database will require the use of an encryption key (that you’re setting here). This must be remembered at al costs. Recovery in the event of a failure without this phrase is not possible. I personally like to go with something long but memorable such as “thephantommenacewascompletegarbageandyouknowit” just ensure you remember it!

Next is the SQL server configuration. You don’t have to have pre created a database as the wizard will do this for you. In the lab we’re using default settings and Windows Authentication. Just ensure that the account you’re logged on as / Running the Management agent as is also a dbcreator / sysadmin on your SQL server before continuing.

Next up is the Distributed Execution Managers setup. DEMs are actually two separate processed. The DEM-Orchestrator that takes care of scheduling asks within vRA and the DEM-Worker which handles the actual execution of vRA tasks (up to 15 per DEM-W).

These are installed to an IaaS server (in our case THIS IaaS server) they need a name and a description (I’ve not been very creative in the example below). These processes run as Windows services so the username and password must be from an account that has Logon As A Service Rights in the IaaS system. This is the account we set up earlier.

On to the next step… Agents. This is where you enter the infomration used to set up the communication between the vRA install and you vCenter & vSphere endpoints. vRA will then install and agent that allows communication between the two systems. Remember, vCenter doesn’t know about vRA, it’s vRA that gathers information on vCenter and then send requests. The agent is the go-between / proxy for this two way communication.

IMPORTANT: The Endpoint name and Agent Name fields should be descriptive and the SAME. This is because the explicit name of these two inputs are used in the configuration of vRA down the line and it’s something you have to manually type in and GET RIGHT. Specifically, there’s no way I know of getting the correct Endpoint name if you can’t remember it or didn’t call it the same as the Agent (which shows up in Windows services). So, if you forget and want to configure an endpoint manually for an agent you can’t remember the name of you’re left with a free form text box and not a hope in heck! This is one of the parts of vCAC that seems to have carried over…. It needs to go!

So, enter sensible information and the details of the relevant username and password (that has vCenter Admin rights in this case) and continue. As before, in a production environment this would probably be a separate account.

Now it comes to Certificates. These are tricky in vRA under an enterprise install. BUT, in a minimal install you are allowed to use Self-Signed Certificates. And we are most certainly going to do this! First up is the certificate for the virtual appliance.

The screen below shows the result of the following procedure.

Select the Generate Certificate option.
Type in a relevant Organisation, Organizational unit and country code (the first two can be whatever, the country code needs to be right).
Click Save Generated Certificate and wait a sec.
The screen will refresh to that shown below.

Now on to the creation of the Web certificate for the IaaS server. Same procedure as before using the same values and you should be left looking at a screen as shown below. This is a time saving of about 3 hours and two servers over the enterprise way of doing this section.

Finally… the Manager service certificate. It should pick up that it’s on the same box as the IaaS Web server and use the cert you just generated. It will look something like this.

The wizard is now almost done. It’s time to validate the install. Click the Validate button and you’re away. Progress will be shown like the screenshot below.

Take note of this line. It really does take this long. Go make another cuppa…

After the wait you should be greeted with this. We’re finally ready to install.

The next screen gives very important advice. vCAC 6.x was notorious for failing the install and leaving everything in such a state that you had to rebuild from scratch (yes, seriously) and try again with fingers crossed. Guard against this possibility by snapshotting the vRA appliance, this IaaS server and the SQL server before attempting the install. It’s worth the wait!

Once you’ve done this it’s time to ignore this next screen and press Install.

Now all you need to do is wait while everything gets installed and configured. a pretty helpful status is shown.

NOTE: I ended up with a screen showing “success” and “100%” install but with the final item on the list still showing as in progress. This is, I think, a bug. everything had completed fine and the system functions as expected.

Once the install is complete vRA will ask you for the licence key.

NOTE: You don’t HAVE to enter a key at this time. However, you can’t do anything if you don’t as there’s no free trial period with vRA 7. If you go on without the key you can display the logon page and sign in. However, it just sits there with a spinning wheel and wont load the mains creen

Next to the option to turn on telemetry which sends info to VMware. IMO this product needs all the help it can get (despite being awesome). Turn it on.

Finally there is the option to create a vRA catalog items that will go off and create a suite of blueprints for you to get you started. This is quite a cool idea and takes the guess work out of navigating the interface the first time. it’s basic but its useful.

You simply need to choose a password for a user that will be created called configurationadmin. In the next stage you’ll log in as this user and run the process to create initial blueprints.

Click the Create Initial Content button and you should see:

That’s it! Now it’s time to log in and create some blueprints. This will be covered in part 4 of this series!

Onwards… To part 4