So after being introduced to App Volumes at PEX I thought it was absolutely amazing. I was finally released from the Thinapp hell that I was oh so accustomed to on a regular basis. After talking to each of the people in the panel I started to think of some things that should be implemented in the product that aren’t.

First off we need to understand the actual underlying framework for the product. App Volumes are client server based from everything that I have seen. You have to install the agent within the guest OS that you are either creating the App Stack on or provisioning the App Stack to and that agent checks in to the App Volumes Manager. Pretty simple right? This is what the overall architecture is from an extremely high level.

Applications are either provisioned to machine accounts or user accounts so application assignments or streaming really isn’t an issue with floating desktops. I think this is awesome except that there is just a vmdk attached to the VM in question when it is either powered on or the user logs in. This vmdk contains all of the applications that you installed during the provisioning process.

So let’s walk through what happens when we provision applications to an AppStack.

Continue reading

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.


Digging through the appliance I found a large amount of python and shell scripts that have little to no documentation. So alot of my time has been spent executing them manually and actually checking out syntax and how the scripts were created.

I stumbled upon this directory

In that directory there are several tools that I will touch on in later posts but for right now we are going to check out

If you execute this script you will see something like the following


Based on everything that I have seen within the actual script it looks like it lists all of the underlying threads for the VCDB and what the total amount of IO / status is. This will come in handy when troubleshooting underlying vPostgres issues in the future. There is a severe lack of documentation for this utility but I do like the fact that I can see the total amount of transactions per secondand  the total amounts of reads / writes. I am just happy that we have additional insight into the built in database.

According to the script there is a help option when issuing a -h which gives you the following

I don’t believe that this is like standard batch mode like we have seen before with esxtop and vimtop. The idle command is actually kind of nice since it cleans up from what we saw previously to this below


the –batch option apparently just gives you a snapshot instead of having the option to output the stats to. Not sure if this is working as intended but my guess would be that this will change in a later release to align better with vimtop / esxtop.

Is this supported? Probably not so do what you want, I’m not your dad.

So it appears the fancy shell we got in 6.0 is not bash since it’s some kind of beautiful candy wrapper for API troubleshooting. I haven’t particularly messed with it very much. I have been digging around in the pi shell and I found that the files that I would like to pull aren’t able to be downloaded.

Here is what I am getting via WinSCP

Error skipping startup message. Your shell is probably incompatible with the application (BASH is recommended)

this will still happen even if you set the shell manually via the advanced settings to /bin/bash

SSH to the VCSA and run pi shell

If we do the following env command we will see the following:

Well that gives us alot of information BUT I am paying specific attention to this entry

This is what is causing us to have that super awesome wrapper when we login that we usually bypass. Let’s change it to actual bash for root

Sweet! Let’s log out and log back in via Putty.



Open WinSCP and make sure you have /bin/bash set as the shell under advanced