WilliamLam.com

Automating VCSA 5.1 (vCenter Server Appliance) Configurations

by // 15 Comments

If you have seen my previous article on Automating VCSA (vCenter Server Appliance) 5.0, you will notice the existing script will not work on latest VCSA 5.1, without a minor tweak. The reason for this is due to the new vCenter SSO (Single Sign-On) configuration that is now part of the initial setup.

Note: If you would like to learn more about the new vCenter SSO, I would recommend you take a look at the What's New vCenter Server 5.1 whitepaper.

Luckily, the change is quite simple and in the example below, you will be configuring vCenter Server SSO to run in the embedded mode on the VCSA. I have also enhanced the script to include the joining of an Active Directory domain if you wish to have the VCSA backed by AD.

Disclaimer: This is for educational purposes only, this is not officially supported by VMware. Please test this in a development environment before using it on actual systems.

Here is a script with the minimal commands needed for running an embedded configuration:

#!/bin/bash

# User Configurations
JOIN_AD=0
AD_DOMAIN=primp-industries.com
AD_USER=administrator
AD_PASS=mysupersecurepassword
VCENTER_HOSTNAME=vcenter51-1.primp-industries.com

## DO NOT EDIT BEYOND HERE ##

echo "Accepting EULA ..."
/usr/sbin/vpxd_servicecfg eula accept

if [ ${JOIN_AD} -eq 1 ]; then
        echo "Configuring vCenter hostname ..."
        SHORTHOSTNAME=$(echo ${VCENTER_HOSTNAME} |  cut -d. -f1)
        /bin/hostname ${VCENTER_HOSTNAME}
        echo ${VCENTER_HOSTNAME} > /etc/HOSTNAME
        sed -i "s/localhost.localdom/${VCENTER_HOSTNAME}/g" /etc/hosts
        sed -i "s/localhost/${SHORTHOSTNAME}/g" /etc/hosts

        echo "Configuring Active Directory ..."
        /usr/sbin/vpxd_servicecfg ad write "${AD_USER}" "${AD_PASS}" ${AD_DOMAIN}
fi

echo "Configuring Embedded DB ..."
/usr/sbin/vpxd_servicecfg db write embedded

echo "Configuring SSO..."
/usr/sbin/vpxd_servicecfg sso write embedded

echo "Starting VCSA ..."
/usr/sbin/vpxd_servicecfg service start

Note: By default the script will not join an AD domain, you will need to change the JOIN_AD variable to 1 and ensure you specify all the Active Directory configurations including the FQDN of your vCenter Server as this is required for properly join your VCSA to your AD domain. If you choose to join an AD domain, make sure you have proper forward/reverse DNS configured on the VCSA and you will also need to reboot the VCSA for the changes to take effect.

To run the script remotely (you do not need to copy it to VCSA), use the following command:

# ssh root@[vcsa-ip] < configureVCSA.sh

You can now quickly deploy and configure your VCSA in just minutes versus spending 5-10 minutes clicking around and waiting for the web interface. Once you have tried this script, you will never go back to manually configuring the VCSA using the web interface!

Project Nanosphere

by // 5 Comments

The #NotSupported event at the VMworld Community Lounge ended with a very special presentation by our very own Randy Keener about a project that a few VMware engineers have been working on called Nanosphere. For those of you who could not make the session or attend VMworld this year, here is some additional information about what Project Nanosphere is all about.

What is Nanosphere?

First off, Nanosphere is not a product, it is a proof-of-concept. The idea is to make ESXi easier to deploy and manage for non-technical users in small environments (SOHO, remote/branch office, family) to get the same benefits of virtualization that enterprises have. Nanosphere provides an ultra-lightweight management layer on top of an ESXi host that will offer a basic set of features including self-configuration, VM provisioning, VM lifecycle management, and console access.Today, connecting to a VM console typically requires both server-side dependencies (a VDI broker, a Windows stack, or specialized guest customization) and client side dependencies (installing a special ActiveX browser plugin that works only on Windows, and only in IE or Firefox browsers). By deploying WSX on ESXi, it makes it possible to connect to any VM (any guest OS) with any modern browser (e.g. including iPad) without any special software.

What can Nanosphere do?

  • Network auto-configuration
    • Automatic network configuration without ever typing an IP address
  • Web Management Interface
    • Provision, Delete, Power On/Off Virtual Machines with pure HTML5 interface
  • Console access without special apps or plugins
  • Dead-simple installation
    • Just install a tiny VIB onto any ESXi host and you’re good to go. The VIB can also be integrated into a vanilla ESXi ISO image
During Randy’s session, a demo of the network autoconfiguration of Nanosphere and its web interface was given and here is how it works.Assuming you have a simple cable-model-like setup:

  1. The physical host has ESXi and Nanosphere installed.
  2. You "unbox" it (take it home from Staples) and plug it in on your home LAN, headless.
  3. It gets DHCP but you have no idea what the address is because it's headless.
  4. Nanosphere "phones home" to a broker running at nanosphere.cloudfoundry.com (custom application written on Cloudfoundry) to report its local LAN address (e.g. '192.168.0.4') and its UUID. The broker also records the WAN address.
  5. You use a plain browser on any device on the same LAN - we used an iPad - to connect to the same broker. It matches the WAN addresses and redirects the browser to the Nanosphere’s LAN address.
Here are a few screenshots of the Nanosphere web interface:

What's next for Nanosphere?

As mentioned earlier, nanosphere is still a proof-of-concept but the VMware engineers have some interesting ideas on where it could go and would love to get your feedback if the following use cases interests you.

  • Early adopters and hobbyists playing with ESXi for fun
  • VARs delivering Nanosphere-based servers in selected vertical markets
  • Nanosphere-based appliances delivering NAS and media streaming
  • Nanosphere-based servers for developing markets and nonprofit organizations
  • Hybrid public/Nanosphere clouds with bidirectional app portability
  • OEMs delivering Nanosphere-based servers through a retail channel
  • Value-added services like cloud backup and remote admin (including VMware GO)
Other work includes tracking ongoing WSX improvements. If any of these use cases interests you, please leave a comment below or if you have other ideas/feedback for Nanosphere, feel free to leave a comment as well.I think the Nanosphere project is a really cool initiative and hopefully we will get to see more in the future. I wanted to also give a big thanks to folks who worked on the Nanosphere project and made it possible to show off at the #NotSupported event: Steve Strassmann (VMware Staff Engineer), Shivam Tiwari (VMware Intern) and of course Randy Keener (VMware TechOps) for presenting on Project Nanosphere!

How to Enable Nested ESXi & Other Hypervisors in vSphere 5.1

by // 88 Comments

There are a ton of new features with the latest release of vSphere 5.1, but the one "unsupported" feature I always test first is "Nested Virtualization" (aka Nested ESXi) and with the latest release, it seems to have gotten even better. You will still need to have the same physical CPU prerequisites as you did in the past to run "Nested Virtualization" as well as nesting 64-bit VMs.

  • Intel VT-x or AMD-V is required for running "Nested Virtualization" which supports nested 32-bit VMs
  • Intel EPT or AMD RVI is required for running nested 64-bit VMs.

A quick way to verify whether your CPU truly supports both Intel-VT+EPT or AMD-V+RVI, you can paste the following into a browser:  

https://[your-esxi-host-ip-address]/mob/?moid=ha-host&doPath=capability

You will need to login with your root credentials and then look for the "nestedHVSupported" property and if it states false, it means you maybe able to install nested ESXi or other hypervisor, but you will not be able to run nested 64-bit VMs, only 32-bit VMs, assuming you have either Intel-VT or AMD-V support on your CPUs.

For more details, take a look at this article for troubleshooting: Having Difficulties Enabling Nested ESXi in vSphere 5.1?

Disclaimer: This is not officially supported by VMware, please use at your own risk.

There are some changes with Nested Virtualization in vSphere 5.1 also officially known as VHV (Virtual Hardware-Assisted Virtualization). If you are using vSphere 5.0 to run Nested ESXi or other nested Hypervisors, then please take a look at the instructions in this article. With vSphere 5.1, there have been a few minor changes to enable VHV.

  1. The new Virtual Hardware 9 compatibility will be required when creating your nested ESXi VM, Virtual Hardware 8 will not work if you are running ESXi 5.1 on your physical host. You will still need to enable promiscuous mode on the portgroup that will be used for your nested ESXi VM for network connectivity.
  2. vhv.allow = "true" is no longer valid for ESXi 5.1 to enable VHV. A new parameter has been introduced called vhv.enable = "true" that is now defined on a per VM basis to provide finer granularity of VHV support. This also allows for better portability between VMware's hosted products such as VMware Fusion and Workstation as they also support the vhv.enable parameter.
  3. You can now enable VHV on a per VM basis and using the new vSphere Web Client which basically adds the vhv.enable = "true" parameter to the VM's .VMX configuration file.

Note: You can run a nested ESXi 5.1 VM on top of a physical ESXi 5.0 host, just follow the instructions here.

Enabling VHV (Virtual Hardware-Assisted Virtualization)

Step 1 - Create a new Virtual Hardware 9 Virtual Machine using the new vSphere Web Client that's available with vCenter Server 5.1.

Step 2 - Select "Linux" as the guestOS Family and "Other Linux (64-bit)" as the guestOS Version.

Step 3 - During the customize hardware wizard, expand the "CPU" section and select "Hardware Virtualization" box to enable VHV.

Note: If this box is grayed out, it means that your physical CPU does not supported Intel VT-x + EPT or AMD-V + RVI which is required to run VHV OR that you are not using Virtual Hardware 9. If your CPU only supports Intel-VT or AMD-V, then you can still install nested ESXi, but you will only be able to run nested 32-bit VMs and not nested 64-bit VMs.

Step 4 - It is still recommended that you change the guestOS Version to VMware ESXi 5.x after you have created the VM shell, as there are some special settings that are applied automatically. Unfortunately with the new vSphere Web Client, you will not be able to modify the guestOS after creation, so you will need to use the C# Client OR manually go into the .VMX and update guestOS = "vmkernel5"

Now you are ready to install nested ESXi VMs as well as run nested 64-bit VMs within.

If you have followed my previous article about How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5 you may recall a diagram about the levels of "Inception" that can be performed with nested ESXi. That is, the number of times you could nest ESXi and still have it be in a "functional" state. With vSphere 5.0, the limit that I was able to push was 2 levels of nested ESXi. With latest release of vSphere 5.1, I have been able to push that limit now to an extraordinary 3 levels of inception!

You might ask why would someone want to do this ... well I don't have a good answer other than ... because I can? 😉 VHV is one of the coolest "unsupported" feature in my books and I'm glad it is working beyond what it was designed for.

For proper networking connectivity, also ensure that either your standard vSwitch or Distributed Virtual Switch has both promiscuous mode and forged transmit enabled either globally on the portgroup or distributed portgroup your nested ESXi hosts are connected to.

Nesting "Other" Hypervisors

For those of you who feel inclined to run other hypervisors such as Hyper-V, you can do so with latest release of ESXi 5.1. The process if very straight forward just like running nested ESXi host.

Step 1 - Create a Virtual Hardware 9 VM and select the appropriate guestOS. In this example, I selected Windows Server 2012 (64-bit) as the guestOS version.

Step 2 - Enable VHV under the CPU section if you wish to create and run nested 64-bit VMs under Hyper-V

Step 3 - You will need to add one additional .vmx parameter which tells the underlying guestOS (Hyper-V) that it is not running as a virtual guest which in fact it really is. The parameter is hypervisor.cpuid.v0 = FALSE