There have always been a severe lack of port querying tools with ESXi until nc was added to the builds and now it looks like the VCSA finally gets something along the same lines. This utility is somewhat limited to what you can and cannot do but it helps when you are in a pinch.

This script is called and is located in

So if we run the python script we will observe the following:

So if I want to issue a test to say one of my hosts to make sure that we can communicate over 902 I would issue the following :

If we are using tcpdump at the same time we can see the rrequest and then we can see the response

If we try it on a port that we know isn’t open on the host we get the following

The command will sit there and hang and while tcpdumping the interface we observe constant retries but the script will not terminate until there is a total of 6 failures

Here is what is returned after the failure

I do know for a fact that the ESXi host has port 80 open so I want to try to see what a HTTP return is when I set the flag for it.

Verdict: It’s not perfect but I think that it is a great start. I would love if they could include nc on the VCSA but I am sure that they have their reasons. My main complaint is that you can’t specify the protocol that you can use when sending the traffic.


I have been looking at further ways to automate alot of the work that we do within our testing environment at work. This is mainly due to the fact that I want to keep our testing set in a standardized format, while removing the dependency on a SME resource to monitor the tests / set them up.

A majority of the time we end up using full clones for all testing due to the fact that we want to test de-dupe along with performance. This means that all scripts that I will post moving forward will reference that model.

Upon further reading I found out that View PowerCLI is different from traditional PowerCLI since it can only be executed locally on the connection server opposed to remotely.

First thing we need to do is figure out a standard script that will serve multiple purposes. Here is the one that I use.

This script does the following:

  • Loads the View PowerCLI snapin
  • Asks you what you want the PoolID to be
  • Asks you what you want the Pool Display Name to be
  • Asks you what cluster you would like the VMs to be placed in
  • Asks you how many desktops you want to create

For this to work in your environment then there are going to be a few things that you need to change

Lab is the name of the Datacenter which has a hidden sub folder of vm. This is going to be the same in all environments. The sub folder is then Testing and that is where I am dumping these desktops. Here is how you would have to change it if the folder structure was as follows


The same goes for the portion of the script where we are defining where the resource pools are

There are 2 folders in this line that aren’t visible but actually exist and it’s host and Resources

The variable $CObject is the name of the cluster where you want to put the VMs SO you really only need to change these lines if you are throwing the VMs in a resource pool below the cluster object

Template path is pretty straight forward. This is just the folder structure that is below the datacenter object and this too has a hidden folder of vm after the object.

Datastore paths are somewhat interesting . I have a standard naming convention of VDI_LUNID for all of my desktops BUT it might be different for your environment depending on how you do it. These datastores have to be present in the cluster object where you are putting the desktops

In the example above I only show one datastore but you can specify multiples by just doing the following

I haven’t really tested how well it works but it shouldn’t be any different than specifying multiple datastores within the pool settings.

Since we found that the script works with what I pasted above we should enable the Connection Server to accept remote Powershell tasks from other domain machines.

Open a Powershell administrative window and run the following

So now that, that works we could just save the script at the root of C:\ as FULL.ps1 since the next script that I will be referencing is a launcher menu that executes it based on the name and location.

Now here is the current menu that I am using that is based all in Powershell that I found somewhere online. If this is yours or you know who made it please let me know so I can give you credit.

So we can see that this when executed will prompt us for VMware View or Citrix.


This top level menu is based off of these lines here

When Selecting VMware View you will get the following sub menu


This sub menu is based off of this code here

I will select Create a pool which brings me here


This is based off of this section here

So since I only have the option for Full Clone it will call the function named FULL this function is really what is going to authenticate against the CS and run the script. I should mention that this user that you are specifying in the invoke-command task needs to be an administrative user in the View Admin UI. If the user isn’t then you will get a Not Authorized generic error that will just piss you off as much as it did me.

Here is the function as above in the script

This is literally the only way I have found this to actually work. If you don’t have a pre-defined testing set that you are using I believe that you can actually specify your commands directly within the { } of the script block but it would be interesting since you would have to load the snapin prior to the execution on the destination.

The one thing that I need to do is have it actually provide somewhat of feedback when it creates the desktops by doing some form of Get from the CS but I am still learning this.  This entire thing isn’t done but I have seen people talking about it lately so I just wanted to provide something that I would have found helpful as I was sifting through documentation attempting to figure this out on my own.  If you have any ways that you think that this could be done better let me know! You can always contact me on twitter @kalenarndt and I will adjust it accordingly. I always love to see how things can be done more efficiently.

This week it has been my goal to learn vCAC and during this time I have been running into old remnants of past labs that have been causing me problems. I was finally getting around to installing my IaaS VM and I kept having the VM BSOD during the install and instantly my host would PSOD. Since I don’t have a KVM I had to just hard power it and wait for it to come back up.

Checking in /var/core I find the following


Well that isn’t great but atleast we have a core and with a core we can find out what happened (usually). So after talking to my cousin Dillon I found out there was a tool that we can use

esxcfg-dumppart -L dumpname

This will output the results in the current working directory where you run the command. In my case it was in /var/core


If we look at the log we can see the following


After doing a bit of  talking to Dillon and Googling we can find this which turns out is a known issue and the only fix is to upgrade.

Turns out I haven’t updated this host in a while.


Since I am currently only running 1 host in this environment I am using the script from with the new package number for 5.5 U2

esxcli software profile update -d -p ESXi-5.5.0-20140902001-standard

Lesson learned….keep my lab hosts up to date before I start new side project goodness.


I have to change storage settings all the time and I have gotten extremely tired of this and since I don’t know PowerCLI yet why not do shell scripts? These do have lines that assume you are using UCS and I haven’t put any logic in them to actually find out if you are or aren’t. These are based off of the array vendor’s best practice guides that I was given.

What I do is upload these scripts to a datastore and use clusterssh to execute them on all of the ESXi hosts. Reboot for all settings to take effect.

Copy the scripts below and paste it into notepad and save it as a .sh file or download them at the bottom.

Continue reading

There are very few times that you will ever need to do this but when you do, you will have the information that you need. I frequently use this when testing HA during a greenfield implementation.  I do this prior to removing a blade so I can test software failure prior to physical failure. Another instance of you having to do this is if you are having to work with VMware support and they need to get some full cores to see if there is a driver / software issue. Either way it’s pretty fun so let’s do it!

SSH to your host


Warning: If you type the following command and hit enter on a host it will cause it to panic. Use caution when doing this.

Type: vsish -e set /reliability/crashMe/Panic 1

Crash Me


After doing so you will see the following screen on the host



After this you can gather a VM support or wait and watch HA fail the VMs over if it is enabled for this cluster. This will allow you to test a failure without pulling any hardware.

So this is one thing that I saw when I was messing around that really made me wish I knew this sooner. Basically you can access the DCUI via SSH through your client of choice as long as the process is running.

First off let’s SSH to the host



Now let’s type DCUI



Go ahead and hit enter and you will get the following


dcui in it


So now you can go ahead and hit F2 and login and start changing settings or shut the box down. To get out of this window go ahead and hit CTRL + C and you will be back to the command line.