Home > Blogs > VMware vCloud Blog > Monthly Archives: February 2011

Monthly Archives: February 2011

Getting Started with vCloud Director, VMware Remote Console Proxy and VMware Remote Console Plugin (Part 2)

By Michael Haines, vCloud Architect

In Part 1 of this post, I inroduced the components of the VMware console proxy, remote console proxy, and how they work with vCloud Director. In Part 2, I'll cover resiliency of the remote console proxy, what ports are required, operations available to the user, and run through troubleshooting and tools.

7. How Resilient is the Remote Console Proxy?

The VMware Remote Console Proxy Plugin actually opens four different connections to the Console Proxy for a single Remote Console session (three for the vCenter server, one for the ESX/ESXi server). The Console Proxy is stateless, and therefore the Load Balancer can route each of those four connections to different Console Proxies and the system would still work perfectly fine. If a connection is dropped for some reason (e.g. the Console Proxy dies), then the VMware Remote Console Proxy automatically tries to re-establish it and the Load Balancer can route it through a different Console Proxy. The user should not notice anything but a small delay.

8. What ports are required to be open for the Remote Console Proxy to function correctly?

The vCD Console Proxy Plugin communicates with the vCD server only on port 443 via the Console Proxy. That is the only port that is required to be open and accessible from the Internet.

9. What operations are available to a user of the Remote Console Proxy?

The following functionality is exposed by the VMware Remote Console Proxy and presented and consumed in VMware vCloud Director:

  • If the Virtual Machine (VM) is powered off and you connect the VMware Remote Console Proxy to it, it will implicitly power it on.
  • Power Off the Virtual Machine (VM).
  • Reset the Virtual Machine (VM).
  • Suspend the Virtual Machine (VM).
  • If the Virtual Machine (VM) is suspended, it will implicitly resume it on initial connection, similar to power on.
  • Remote MKS interactions, including grabbing / un-grabbing input, and explicitly sending Ctrl+Alt+Del to the guest.
  • Full screen support.
  • Remote device support for CD-ROMs and floppies, whether physical or backed by file images, which exists on the client machine.
  • Technically, it will let you connect these devices as server-side as well.
  • If the Virtual Machine (VM) temporarily disconnects, such, as during reverting to a snapshot or the MKS connection is lost, the VMware Remote Console will try to re-connect.

The VMware Remote Console Proxy behaviour is to automatically power on and resume the Virtual Machine (VM), if it is powered off or suspended when you open a console to it. However, vCD allows you to open a console of a Virtual Machine (VM), only if the state of the Virtual Machine (VM) is powered off. This behaviour is enforced by vCD and not the VMware Remote Console Proxy.

10. Troubleshooting

Here are some of the most common things to check if for some reason you are not able to use the Remote Console Proxy:

  • Does `netstat -nape | grep 443` show a java process listening on the IP Address that you specified as the (internal) console proxy IP Address when running the configure script? This should also show port 443 open on the HTTP service IP.
  • Can you telnet to port 443, 902, and 903 on the vCenter server from the vCD server?
  • Can you telnet to the public console proxy IP on port 443 from outside of your Load Balancer?
  • Do the VMware Remote Console Plugin logs, which exist on the client, tell you anything?  On Windows clients, the VMware Remote Console Plugin logs are typically found in C:\Documents and in Settings\LOGINUSER\Local Settings\Temp\vmware-LOGINUSER. The file names follow the pattern of vmware-LOGINUSER-VMWAREVMRCPID.log and vmware-VMWAREVMRCPID-mks-LOGINUSER-VMWAREREMOTEMKSPID.log. On Unix clients, the VMware Remote Console Plugin logs are typically found in /tmp/vmware-LOGINUSER. Again, the file names follow the pattern vmrc-VMWAREVMRCPID.log and VMWAREVMRCPID-mks VMWAREREMOTEMKSPID.log.
  • Do the Console Proxy logs tell you anything? The Console Proxy logs al its activity in the same way as the rest of the vCD server. Its logs therefore can be found in <vCD dir>/logs/vcloud-container-info.log and vcloud-container-debug.log.

11. Tools

The following python script can be used to get a Virtual Machine (VM) console through the VMware Remote Console Proxy. The script expects curl and vmware-vmrc to be in your path. This script has currently been tested on Linux and Windows. The latest version of the script, version 1.0.2 is able to work on windows by using python and curl compiled for windows. In addition to this on Windows we have tested both with and without the cygwin shell. If you get the following when you try and run Vmrc-mks.py as follows:

$ python Vmrc-mks.py 
Traceback (most recent call last):
  File "Vmrc-mks.py", line 13, in <module>
    import argparse
ImportError: No module named argparse

This is because this script requires Python 2.6 or later and the argparse package, which is not always installed with the default distribution. This can be found at:

The script performs the following:

 - login to vCD

 - request screen ticket

 - parse the mks://… URL and extract the host/vm moref/ticket

 - decode the URL-encoded ticket

 - pass proper arguments to vmrc

Script help:

usage: vmrc-mks.py [-h] [-v] -c CREDENTIALS [--curl CURL] [--vmrc VMRC]


Script to process and acquire the VM screen ticket from the vCloud REST API.

Positional arguments:

acquire_ticket_uri    URI to acquire ticket action:

https://<vCD Cell Host>/api/v1.0/vApp/vm-265481682/screen/action/acquireTicket

 Optional arguments:

  -h, –help            show this help message and exit

  -v, –verbose      verbose messages


                                  credentials in format user@Org:password

  –curl CURL           point to curl executable, default is "curl"

  –vmrc VMRC           point to vmrc executable, default is "vmware-vmrc"


vmrc-mks.py -c vcloud@system:vcloud


Providing the VMware Remote Console clients (VMRC) functionality in vCD allows you to access multiple vCenter and ESX/ESXi servers from a single location. This is useful, as it allows the cloud provider’s to "hide" the structure of their vCenter servers and ESX/ESXi servers where the Virtual Machine’s (VMs) are located. In addition to this, the VMware Remote Console clients are stateless and therefore provide both scalability and availability.

Getting Started with vCloud Director, VMware Remote Console Proxy and VMware Remote Console Plugin

By Michael Haines, vCloud Architect

The Remote Console Proxy allows a tenant (a vSphere Remote Console client) using VMware vCloud Director (vCD) the ability to access a vApp (VM) and open and present the console of that vApp (VM) in question.

So, why do we need to have a Remote Console Proxy at all? In the context of VMware vCloud Director, we have a product that is designed to work over the public Internet. For security reasons, we need an intermediate communication module, the Remote Console Proxy. The security aspect and benefit here for the Service Provider means that they do not have to put their vSphere infrastructure directly on the internet, and for the consumers (tenants) of such a service, they gain the ability of access through an additional security layer such as a firewall, etc.  

Here’s How it Works:

The VMware Remote Console clients (also referred to as VMRC) communicate with the vSphere servers using a custom protocol developed by VMware. However, cloud users will more than likely be behind corporate firewalls that limit the possible network communication only to selected protocols and thus custom protocols would not be allowed. To resolve this limitation, the Remote Console Proxy allows the entire Remote Console communication to be tunnelled over the HTTPS protocol. This approach uses the standard port 443 and can be passed via corporate HTTPS proxies if needed.

Below I try to answer the 11 top questions about some of the key components that you need to understand about VMware vCloud Director and the Remote Console Proxy.

1. What are the components of Console Proxy (CP)?

VMware Remote Console Plugin

The VMware Remote Console Plugin provides the scripted interface to launch the VMware Remote Console. The plugin is provided as an ActiveX control for IE and a Mozilla plugin for Firefox. The plugin launches vmware-vmrc.exe on Windows and vmware-vmrc on Unix that renders the Virtual Machines (VM) console. vCloud Director uses client-side JavaScript to call into the plugin. The VMware Remote Console Plugin also queries the proxy settings from the browser. Note: the VMware Remote Console Plugin caches browser proxy settings and hence if you make changes, you need to restart the browser for the plugin to reload the settings. The VMware vCloud Director Remote Console is vSphere 4.1 plus vCloud specific features (browser proxy support and HTTPS tunnelling for MKS traffic). VMware vCloud, allows you to open the console of a Virtual Machines (VM), only if the state of the Virtual Machines (VM) is powered off. vCD and not the VMware Remote Console enforce this behaviour.

VMware Remote Console

The VMware Remote Console can be thought of a lightweight VIM client (VIM stands for VI Management. For the VI, it could be VMware Infrastructure or Virtual Infrastructure), that is spawned by the VMware vCloud Director in this case, and which is capable of providing MKS (For virtual machines residing on a VMware ESX/ESXi server, console connections are offered through the VMware MKS ActiveX control). This control is downloaded through a secure channel when you try to view a live VMware virtual machine) and device interactions with a single remote Virtual Machine (VM) that lives on a vSphere server. As such, the Remote Console can talk to either a Virtual Machine (VM) residing directly on an ESX/ESXi server or go through the vCenter server. It also has some limited Virtual Machine (VM) management functionality for the Virtual Machine (VM) it is connected to.

Note: The Remote Console only operates on powered on Virtual Machines (VMs). This is enforced by vCD, which means that vCD does not allow you to open the console of a powered off Virtual Machine (VM). However, Remote Console does allow opening console of a powered off VM and the behaviour is to automatically power it on.

Remote Console Proxy (CP)

The Remote Console Proxy performs three distinct functions:

a) Provides a single entry point. A VMware vCloud Director installation works with a large number of vCenter servers and ESX/ESXi servers and therefore the Virtual Machines (VM) can be located on many different hosts. The vCD clients are not aware of that however – they communicate only with the Console Proxy in order to open Remote Consoles. It is the only visible entry point for Remote Console communication from the viewpoint of the vCD clients. The Console Proxy is responsible for redirecting the requests to the correct vCenter server and ESX/ESXi servers.

b) HTTPS communication. The VMware vCloud Director clients communicate with the Console Proxy only via HTTPS on port 443. This communication can be channelled through a client's HTTPS proxy as well if needed. The Console Proxy converts the incoming HTTPS communication to the protocols specific to the vCenter server and ESX/ESXi servers.

c) Security. The Console Proxy provides an additional layer of VMware vCloud Director specific security on top of the standard vCenter server security. The Console Proxy assists with the protection of customer Virtual Machines (VMs) in a multi-tenant environment. In this case it ensures that a client in one organization does not get access to the Virtual Machines (VMs) of another organization. The Console Proxy also protects the vCenter and vSphere servers from denial of service attacks. This works through the Console Proxy communicating with the vCenter and ESX/ESXi servers, but only if the connection is made by clients who have already authenticated to the VMware vCloud Director server. Other clients are denied access, and as a result the vSphere servers cannot be subjected with connections from anonymous users.

Cipher Suites

The Console Proxy accepts only FIPS-140 compliant cipher suites. These suites only use "Triple-DES (3DES)", which is the "Data encryption standard (DES)" and is a symmetric encryption standard based on a 64-bit block and "AES", which is "Advanced Encryption Standard" and is also an example of a symmetric algorithm.

The following is the specific list of supported Console Proxy cipher suites:

  • TLSv1:DHE-RSA-AES128-SHA – ENABLED – STRONG 128 bits
  • TLSv1:DES-CBC3-SHA – ENABLED – STRONG 168 bits
  • TLSv1:AES128-SHA – ENABLED – STRONG 128 bits
  • SSLv3:DHE-RSA-AES128-SHA – ENABLED – STRONG 128 bits
  • SSLv3:DES-CBC3-SHA – ENABLED – STRONG 168 bits
  • SSLv3:AES128-SHA – ENABLED – STRONG 128 bits

Note: A description of FIPS-140 can be found here:


The Remote Console Proxy logs the important events in the logs/vcloud-container-info.log (in the vCD cell). Detailed information about its operations is logged in logs/vcloud-container-debug.log (if it is enabled).

2. How does the Remote Console Proxy Work?

The Remote Console Proxy runs as a process on the VMware vCloud Director Cell and communicates to the vCenter server on port 443 and to the ESX/ESXi host on ports 902 and 903. The VMware Remote Console Plugin, which runs on the client browser, communicates with the Remote Console Proxy only on port 443. The VMware Remote Console Plugin then tunnels the MKS traffic (902/903 traffic) over HTTPS to the Console Proxy. In terms of the flow, a user creates a HTTPS session to the VMware vCloud Director Portal via a load balancer (and is authenticated etc).  Note here that the MKS traffic is already encrypted at this point, so we do not need to encrypt it again. Also, the initial handshake is SSL and the traffic after that is encrypted in a custom way. The VMware Remote Console Plugin talks only to a single address, that of the Console Proxy, or its Load Balancer. The VMware Remote Console Plugin talks to the Console Proxy, possibly through a Load Balancer only on port 443. If present, the Load Balancer directs the incoming HTTPS connections only to the Console Proxy. It is the Console Proxy's responsibility to direct the connection to the correct vCenter server or ESX/ESXi server and to convert the HTTPS connections to MKS connections on ports 902/903 if needed. 

Note that the VMware vCloud Director Remote Console Plugin detects whether the client has an HTTPS proxy (using the IE settings) and it only talks to Console Proxy through the HTTPS proxy if there is one.

As you will note from the above, there is a difference in the way that the vSphere Remote Console Proxy and the vCD Remote Console Proxy functionality works. The following basically lists the differences:

  • The vCD Remote Console Proxy plugin uses the proxy settings configured in the browser to connect to the Remote Console Proxy.
  • The Remote Console Proxy presents itself as a vCenter server and ESX/ESXi server to the vCD Remote Console Proxy.
  • The ticket used by the vCD Remote Console Proxy is augmented to figure out which real vCenter server and ESX/ESXi server it needs to communicate with.

3. How does VMware vCloud Director actually Remote Console to the ESX/ESXi Console?

The flow of operations goes as follows:

  • The VMware Remote Console Proxy logs in via the vCenter server using the clone ticket that was provided to it.
  • The VMware Remote Console Proxy acquires an MKS ticket for the Virtual Machine (VM) from the vCenter server and gets the address of the ESX/ESXi where the VM is running.

The VMware Remote Console Proxy connects to the ESX/ESXi using the MKS ticket. In ESXi this occurs in one pass only on port 902. In ESX, the VMware Remote Console Proxy first gets yet another MKS ticket on port 902 and then connects on port 903, only then does it establish a VNC-like connection that allows it to display the remote console of the Virtual Machine (VM).

4. How does the Remote Console Proxy Work without a Load Balancer?

Diagram: vCD-Console-Proxy-Architecture without a LB:


The browser interacts with the VMware vCloud Director Portal using the HTTP service and requests a console session ticket. The VMware vCloud Director Cell responds to the client with the console session ticket that includes an IP Address to connect to – in this example ( The VMware Remote Console Plugin then connects to the IP Address ( from the console session ticket. If you do not have the VMware Remote Console Plugin installed, you will be prompted to install this (please see the diagram vCD-Remote-Console-Plugin). Once the VMware Remote Console Plugin is installed on the client browser, the console session will start between the VMware Remote Console Plugin and Console Proxy.

Diagram: vCD-Remote-Console-Plugin:


5. How does the Remote Console Proxy Work with Load Balancing HTTP Traffic?

Diagram: vCD-Console-Proxy-Architecture with a LB:


In this scenario, the browser interacts with the VMware vCloud Director Portal using the HTTP service, but this time the communication is performed through the Load Balancer and again requests a console session ticket. The VMware vCloud Director Cell responds to the client with the console session ticket that includes an IP Address to connect to – in this example The VMware Remote Console Plugin then directly connects to the IP Address ( from the console session ticket. If you do not have the VMware Remote Console Plugin installed, you will be prompted to install this (please see the diagram vCD-Remote-Console-Plugin). Once the VMware Remote Console Plugin is installed on the client browser, the console session will start between the VMware Remote Console Plugin and Console Proxy. In this scenario, all HTTP traffic will be load balanced.

6. How does the Remote Console Proxy Work with the HTTP and Remote Console Proxy Load Balancer?

Diagram: vCD-Console-Proxy-Architecture with HTTP and Load Balancer:


In the above architecture, the browser interacts with the HTTP service through the load balancer and requests a console session ticket. On completion of acquiring the session ticket, the vCD cell responds with the ticket that includes the IP address to connect to, in this case either, or The VMware Remote Console Plugin then connects to the external IP of or from the ticket again. Finally, the console session then takes place between the VMware Remote Console Plugin and the console proxy through the load balancer.

In Part 2 of this post, I’ll cover resiliency of the remote console proxy, what ports are required, operations available to the user, and run through troubleshooting and tools.

When Your Data Center Has Packed Its Bags

By John Ellis, Chief vCloud Architect at BlueLock


I recently grabbed lunch with a friend of mine whose company had just moved their data center several states away.

Physical Data Center Migrations such as these are truly epic quests: one hopes that servers come off the trunk in roughly the same shape they possessed when they were placed on the truck. Once the gear is brought into the new data center you try to re-assemble all the building blocks in the same manner as the original datacenter.

Carefully and in the proper order, one powers on servers one-by-one hoping that disks haven't been jostled and all networks were reconstructed correctly. Of course the data center reconstruction didn't go entirely to plan and the poor guy spent most of his holiday trying to get his services to start up once again. Physical servers and networks can be very delicate items that require a good deal of precision to move, no matter if it is three yards or three states.

Virtual Datacenter Migrations

In October I had to perform a similar, albeit smaller, move migrating the infrastructure for our development team into our brand new datacenter. Forty servers running our collaboration environment, testing environment, quality assurance, pre-production and rapid prototyping needed to move along with the independent networks and firewalls for each. While there were many dependencies to manage between servers and a long list of LAN restrictions and security policies, I was still able to perform the entire migration within four hours. When I was ready to power everything up I didn't have to reconfigure a single application.

What made my October migration so smooth was not based on any planning or forethought at all – I had not performed much of either. The migration I managed dealt entirely with cloud-based infrastructure while my friend was dealing with bare-bones physical hardware. While he moved disks and chassis, I just moved bits and bytes.

There are several facets of vCloud Datacenter that afforded organizations greater IT agility, but the function that has saved me the most sweat and tears has been the portability between vCloud Datacenters. I can now organize all my inter-dependent servers together as virtual applications, bound by their networks and the security policies that define them.

VMware vCloud Director in Action

These vApps reside as the primary components of vCloud Director and can easily be exported in a standard Open Virtualization Format (OVF). If I ever need to move my QA environment to a new data center (or a new country) I can easily freeze-dry my virtual machines, networks, firewall rules, guest customization rules, hardware definitions and even end-user licensing agreements into a readily portable format and transfer it wherever I wish. No more loading trucks with servers, no more plugging in CAT5e cables. I now move only virtual server files to a new home whenever I feel the need. I can even move servers onto my local laptop for testing by loading the OVFs into VMware Workstation. Portability is just one requirement of agile IT. A nimble infrastructure requires rapid provisioning and flexible management. vCloud Datacenter enables this flexibility through two interfaces: the vCloud Director management console and the vCloud API.

For my next post, let's walk through an example of how much more quickly one can have new hardware running within vCloud Datacenter.

Update on Virtacore vCloud Express Beta

Matthew D. Sarrel, Sarrel Group

I’ve been playing around with the Virtacore vCloud beta for a few weeks. There isn’t all that much that I can do with it right now.  Even with the limited functionality though, it does what they say it does – which is pretty good for a beta cloud offering.

I got another email from Virtacore:

Greetings to all of our vCloud Express Beta Testers!

The last several weeks have been pretty busy behind the scenes here at Virtacore.  Thanks to feedback from our testers, we believe we've isolated a few problems encountered during testing.  Specifically we believe we've finally pin-pointed and corrected the issue that was resulting in VMs suspending after running for a week.  This fix will be applied to all new VMs created going forward and as of early Monday morning is now fixed for all existing VMs. 

In addition to fixing bugs and troubleshooting interface errors, our development team is in the process of rolling out two new features – user management and vApps (aka VM Groups). 

You can find a more detailed explanation of the features here.

And on a final note, we are extending our vCloud Express beta program through February 15, 2011.  There are a few more bugs/features we want to work through before release, so we're pleased to announce you'll continue to have access to the beta until at least February 15th. 

I did have that problem of the VM suspending on its own, but I didn’t think it was such a big deal because I’m not using it for anything anyway.  When I signed up for the beta, Virtacore suggested that I not save any data on the VM because it is beta and that they could blow it away as part of the development process.

Virtacore had also been running a competition to see who could report the most bugs.  That ended, but had I participated I could’ve won a $50 Amazon gift certificate. It’s an interesting enticement to get people to test and report findings.

I’m getting more and more eager to get out of beta and get some real systems running up there.

Update: Virtacore also recently rolled out the ability to build a vApp.

A vApp is basically a group of virtual machines with applications and operating systems running on top of them, stored with the information needed to launch and operate them. I think of vApps the same way that I thought about “teams” in VMware Workstation.  Many organizations have moved beyond thinking about VMs and now think in terms of vApps in order to simplify complex multi-server environments.


Creating a vApp is about as easy as creating a VM:


And then the vApp can essentially be managed as a “Server Group”


Stay tuned for more updates as Virtacore's vCloud offering continues to evolve.

Matthew D. Sarrel (or Matt Sarrel) is executive director of Sarrel Group, a technology product testing, editorial services, and technical marketing consulting company.  He also holds editorial positions at pcmag.com, eweek, GigaOM, and Allbusiness.com, and blogs at TopTechDog.

VMware Partner Exchange 2011 – Get Ready!

By David Davis

One of my favorite yearly events (besides VMworld) is VMware Partner Exchange (PEX). Much more intimate and more "top secret" than VMworld, the partner-only event offers unique advantages.

Who Attends VMware Partner Exchange?

PEX doesn't have as many attendees as VMworld and I’ve found it to be lower stress and a more concentrated dosage of VMware Kool-Aid than its larger cousin.

First, VMware Partner Exchange is only open to VMware partners. Large partners like EMC, Cisco, Dell, VCE, NetApp, and HP have their own training days before PEX begins (called "pre-conference boot-camps). Many sessions and keynotes revolve around becoming the most successful (and profitable) VMware partner you can be.

If you are a VMware partner then there is no doubt that you need to be in Orlando, Florida between February 8-11.

If you aren't a VMware partner but you or your company sells, supports, integrates, develops related software, or manufactures related hardware then you need to, first, become a partner and then make sure you attend this invaluable event. There is even an option to become a free VMware partner called a Technology Alliance Partner (TAP).

Finally, if you are a VMware customer then continue to learn more about PEX, and ask your local VMware partner about PEX when they return. Also, make sure you have VMworld 2011 in Las Vegas on your calendar for August 29-September 1, 2011 because that is the event for you.

Five Reasons to Attend VMware Partner Exchange

If your company is or can be a VMware partner then here are five reasons why you need to attend PEX:

1. Learn how to make your company more successful - you'll find keynotes and sessions that educate, empower, and motivate you to be the best partner you can be (more on sessions below).

2. Gain the training on new technology that you must have to be successful – prior to the conference you'll find VMware training boot-camps that cover vSphere Design, View 4.5 Design Best Practices, and desktop virtualization. Additionally, you'll be able to perform VMware labs to gain the hands-on experience you'll need to implement VMware's products quicker and easier.

3. Network with the best in the virtualization world - VMware company executives like Paul Maritz, & Steve Herrod will be there as well as well known names in the virtualization world like John Arrasjid (VCDX001), Duncan Epping (VCDX007), and John Troyer (VMware Social Media Evangelist).

4. Get certified - VMware will be offering a free certification training boot-camp on the VMware Technical Sales Professional (VTSP) and there are special sessions on VCP and VCDX. Last year, I paid $150 extra to attend John Arrasjid's VCDX preparation workshop (which is available this year as well). Plus, you can attempt your VCP, VCAP-DCA, or VCAP-DCD certification exam, onsite at PEX. Learn more about certifications at PEX here.

5. Go to Disneyworld - Okay, don't tell your boss about this one but PEX is inside the Disneyworld campus and if you have an extra $80 you could go to one of the parks before or after the conference. (Remember – it's the happiest place on earth.)

Must See PEX Sessions

I've already built my schedule for PEX and you'll see it below. While I have booked every session that I possibly can, there are some speakers and sessions that I consider "must see". They are:

  • John Arrasjid – covering vCloud BC/DR solutions (TECH-BC-202) & vCloud Architecture Design Workshop(TECH-CLD-201),
  • David Hill – Private vCloud Architecture Technical Deepdive (TECH-CLD-300)
  • John Troyer – Social Media Optimization for Marketing (SAL-MKT-200)
  • Brenton Badger – Tier 1 Applications in VMware vCloud Director (TECH-CLD-203)
  • Pang Chen - VMware vCloud and vCloud Director 101 (TECH-CLD-101)
  • Thomas Christensen - Don't be afraid of the Cloud (SAL-CLD-100)
  • Ryan Sweet - vCloud APIs bringing new integration partner opportunities (TEX-CLD-204)
  • And many more vCloud-related sessions.


The public content catalog for PEX 2011 is located here.

See you there!

I'll be staying at the Disney Coronado hotel for PEX from February 7-11. For anyone reading this who is attending – I would be glad to meet you there. I'll be attending as much training and as many sessions I can but I also plan to make time to do some labs and network with as many people as I can. Additionally, I'll be blogging and doing video interviews. If you are at PEX and would like to meet or do an interview, let me know via Twitter (@davidmdavis). Look for more upcoming posts on VMware PEX 2011!

Learn more and register for VMware Partner Exchange 2011 here.