WilliamLam.com

The Missing Piece In Creating Your Own Ghetto vSEL Cloud

by // 21 Comments

Awhile back I discovered an undocumented flag called "esxvm" in the SQL statements of the new vCloud Director 1.5 installer that suggested the possibility of deploying nested ESXi hosts in vCD. However, after further investigation the flag only enables the automated deployment of an ESXi 5 parameter (vhv.allow) which is required to run nested ESXi 4.x/5.x hosts as part of preparing a new ESXi 5 hosts in vCloud Director. There was still a missing piece to the puzzle to enable this functionality within vCloud Director user interface.

The answer eventually came from attending a recent session at VMworld 2011 in Las Vegas CIM1436 - Virtual SE Lab (vSEL) Building the VMware Hybrid Cloud by Ford Donald of VMware. I will not go into detail about what vSEL is, if you would like more information take a look at this blog post The Demo Cloud at VMworld Copenhagen or check out Ford's VMworld presentation online. In one of Ford's slides, he describes the necessary steps to enable nested ESXi called ESX_VM mode in vCloud Director which actually consists of two parts:

  • Enable nested virtualization and 64-bit vVM support in vSphere 5
  • Enable special mode in vCloud Director called ESX_VM to allow for vSphere 4 and 5 hosts as valid guestOS types

There are also some additional steps that are required after enabling ESX_VM mode:

  • Preparing or re-preparing ESXi 5 hosts
  • Allowing for Promiscuous Mode in vCD-NI or VLAN-backed Network Pool

********************* DISCLAIMER *********************
This is not a supported configuration by VMware and this can disappear at any time, use at your own risk 

********************* DISCLAIMER *********************

Note: I will assume the reader has a good understanding of how to install/configure vCloud Director and how it works. I will not be going into any details in configuring or installing vCD, you can find plenty of resources on the web including here, here, here and here. I will also assume you understand how to configure vCD-NI and VLAN-backed network pools in vCloud Director and how they work.

The first part is to enable nested virtualization (nested ESXi) support within the ESXi 5 hosts when they're being prepared by vCloud Director by updating the following SQL statement as noted in my earlier blog post Cool Undocumented Features in vCloud Director 1.5:

UPDATE config SET value='true' WHERE name='extension.esxvm.enabled';

The second part is to update the vCloud Director database to add support for both vSphere 4 and 5 hosts as valid guestOS types:

INSERT INTO guest_osfamily (family,family_id) VALUES ('VMware ESX/ESXi',6);

INSERT INTO guest_os_type (guestos_id,display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version, supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto, is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version) VALUES (seq_config.NextVal,'ESXi 4.x', 'vmkernelGuest', 6, 1, 1, 8, 3072, 7,1, 1, 4, 8, 0, 0, 0, 0, 107, 40);

INSERT INTO guest_os_type (guestos_id,display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version, supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto, is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version) VALUES (seq_config.NextVal, 'ESXi 5.x', 'vmkernel5Guest', 6, 1, 1, 8, 3072, 7,1, 1, 4, 8, 0, 0, 0, 0, 107, 50);

To apply these SQL statements to your vCloud Director 1.5 database, you will need to login to either to your Oracle or SQL Server database and manually execute these statements using the account that you originally created.

Here is an example of executing the SQL statements on an Oracle Express 11g database (Oracle Express is not officially supported by VMware):

As you can see, we need we first create a new guest_osfamily type called "VMware ESX/ESXi" and we need to also provide a unique family_id, which from a default installation of vCloud Director 1.5, the next available value will be 6. Next, we need to create the two new guestos_type "ESXi 4.x" and "ESXi 5.x" and again we need to provide a unique guestos_id which from a default installation of vCloud Director 1.5, the next available values will be 81 and 82. If any errors are thrown regarding a constraint being violated, then the ids may already have been used, you can always query to see what the next value is or select a new id.

Once you have executed the SQL statements, you will need to restart the vCloud Director Cell for the changes to take effect and if you already have prepared ESXi 5 hosts, you will need to re-prepare the hosts.

If you prefer not to manually do this, you can take a look at my blog post Automating vCloud Director 1.5 & Oracle DB Installation which has been updated to allow you to enable ESX_VM mode with your vCloud Director 1.5 installation. There is a new flag in the vcd.rsp file called ENABLE_NESTED_ESX which can be toggled to true/false which will automatically perform the SQL statements as part of the post-installation of vCloud Director 1.5 and restart the vCD Cell for you.

Here is a screenshot if you decide to enable this flag:

Finally, the last configuration tweak is to enable both promiscuous mode and forged transmit in either your vCD-NI or VLAN-backed Network Pool which is a requirement to run nested ESXi hosts. You locate the name of your network pool to identify distributed portgroup.

Next you can either use the vCD API or login to your vCenter Server and enable the promiscuous mode for that specific distributed portgroup.

UPDATE: Thanks to @DasNing - You can also enable promiscuous mode by executing the following SQL query: UPDATE network_pool SET promiscuous_mode='1' WHERE name=';

We are finally done with all the configurations!

If you successfully completed the above, when you go and create a new virtual machine in vCloud Director, you should now have a new Operation System Family called "VMware ESX/ESXi"

Within this new OS family, you can now provision a new ESXi 4.x or ESXi 5.x guestOS

Here is an example of my own vGhettoPod which includes vMA5 and vESXi 5 host which I can use to perform various types of testing in my home lab.

Now you can create your own ghetto vSEL cloud using VMware vSphere 5, vCloud Director 1.5 and vShield 5!

How to Use Custom VM Icons in the vSphere 5 Client

by // 3 Comments

Ever get tired of the same old virtual machine icons in the vSphere Client? Ever thought about changing it? Well with vSphere 5, you can! Here is a screenshot of some the custom icons I added for several virtual machines in my development lab.

One of the major enhancement in the vSphere 5 API is the introduction of the vCenter Solutions Manager, vSphere ESX Agent Manager, and vServices SDK. These various interfaces allows ISVs, partners and end users to easily extend the functionality of the vCenter Server and provide solutions that are tightly integrated via extensions/plugins that are aware of features such as vSphere HA, DRS and DPM.

Here what each of the interfaces provides:

vCenter Solutions Manager - is a view in the vSphere client where you can monitor and interact with the solutions that register with a vCenter Server instance. Solutions Manager shows three standard tabs for each running solution. The tabs list the virtual machines that a solution deploys and manages, show the health, name, company URL, version of the solution, and show any vServices that the solution provides.
vSphere ESX Agent Manager - automates the process of deploying and managing vSphere ESX agents. The services that ESX Agent Manager provides include out-of-the-box integration of agents with vSphere features such as DRS, AddHost, High Availability, DRM, and maintenance mode. All of these features can be difficult to integrate with manually. ESX Agent Manager also allows users to monitor the health of ESX agents, and blocks users from performing certain operations on ESX agents that might affect the virtual machines that use them. For example, ESX Agent Manager can prevent an ESX agent virtual machine from being powered off or moved from an ESX host that contains other virtual machines that use that agent.
vServices SDK - is a service that a solution provides to specific applications that run inside virtual machines and vApps. A solution can provide several types of vServices. Virtual machines or vApps can have dependencies on several types of vServices. A vService is similar to a virtual hardware device upon which virtual machines and vApps can depend. Instead of providing a piece of virtual hardware, vServices typically provide access to a service across a network. By providing a vService, a solution can expose application-aware services to virtual machines and vApps. For example, a vService can provide a backup service or a logging service to virtual machines and vApps.
For more details about these interfaces and how to implement them, take a look at the documentation here.

Even though these APIs are really meant for ISVs and partners to consume, if you would like to add a splash of color to your environment, you can use the following trick. At at high level we will be adding a new extension(s) which includes a mapping of a particular solution (e.g. logical name) to a particular icon that a virtual machine or vApp can be associated with. The icons must be 16x16 PNG format referenced by a URL. Once the custom extension has been created, you will then need to reconfigure the virtual machine(s) and associate the managedBy property to the solution's logical name key to update the virtual machine's icon.

You will need access to either the vCLI or vMA and the following two vSphere SDK for Perl scripts: registerCustomSolution.pl and updateVMManagedBy.pl You will also need access to vCenter Server 5 as this is not supported on an ESXi 5 host.

There is a very simple example in registerCustomSolution.pl which creates two extensions: one that includes custom icons and tabs that can link to any webpage (vGhetto) and one that only includes custom icons (Custom Application). You will need to edit the script so it fits your environment and there is a special variable in the script called "editedScript" which is set to 0 that prevents the script from running. This will ensure you do not accidentally create these extensions based on information in my development environment. Once you have updated the script, go ahead and change the value to a 1.

When you are ready, you will use the registerCustomSolution.pl script to create the extensions, here is an example:

To verify that the extensions were created properly with the information you provide, you can use pluginExtensionManager.pl to list all registered extensions. The command is the following: ./pluginExtensionManager.pl --operation list

You should see at the bottom of the output the extensions that were just registered and the associated configurations URL + icons. It is important to make note of the extension key (e.g. com.vmware.vGhetto) and the solution type string as that will be needed in the next section.

Now all we need to do is associate a particular virtual machine with the solution to update the virtual machine's default icon. You will use the updateVMManagedBy.pl script and using the extension key and type from the output from the previous screen.

To verify the icons have been updated, you will need to login to the vCenter Server and check out your virtual machines.You will also notice that on the right hand side of the virtual machine summary screen, there is a new "Managed By" section which includes a link to the vCenter Solution Manager.

Note: If you would like to reset or revert back to the original icons, you just need to use the  updateVMManagedBy.pl script and specify a empty string for the key. If you would like to unregister and remove the extension all together, you can use pluginExtensionManager.pl and perform remove operation.

Another way to view all the vCenter Solutions is on the home page and by clicking on the vCenter Solutions Manager icon.

From here you will see all registered vCenter extensions including some information about the vendor, version and health of the extension.

Here is a drill down into one of the extensions that contains several tabs to some URLs

As you can see, you can link to some useful URLs that can easily be accessible through the vSphere Client without having to go to your browser. Another neat feature of the tabs is to include any web management interfaces for a particular solution/vApp so that you can easily configure and manage the system from a single pane of glass.

In addition to this, you can also get a summary of the registered virtual machines with a given solution by clicking on the "Virtual Machines" tab and selecting "Managed By" box, the "Server" and "Agents" are reserved for ESX Agents.

There are also two caveats to be aware of if you decide to create custom icons for your virtual machines. The first is when you edit a virtual machine, you will get an annoying pop-up that states changes to the solution is not recommended. Under normal circumstance, where a solution/extension is provided by a 3rd party, you definitely do not want to manually tweak the virtual machine but in this scenario, it is fine.

The second thing I noticed is the custom icons do not properly show up in the nextgen vSphere Web Client, a default icon is used instead for virtual machines who have custom icons. I am not sure if this is a display bug with the vSphere Web Client or with the APIs.

So there you have it, if you are bored at looking at the same old icons and would like to differentiate some or all of your virtual machines, you now have the option to use custom icons.

How to Automate the Deployment & Configuration of vShield Manager 5

by // 8 Comments

If you have ever worked with VMware vShield Manager, you know that deployment and configuration of the virtual appliance is pretty much a manual process. You can automate the deployment of the vShield Manager OVA using the various vSphere SDK's or the ovftool, but the initial IP address configuration for vSM still needs to be configured manually using the remote console for the very first time.

An easy solution to this problem would be for VMware to create the vSM OVA to support IP address configuration out of the box as part of the deployment options (but why make things easy). In any case, I will demonstrate how you can easily automate both the deployment and the initial configuration of vShield Manager to your vSphere environment.

Before I begin, I can not take credit for coming up with the idea of automating vShield Manager deployment, the credit goes to Alan Renouf. Alan recently contacted me and ask if it was possible to automate the IP configuration. The answer is yes and here is a solution.

One of the main challenges in figuring out how to automate the IP address configuration of vShield Manager was due to the vtysh integrated shell daemon for Zebra that launches by default as part of the "admin" user account. This interface is used to manage the kernel routing and management table and made it very difficult to interface with for any type of automation. I decided manually go through a vSM configuration and then using Knoppix LIVE-CD, I was able to mount up the vSM filesystem and look around to get a better understanding of what was going on. After some investigating, it looks like IP address configuration is stored in /common/configs/cli/zebra.conf, here is an example of what the configuration looks like:

Armed with this knowledge, it was pretty straight forward in developing an automated way of deploying and configuring vShield Manager. I created a script called deployvShieldManager.sh which utilizes guestOpsManagement.pl, vCLI and ovftool. It's recommended that you use vMA and install ovftool to quickly get started. At a high level, the script is doing the following:

  1. Deploy vShield Manager OVA using ovftool
  2. PowerOn vSM and wait 2 minutes for VMware Tools to be ready on the system
  3. Create new zebra.conf, backup the old zebra.conf and upload new zebra.conf using the new vSphere 5 VIX integration
  4. PowerOff vSM to force the configurations to be read in upon next bootup
  5. PowerOn vSM and it is now ready for use

At the top of the script, there are several configuration variables that need to be edited by the user to specify the vSM configuration, including vCenter and ESX(i) host to deploy vSM.

Here is a list of variables that need to be configured at the top of the deployvShieldManager.sh script:

Once you are done updating the variables, you are now ready to execute the script. Before the script performs any changes, it will first prompt the summary of configurations you have specified in the script. Once you are satisfiy, you may than proceed by typing "y" or "yes" to start, or if you would like to cancel, type "n" or "no".

Note: The script will perform some basic validation such as existence of the vShield Manager OVA, ovftool, etc. else you will get an error message and the script will exit.

Next, the script will perform the deployment of vSM using ovftool and proceed with the configuration of vSM once it has been deployed.

Note: If it takes longer to poweron vSM in your environment to get it into a ready state, you may want to tweak the sleep period from 120 seconds (2minutes) to something longer.

At this point, you now should see a new vShield Manager VM deployed and if you take a look at the summary page, you should see the new IP address and hostname configurations.

Now all that is left is to point your browser to the vSM address and you should be prompted to login to vShield Manager management interface.

Instead of manually deploying vShield Manager in your environment, you can now automate the initial deployment and configuration for general use or with VMware vCloud Director. For further automation and configuration of vShield manager, once vSM is online and accessible, you can leverage the vShield REST API.