Connecting a USB device to an ESXi 5.0 VM

This is something we have been asking for years and it was only available up until now in VMware View. We can finally connect a USB device to a VM running on ESXi. No additional licensing required!!!!!

From the What's New in vSphere 5.0

What's New

Could it be that simple? Well actually yes it is.

This is my host (in this case the free vSphere Hypervisor)


Here you have a VM Virtual Hardware version 8 (I was not able to test with Version 7 so if you would like to try and add a comment here - that would be great!!)

VM details

Add a USB Controller to the VM

Add Hardware

You can choose either USB 2.0 or USB 3.0

USB 2.0USB 3.0

And here is the VM Configuration after the addition.

VM Config

After adding the USB controller to the VM, these parameters are added to the VM's configuration (.vmx) file.


After the machine has come up it now has a USB controller in its device manager.

Device Manager

In the vSphere Client I can now attach USB devices that are connected to the my computer to the VM running on this ESX host.

connect USB

When I connect the USB device to the VM I get this warning - which is similar to the one you get when doing the same with Workstation


Once connected to the VM - it shows up in the Device manager and in this case also as a local drive.

New Disk

New Disk2

And of course the details are updated in the .vmx itself


This opens up a whole new world of connecting peripheral devices to the VM. I do wonder though what it will mean to all of the companies that have created solutions that were able to solve these issues until now with a USB-over-IP solution. (Digi)

It would be interesting to hear what kind of use you could make of this new feature in your environment. Feel free to drop a comment below.


netstat for ESXi

The title of the post is actually misleading - on purpose - because there is no netstat for ESXi. The reason that I bring this up today is because of a Twitter conversation from today regarding SSH access and VMkernel interfaces. I was looking to see which ports were open and what interfaces were listening.
But that is a different post.

What is netstat? according to Wikipedia:

netstat (network statistics) is a command-line tool that displays network connections (both incoming and outgoing), routing tables, and a number of network interface statistics. It is available on Unix, Unix-like, and Windows NT-based operating systems.

Why would you use it? For one thing for example, to check if a host has an open connection on a certain port, if it is listening on a certain port - for troubleshooting purposes would be the proper answer.

So how do you get that information on ESXi?

Trying netstat on an ESXi host does not work - because that command is not there - see the screenshot below.

No netstat

Well that is not good - if the command is not in the busybox console then how would you go about getting that information? Well of course the clever people at VMware have already thought about this and have exposed all this information through esxcli. William Lam wrote a great set of posts on esxcli
esxcli Part1 - What is esxcli?, esxcli Part2 - Automating esxcli using vMA and esxcli Part3 - Automating esxcli using PowerShell

This is how you would go about getting the information from esxcli. (Be aware the command differ according to the different versions - 4.x is not the same as 5.x)

esxcli network ip connection list


That is fine and dandy - but to get that info you need to either:

  1. have access to the DCUI (and have it enabled of course)
  2. access remotely with SSH (and also have it enabled of course)

But what if you do not want to enable neither of the above - that means you have to do it remotelyand for that you have two options, vCLI or PowerCLI.

The vCLI way

esxcli --server esx1.maishsk.local network ip connection list


But me being more of PowerCLI guy I would do it like this.

The PowerCLI way

$esxcli = get-esxcli -vmhost esx1.maishsk.local

$esxcli.network.ip.connection.list() | ft


Output is almost identical - just that in the case of PowerCLI the values are returned as a set of objects - a  VMware.VimAutomation.ViCore.Impl.V1.EsxCli.EsxCliObjectImpl object to be precise. Once these presented as objects I can start to mold and dice my results to my liking.

For example - I would like to check if there is any connections open on port 80 (http) - with vCli - this is not so simple - because you are working essentially in a DOS window - so filtering is not the easiest with findstr. Using the console or SSH is easier - a simple grep will work as you can see below.

esxcli network ip connection list | grep :80


With PowerCLI

$esxcli.network.ip.connection.list() | where { $_.LocalAddress -like "*:80" } | ft


I hope you can see that the options this way are pretty much endless - like filtering all connections to show only those from a specific IP, or a complete subnet.

So that is how you netstat on ESXi….


VCP 5 Beta Exam - a Pass - but it aint easy

I received an email today

September 7, 2011

Dear VMware Beta Candidate

Congratulations!  You have passed the new VMware Certified Professional on vSphere 5 (VCP5)

certification exam. Thank you for your participation in the beta exam.  Your input and participation were invaluable to this process.

We will be adding this certification to your transcript within the next three weeks.  You will receive an email notification with additional instructions once your education transcript has been updated.  Physical certificates will be sent after your shipping address has been confirmed.  Please contact certification@vmware.com if you do not receive your notification.  Please include your Candidate ID from your exam score report.

Thank you for participating in the VMware Certified Professional on vSphere 5 (VCP5) beta exam and congratulations once again on becoming one of the first VCP5s!

I think this is the last time I will take a Beta exam. It is a lengthy and not trivial process.

Let me run you through the flow of a Beta Exam.

  1. Beta is announced.
  2. Hope you know someone - that will get you in on the Beta of that product.
  3. Play with the product on your lab.
  4. Close enough to GA of the product - depending on the case a beta Exam will be come available.
  5. Pray there is an available slot in the tight timeframe that the beta is open - usually 7-10 days.
  6. Book the Exam - almost always it costs money (less than a regular exam)
  7. Look over the blueprint - and rely on your experience and knowledge of the product, because there is no-one who can help you out here. You are on your own.
  8. And this is the worst - sit for about 4 hours - going over 100-200 questions, some of them are so whacky - some are intentionally wrong and some plain stupid. This is the worst part of the whole process. Sitting for that amount of time is not an tedious and exhausting experience.
  9. And then wait - 6-8 weeks after that - to see if you passed or not. Usually people that have taken the live exam after launch get their results before you do.

I do feel that participating in a Beta Exam is something that is beneficial to the candidate in a way - you are actually saving money. But this should also be perceived as a service to the community - because you are acting as a "guinea pig" for VMware to help refine the exam when it goes live and offered to the masses.

I said after this one - I will not do any more beta exams, it takes too much energy - but getting a pass mark - it always gives the extra boost. Let's just say - I will decide next time it comes up what I will do.


Congratulations to all those who passed the Exam!!


VMworld Labs - Addendum

As always the VMworld labs are always a hit. Everyone wants to try out the new technology, see the new stuff, and get a hands on feeling with the latest and greatest. To add to my HoL post from VMworld, the Fast Pass was gone within a very short time, so my apologies about that one.

Borrowing from Duncan Epping's post VMworld Labs 2011.

2011 Labs Prelude

The labs were (as they always are) impressive, two monitors at each seat, with a thin client. A great user experience, albeit a bit sluggish at times. The aquarium was nice touch and a good visual aid as to what was was being deployed during the show. By the way - the racing car dashboard from last year - beats the pants off the aquarium. Just sayin..

One of the sessions I attended was LAS4000 VMworld Labs Hardware Architecture. Here I learned several things some I found surprising, and others not. The not first.

  1. The entire infrastructure was running in the cloud. Why was this not surprising - because - Cloud is what VMware is selling, it is their vision. It is what they are betting their chips on. So they have to (and rightfully should) present solutions using this technology.

I was surprised to hear..

  1. The entire Lab Environment  was running on NFS. Not FC, not FCoE, only NFS. That is change from previous years. If my memory serves e well, last year is was mostly FC and a small amount of NFS storage.
  2. EMC was not the only player for the underlying spindles. Nexenta (a much smaller company) was used to power a good amount of the storage used for the labs. I was originally led to believe that it was only Nexenta storage, but that turned out to not be entirely accurate.

A few closing comments regarding the organization.

  1. Extending the labs to provide options to test also the partner integration is a great addition - just it should be kept to a minimum (like it was). 
  2. Waiting in line for 45 minutes to get a lab seat is not good. Not for those who want to take the labs. That time spent in line is wasted - it could have been spent on the floor, or in a session. There has to be a better way of doing this. Perhaps pre-register for labs (like sessions), but also allow for walk-by's as well. Those who have pre-registered will get quicker access. That way those who really want to do the labs, and close off time on their schedule and are there on time - do not have to spend an hour in line.
  3. The real world scenarios - were perfect!!! Whoever had that idea - brilliant!! Well done!
  4. Looking at the number above from Duncan's post I noticed something which troubled me. On his post VMworld Labs wrapup 2011 – Las Vegas2011 Wrapup 
    I noticed that the number of Labs was less than last year and the number of VM's was only slightly higher, despite the fact that there were more hours, an increase of 2% despite the increase of 13% more lab hours. Again a record was broken, but not by much.


But what really troubles me is the huge difference in goal vs actual. 148,000 vs. 225,000, that is a really big miss. It would be nice to hear what actually was the reason for not achieving the pre-defined goal. Was it performance? Was it architecture? Was it logistics? Was it over-zealous goals?

I do want to stress again. The labs are amazing - the technology behind it is amazing. The option of trying something hands-on is wonderful - and for some it is the main reason to come to VMworld. If the post-mortem analysis could be shared - I am sure that this is something we would all benefit from. This is not to criticize any of the the VMware Integration Team in any way. So if someone could share more details on why the big differences, I would be grateful.