WilliamLam.com

Cool Undocumented Features in vCloud Director 1.5

by // 6 Comments

While working on the updated script in Automating vCloud Director 1.5 & Oracle DB Installation, I did some digging in my lab deployment and noticed a few interesting things about the new vCloud Director 1.5 installation.

The first thing I noticed after configuring a new Provider vDC and the vCloud Agent (stored in /opt/vmware/vcloud-director/agent) is pushed out to the ESXi 5 hosts, a new esxcli module is added for vCloud Director under /usr/lib/vmware/esxcli-vcloud

There are 6 namespaces that ranges from simple configuration query, network fence management, account manage and also something called "esxvm" which I'll go into a little bit later. I am not sure why this is not in the vCloud Director documentation, I was not able to find any reference to the new esxcli operations. You may also notice the use of legacy "vslauser" (Virtual Software Lifecycle Automation) throughout vCloud Director, even though it was re-written from the ground up, it looks like VMware decided to either keep the name or some of the code related to the service account.

Here is an example of running "esxcli vcloud about get" command:

Here is an example of running "esxcli vcloud fence getfenceinfo" command:

Lastly, here is an example of what "esxvm" namespace provides:

As you can see above, there are two operations: disable/enable support for 64-bit nested virtual machines. This is exactly the same configuration as I blogged about in How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5 but using esxcli interface with vCloud Director 1.5. Let's take a look at what happens when we run the "enable64bitnested" operation.

No surprise, we see that it automatically appends the required vhv.allow = "TRUE" flag which enables the support of running nested 64-bit virtual machines within a physical ESXi 5 host.

You might be asking, why is this in vCloud Director? Well if you attended VMworld 2011 or previous VMworlds and took part in the hands on labs, you will know that VMware utilizes vPods or nested ESXi to deploy their labs. I suspect, this functionality was added into vCloud Director so that VMware can easily leverage nested ESXi for hands on labs or vSel deployments just like they did with Lab Manager previously.

While look into this, I recall a very interesting article by Jason Boche - Deploy ESX & ESXi With Hidden Lab Manager 4 Switch in which Jason identifies a hidden flag in the Lab Manager database that enables a special feature in deploying nested ESX(i) VMs including customization through the use of a special version of VMware Tools for ESX(i). I was curious to see if something similar existed in the new vCloud Director that provided similar functionality.

Looking at the SQL install scripts located in /opt/vmware/vcloud-director/db/{oracle/mssql}, I noticed an interesting config called "extension.esxvm.enabled" in NewInstall_Data.sql file

As you can see from the insert statement, by default this value is set to "false" and we can also confirm this after vCloud Director has been installed and configured by querying the database. Let's go ahead and update this value to "true" and let's see what happens. 

Once you have verified the value has been successfully updated, I decide to use the same trick that Jason had identified with the special "Uber Admin Screen" to load the changes. To my surprise, the trick still worked but the page was not super Uber .... To enable the screen, you will need to click on the "About" page and then click CTRL+U (ctr + shift + u), which will toggle the "Uber Admin Screen".

The available options are quite limited as you can see but there are some new hidden options such as a new debug and console toggle. When you enable these options, you will see them at the bottom right of your screen including a counter of the amount of memory being used for your vCloud Director deployment.

After toggling the hidden database feature, I was not able to see any additional pages relating to nested ESXi hosts, even after restarting vCloud Director. Through some testing, I found that the "extension.esxvm.enabled" actually controlled whether or not nested 64bit VM was enabled when the vCloud Agent was pushed out to ESXi 5 hosts. Instead of manually adding vhv.allow = "TRUE" or using esxcli vcloud esxvm enable64bitnested, vCloud Director will automatically configure the ESXi hosts for you. I still suspect there is probably a hidden interface in managing vESXi hosts and leveraging a specialized version of VMware Tools to automate the deployment of nested ESXi, but I have not found out yet.

UPDATE: Take a look at this blog post for the full details on building your own vSEL - The Missing Piece In Creating Your Own Ghetto vSEL Cloud

Duncan's 50 out of 140 vSphere 5 Features Challenge

by // 4 Comments

You may have heard that vSphere 5 has officially launched today (well last night ~7pm-ish PST), but you may not know, that there are over 140 new features introduced in this release. Duncan Epping shared a blog post vSphere 5.0 Features detailing a list that was generated internally from VMware on the 140 features. Duncan also provided a challenge to the readers:

Now before we will give you the full list we want to challenge you... Who will be the first one to show 50 of the below listed features in an article? We will give a "vSphere 5.0 Clustering Technical Deepdive" book signed by both authors to the first 5 people who manage to write a single article detailing 50 of the below features with short paragraph about what this feature brings including a screenshot.

Even though I had already purchased the colored copy of vSphere 5.0: Clustering and Technical Deepdive which I am still trying to finish (only half way done), I decided to accept Duncan's challenge and here is my list of the 50 features I decided to write about.

Note: I personally have not worked with all 50 features listed below, some of these were selected due to ease of capturing a screenshot.

[Read more...]

New Hidden CBRC (Content-Based Read Cache) Feature in vSphere 5 & for VMware View 5?

by // 25 Comments

CBRC (Content-Based Read Cache) is another new/hidden feature of vSphere 5, not to be confused with the new Host Cache feature (swap to host cache). I initially thought CBRC was related to host cache and that it might have been an internal name for the feature. In a recent discussion on the VMTN community forums, a reader pointed out that CBRC is different and there is not whole lot of information on how it works. I decided to perform a quick Google search to see if anyone has written about this feature and one site had an interesting quote from a VMware sales rep on how CBRC works:

Content-Based Read Cache. A content-based read cache (CBRC) has been delivered for specific use with View (VDI) workloads. With this option configured in ESX, a read cache is constructed in memory optimized for recognizing, handling, and deduplicating VDI client images. The cache is managed from within the View Composer and delivers a significant reduction, as high as 90% by early estimates, in IOPS from each ESX host to the storage platform holding client images. This reduction in IOPS enables large scaling of the number of clients in case multiple I/O storms, typical in large VDI deployments, occur. 

It looks like CBRC is implemented within hypervisor but it will be leveraged by VMware View 5 around provisioning Linked Clones? One question I had was whether or not this constructed cache in memory could be used without VMware View?

*** Disclaimer: I do not have any insider information from VMware, these are my own personal observations. The following section is not supported by VMware, use at your own risk ***

There are two new sections under the Advanced Settings of an ESXi 5 host, CBRC and Digest.

There are 4 configurable options to enable CBRC, to configure the cache size, to configure the cache size reservation and interval for digest journal.

I believe the Digest section is related with respect to the algorithms used for CBRC

CBRC looks to only support a maximum of 2GB of memory and default of 400MB reservation. In this example, I have a brand new ESXi 5 host with 8GB configured and without any running virtual machines, here is how much memory it is using.

Now let's go ahead and change the CBRC reserved memory from 400MB to 2048GB (max) and enable CBRC.

If we go back to ESXi summary page, we'll see that an additional 2GB is now being reserved by the ESXi host.

You can also enable and configure CBRC using the CLI, but the ability to enable is only available when using vim-cmd interface in ESXi Shell, the other three options can be configured using legacy esxcfg-advcfg, esxcli or vsish.

Here's an example of enabling CBRC and changing the CBRC memory reservation to 1GB:

vim-cmd hostsvc/advopt/update CBRC.Enable bool true
vim-cmd hostsvc/advopt/update CBRC.DCacheMemReserved long 1024

Ifyou are interested in other advanced settings for CBRC that are not publicly exposed, be sure to check out this post here.

Note: Something I noticed about CBRC is there is an admission control check when you initially enable the feature. If you do not have sufficient memory to pass the admission control check, you will get a very generic error. To see if it is related to admission control by looking in vmkernel.log, you may see a message such as the following: WARNING: cbrc_filter: CBRC_MemSetMemAllocation:1420:Failed to set memory resource parameters for CBRC (Admission check failed for memory resource)

So now that CBRC is enabled, how do we actually use the feature? Well, as I mentioned earlier in the post, this is both a new and hidden feature. Hidden in the sense, that it's not meant to be used directly on an ESXi or vCenter Server but by actually by View Composer. Though you can still access the hidden APIs using the vSphere MOB connected to either vCenter Server or ESXi host.

To get to the new CBRC managed object manager, you can point your browser over to following URL:

https://[hostname]/mob/?moid=ServiceInstance&method=retrieveInternalContent

You will notice a new managed object manager "cbrcManager", go ahead and click on it.

There are 4 methods associated with configuring CBRC:

Note: A shortcut to getting to the CBRC managed object manager is using the following URL:

ESX(i) - https://[hostname]/mob/?moid=ha-cbrc-manager
vCenter - https://[hostname]/mob/?moid=CbrcManager

The ConfigureDigest_Task is what is needed to configure CBRC for a given virtual machine and specifically a virtual disk. The parameters that are needed is both the managed object reference ID of the virtual machine and the virtual disk device ID.

If we browse over to https://[hostname]/mob/?moid=ha-host, we'll be able to identify the virtual machine's MoRef ID and in this example, it's 1

Next we'll need to identify the virtual disk device ID, by traversing the virtual hardware array until we find the virtual disk we're interested in.

The ID for this virtual disk is 3000 and you will also notice a new property called digestEnabled, currently it is disabled.

Now we have everything we need to construct ConfigureDigest_Task method, click on the method name and it will open a new page for you to specify the virtual machine ID and the deviceKey for the virtual disk. You will see the next option is to enable CBRC, I'm not exactly sure what the latter two options but I'll go ahead and enable them anyways.

Once the task has completed, you can view the results and you will see that CBRC has successfully been configured for the virtual machine:

You can also see that the task has been kicked off within the vSphere Client depending if you're connecting to ESXi 5 directly or to vCenter Server:

If we go back to the virtual disk, we will see that digestEnable property is now enabled:

One interesting observation I found was when you enable CBRC, if you browse the datastore of the virtual machine, you will see a new VMDK created with name "digest", this is probably what keeps track of the blocks from the virtual machine and what is loaded into memory.

We can also use the QueryDigestRuntimeStatus to check whether a virtual machine is enabled with CBRC, again specifying the virtual machine's MoRef ID and virtual disk device ID:

We can use QueryDigestInfo on an offline virtual machine to get the details of the digest information for a virtual machine with CBRC enabled:

The last method RecomputeDigest_Task should be self explanatory and it allows you to compute partial or full digest.

By enabling CBRC, the CBRC kernel module is loaded and with that, there are some interesting statistics that can be viewed for a given virtual machine. We'll be leveraging the VMware vsish interface to access the CBRC statistics. To get started, just type vsish and then you will need to change into vmkModules/cbrc_filter path.

One interesting property is the dcacheStats, you can just cat this entry and it provides an enormous amount of statistics about the cache including the number of virtual machines that are using the cache and various IO counters.

You will see that all counters are currently zero, once we start to spin up some Linked Clone virtual machines, you will want to pay close attention to some of these counters.

To answer the question on whether or not CBRC would work outside of VMware View 5, I decided to perform a functional test of the feature. I generated my own VMware Linked Clones using the following vSphere SDK for Perl script vGhettoLinkedClone.pl. You will need a vCenter Server, but you will NOT need VMware View.

Step 1 - Create an offline snapshot for the virtual machine that will be used as the base/golden image to create Linked Clones, in this example, the snapshot will be called "base"

Step 2 - Create several Linked Clones based off of this base/golden virtual machine, in this example, I will be creating three Linked Clone virtual machine named: ALinkedCloneVM1,ALinkedCloneVM2,ALinkedCloneVM3

If we go over to your vCenter Server, you should see the following inventory:

Step 3 - Let's power on the first two virtual machine "ALinkedCloneVM1" and "ALinkedCloneVM2" and let's check out the dcacheStats from vsish and see what has changed.

As you can see we now have counters incrementing on the number of VMs using the cache that was created with CBRC and also counters regarding the backend IO. It looks like the new Linked Clones that was generated can in fact leverage CBRC without VMware View 5. Now this was purely a functional test, these VMs were basically dummy shells, I would be very interested to see if someone is able to get this really working and actually leveraging CBRC with real base images and seeing the reduction of IOPS during a VDI boot storm.