Using PowerVRNI to Register Applications

One of my customers wants to use VRNI to better understand their environment.  They've been fairly disciplined about putting VMs into folders based on the application that the VM serves.  Unfortunately, they've been a little too good about putting the VMs in folders, as each application is broken up into several subfolders.  This causes a bit of a problem when we want to use VRNI to analyze an application's traffic, as the query flows where folder like *application* certainly works based on the VM folder... but it only looks at the immediate folder for the VM, rather than the whole path.  Since we had everything broken up into subfolders, that query doesn't do us much good here.

So, I put together a quick script that can scrape a vCenter inventory to register VRNI applications for each folder that it finds.  Those applications are named based on the absolute path of the VM folder, so that you can run queries like flows where application like *application* to find all network flows for a given application.  I originally wanted to have the script register an application for each parent folder with child folders becoming tiers, but the VRNI API has a hard limit of 6 tiers (that limit doesn't seem to exist in the GUI) per Application, and some of the larger applications here had significantly more than 6 subfolders.  So, I ended up creating one application per subfolder, but I made sure that the application was named for the absolute VM folder path.  Here's what I came up with.

This script loads up the vCenter inventory as a PSDrive and gets all of the VMs that way, rather than by the standard get-vm cmdlet.  This method is actually a lot slower, but it has one key advantage: the psparentpath property.  Unlike the VM Object's .folder property, the .psparentpath property shows the absolute path for the VM, making it easy for my flows where application like *application* VRNI query to work.  I ended up prepending the application names with vc_ (to show that they came from a vCenter object), just to make sure that I didn't stomp on anything that was pre-existing.

The script is pretty easy to use.  You just need to have a PowerShell session with the VMware.PowerCLI and PowerVRNI modules loaded and active sessions on both vCenter and vRNI.  Then, just run the script and specify whatever VM folder name you're interested in.  The script will then scrape the vCenter inventory for any VM that contains the name that you typed anywhere in its absolute path, then will generate vRNI applications based on those paths and register the VMs in the appropriate applications.


Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more