WilliamLam.com

vGhetto Lab #NotSupported Slides Posted

by // Leave a Comment

As promised, here are slides to my #NotSupported session at VMworld Europe which I continued the theme of home labs with my vGhetto Lab #NotSupported presentation.

The idea behind the vGhetto Lab is to easily setup a vSphere home lab without too much effort and most importantly, leveraging as little resources as possible. This is all accomplished with the following:

  • Physical host running ESXi 5.x
  • ESXi 5.x offline depot image
  • VCSA 5.x (vCenter Server Appliance)

In addition to the above, you will also need to download the vGhetto Lab scripts which are shown in the video.
Here are some additional details on how to quickly get setup with your own vGhetto Lab.

Step 1 - After installing ESXi 5.x on your physical host, you will need to deploy the VCSA. Make sure you add a second network interface to VCSA as shown in the presentation. In my example, I created another vSwitch with no uplinks and portgroup for Auto Deploy network

Step 2 - Once the VCSA is powered on, go ahead and SCP the scripts to virtual machine. The first script that we will need to execute is the setupNetwork.sh and you will need to edit the following variables:

VCENTER_IP_ADDRESS_1=192.168.1.150
VCENTER_NETMASK_1=255.255.255.0
VCENTER_GATEWAY=192.168.1.1
VCENTER_IP_ADDRESS_2=172.30.0.1
VCENTER_NETMASK_2=255.255.255.0
VCENTER_HOSTNAME=vcenter.primp-industries.com
DOMAIN_LIST=primp-industries.com
DNS_LIST=192.168.1.1

Note: To ensure that you do not accidentally run the script without changing out the variables, there is another variable called ACTUALLY_READ_SCRIPT that needs to be changed from "no" to "yes" else the script will not execute.

Step 3 - Next we need to configure the vCenter Server, we will need to execute the configureVCSA51.sh which will configure the embedded SSO Database as well as the database of the vCenter Server. You do not need to edit any variables in this script

Step 4 - Finally, we need to configure our DHCP, TFTP, Auto Deploy services as well extracting the ESXi offline depot image and preparing it for use with Auto Deploy. You will need to edit the following variables before running the setupvGhettoLab.sh script.

DHCP_SUBNET=172.30.0.0
DHCP_NETMASK=255.255.255.0
DHCP_START_RANGE=172.30.0.100
DHCP_END_RANGE=172.30.0.200
DHCP_INTEFACE=eth1
TFTP_SERVER=172.30.0.1
VCSA_SERVER=192.168.1.150
ESXI_OFFLINE_DEPOT=/root/VMware-ESXi-5.1.0-799733-depot.zip
ESXI_REPO_PATH=/etc/vmware-vpx/docRoot
ESXI_REPO_DIR=ESXi-5.1.0

Note: For the Image Profile and Auto Deploy rule creation, if you wish for the script to execute them automatically versus echoing to the screen, remove the "echo" statement as well as the double quotes from the following so the last three lines look like this:

pxe-profile-cmd create $(cat /tmp/VIBS) ${ESXI_REPO_DIR}
rule-cmd create -i pxe:${ESXI_REPO_DIR} ${AUTO_DEPLOY_RULE} vendor=='VMware, Inc.'
rule-set-cmd set ${AUTO_DEPLOY_RULE}

Step 5 - You are now ready to create your nested ESXi virtual machines. You can use RVC as shown in the presentation (there is a slide at the very end which lists the commands) or you can connect to vSphere Web Client and create the ESXi virtual machines the traditional way via the GUI.

After updating the DHCP configurations with the new MAC Addresses from your nested ESXi virtual machines, you should then see Auto Deploy automatically provision your ESXi hosts and join them to the VCSA you deployed earlier.

Additional Links:

 

Using the New vCloud Networking and Security to Load Balance Multiple vSphere Web Client Servers

by // 1 Comment

If you followed my previous two articles Configuring Additional Windows vSphere Web Client 5.1 Servers & Configuring Additional VCSA 5.1 as vSphere Web Client Servers I demonstrated how easy it is to add additional vSphere Web Client Servers to provide additional connection load balancing as well as redundancy in accessing your vSphere 5.1 environment. The next logical step is to actually place a load balancer in front of all the vSphere Client Servers to provide a single entry point for users to connect to.

I did a quick search for some load balancer solutions for testing, but found that they were quite complex and non-intuitive to setup. Since this was for my home lab, I decided to try out the new vCloud Networking & Security 5.1 (previously known as vShield). This being my first time setting up a load balancer (usually a task given to Network Engineers), I was pleasantly surprised and shocked at how easy it was to deploy and configure a load balancer using the new vCloud Networking and Security. Instead of going through this step by step, I thought I record a quick video.

The video below shows how you can leverage the new vCloud Networking & Security 5.1 to deploy and configure a Load Balancer to load balance multiple vSphere Web Client Servers.

If you have not tried out the new vCloud Networking and Security, I highly recommend you give it a try, especially with all the new network and security features in the latest 5.1 release.

Adding Non-Supported ESXi Builds to VIN (vSphere Infrastructure Navigator)

by // 4 Comments

I was recently asked whether it was possible to add a non-supported ESXi host into VIN (vSphere Infrastructure Navigator)? The reason for this request is if you are running an ESX(i) build which is not on the list of supported builds, VIN would fail to discover virtual machines on that host. You may see the following error "Access failed. Unsupported ESX version"

The latest release of VIN 1.2 supports the following ESX(i) builds:

    • ESX/ESXi 3.5 (builds 425420, 408533, and 409724)
    • ESX/ESXi 4.0 (builds 398348, 403553, and 403554)
    • ESX/ESXi 4.1 (builds 433742, 433803, and 433804)
    • and all builds of ESXi 5.x.

If you happen to be running an ESX(i) build which is not listed but the build number is greater than the ones shown above, then there is a workaround. You can add the non-supported ESX(i) build into VIN's whitelist which would allow VIN to discover the virtual machines. In the example below I will be adding an ESXi 4.1 Update 3 Build 800380 which is not listed as a supported build.

Disclaimer: ESX(i) hosts with build numbers that are smaller than the ones listed may still be added, but this will most likely not be supported as the list of default build numbers are the minimum requirements. Please thoroughly test this in a lab environment before applying to your production environment.

You will need SSH access to your VIN appliance and before we get started, we will quickly verify the list of supported ESX(i) build versions by querying the VIN database (I was able to find the details in /var/log/vadm/dbconfig.log). Run the following command which will connect to VIN Postgres DB:

psql -h 127.0.0.1 -U vadm -d inception

The password for the database is vadm

Next, we will run the following SQL query to display the list of supported ESX(i) build numbers which should match the release notes. Run the following command:

select * from valid_host_build;

As you can see from the screenshot, the ESX(i) build numbers matches those listed in the VIN 1.2 release notes and we can also see that a wildcard is also a valid input value for ESXi 5.x which denotes any build of 5.x supported as noted in the release notes.

To add a non-supported ESXi build number into VIN's DB, we will be using the following script /opt/vadm-engine/set_valid_host_versions.sh which is located in the VIN appliance.

Note: You do not need to stop or restart the VIN service to run the command.

The script accepts a very simple XML file that contains the list of supported ESX(i) build numbers and it is very IMPORTANT to note that this will override the original defaults. This is part of the reason we performed a query to the VIN DB to ensure we have a copy of the original build numbers as a reference.

To add our additional ESXi build number, we will need to construct an XML file containing both the original build numbers as well as our non-supported. In this example, I created a file called myHostVersion.xml (based on the original DB data) which contains following:
Next we will pass in our XML input file to the set_valid_host_versions.sh script. Here is a screenshot of what that looks like after the operation has been successfully completed:

If we log back into the VIN DB and query the list of supported ESX(i) builds, we should be able to see our new build number that we inserted into the DB along with the original defaults:

During the next automatic discovery cycle, VIN should now be able to discover virtual machines running on the ESXi host that was not supported earlier.