Virtually Jason

Here's a quick one-liner that I've been particularly pleased by.  I put this together when I was reconfiguring several c7000 chassis at a time and wanted to minimize the amount of typing that I was doing per host.  This is a big ugly one liner, but what it does is to create a new VMK interface on the specified Port Group, assign it a valid IP Address and enable vMotion for that interface.  The command performs those tasks on all ESXi hosts in the "unconfigured" folder. How does it get the valid IP Address?  Well, it takes the first 2 octets of the host's management IP address, uses a customized 3rd octet, then appends the last octet from the host's management IP address.  So, for example, if the host is managed at 192.168.1.101, the script will use 192.168.#.101 for the vMotion interface. In this example, it uses a port group called "vMotion" on a VDSwitch that ends with Intranet, and has a standard /24 network with 2 in the third octet for vMoti...

So, I post a lot of scripts here, and I'm sure that you can see the progress that I've made as I've learnt more and more about PowerCLI, PowerShell and scripting in general.  One of the things that I've recently been considering is how to make my scripts run faster.  I've got some scripts that are designed to make lots of changes, like changing the Port Group assignment of every VM in an environment.  And they take a long time to run.  As in, depending on the size of the environment, several hours.  But, they don't necessarily have to take so long to run... I just wasn't clever enough when I wrote them. There are two major techniques that I'm trying to learn that would seriously speed up those scripts.  The first one is parallel execution of For Each loops... I'm still learning about that one, so will write more about it once I've learnt something worth sharing.  The other though, is much easier, and can generally be worked into any script with...

One of my customers recently experienced a strange issue.  One of their ESXi hosts had entered a problem state where Storage vMotion and vMotion were failing for all VMs on the host (vMotion was failing at 13%, which is an interesting spot).  We initially noticed the issue when Storage vMotion repeatedly threw an error for one of their VMs: A general system error occurred: Failed to create journal file provider: Failed to open "/var/log/vmware/journal/..." for write: There is no space left on the device. Well, that error seemed self explanatory.  I connected to the host's CLI (SSH was already enabled, which made that easier) and did a "vdf -h" to look at its file system.  I was surprised to find that none of the partitions were full, so I dug deeper. I decided to take a look at the vmkwarning log file, which is frequently a gold mine when troubleshooting ESXi host issues.  So, I did a quick "tail /var/log/vmkwarning.log" and, lo and  behold, we h...

Towards the start of the year, I made a post about my vCenter to vCenter migration process , which can be used to update from vCenter 5.5 to vCenter 6 (or for that matter, to downgrade, or whatever).  Since then, I've done a lot of these migrations and the scripts/procedure have matured.   Jeff and I have fixed many bugs, but the reason that I'm posting about this (again) is that I recently added a new feature and have polished our migration process. The latest versions of the migration scripts (the ones that get the settings from the source vCenter and then recreate those settings on the destination vCenter) now support DRS Rules!  The native support for DRS Rule manipulation through PowerCLI is a bit lacking... but fortunately, the community has solved that problem!   Matt Boren and Luc Dekens have created a module called DRSRule that is built to help with the reading and manipulation of DRS Rules (pretty self explanatory, right?).  I took advantage of t...

One of my customers uses DRS groups heavily.  The environment contains a set of specialized ESXi servers for a specific subset of machines and a set of general ESXi servers for everything else.  However, in order to maximize availability, all of these ESXi servers are part of one big cluster.  That means that every VM in their environment must be a member of at least one DRS group, placing the VM on either these specialized ESXi servers or the general ESXi servers.  Until we get an automated solution in place (probably through Orchestrator), we need to depend on the administrators to place the VM in the correct group (almost always the general group) upon machine creation.  As you might expect, that's not going too well. So, I put together a quick PowerCLI script to detect any VMs that are not grouped and (optionally) place them into the specified group.  This is what I came up with! The script is easy to use, but it requires a non-standard PowerCLI mod...

Last year, I wrote a post with a quick one-liner about how to ping all VMs on a given ESXi host .  Since then, I've been doing a lot of work with vSphere 6 upgrades, which has involved migrating many VMs between various switches.  As part of that process, I like to have an established basic test that I can run before and after the migration, so that I can record that the migration was successful. So, needless to say, I've expanded on that old one-liner a little bit... and now it's a full blown script.  I've built this script based around my migration validation use case, and so it has some very specific behaviors based around that.  It accepts four parameters, but really only two of them are required: -vmHost and -results.  As you certainly expect, -vmHost is the name of the host on which you want to ping all VMs and -results is a path to a file where the script will store its results (I just use a .txt file, myself). When the script is executed for the firs...

I often find myself working with CSV files when I'm writing PowerShell or PowerCLI scripts.  Of course, PowerShell has the native Import-CSV cmdlet , which works well... but it doesn't have much error checking.  After writing a bunch of script specific error checking, I've finally broken down and put together a function to do it for me.  Now, I can either add this function to my PowerShell profile, or just include it in any scripts that need it. The function is called Import-ValidCSV.  It basically just calls the normal Import-CSV cmdlet, but accepts a second arguement: -RequiredColumns.  The -ReqiredColumns argument is set up to accept an array of strings, listing all of the column headers that are required (duh!).  The function iterates through the list of RequiredColumns and checks that each column exists in the supplied CSV file.  If a column does not exist, it throws an error and quits.  If all columns exist (really, just if it doesn't thro...