Posts

Moving Clustered VMs with Shared Physical Mode RDMs

This is probably one of those articles that's only going to apply to a tiny percentage of people within an already miniscule niche subset of a small population... but I'm proud of my work and so am going to post it here anyway.  One of my customers needs to move a bunch of VMs off of one SAN onto another.  Storage vMotion for the win, end of story, right?  Yes*

* 99% of the problem is absolutely solved with Storage vMotion, but I'm not in the business of leaving 1% unfinished.  In this case, that 1% was a bunch of older SQL Servers, set up in 2 node pairs using Microsoft Clustering Services via shared Physical Mode RDMs.  Yikes.

In theory, this process isn't too bad.  Just record the vital statistics about the RDMs, then detach them from the VMs, move the VMs (during an outage window, obviously), create new RDMs using the recorded data, and power everything back up.  This process depends on the new-harddisk cmdlet... but given that I'm writing about it here, you…

How to use SSH and SCP with VCSA

I was replacing some vCenter Server Appliance (VCSA) self-signed certificates with signed certs from an Active Directory Certificate Authority and I came across a minor issue that I wanted to document here.  I was using the /usr/lib/vmware-vmca/bin/certificate-manager tool to generate the CSR, and then PSCP to download the CSR and hand it off to the security team.

When I first tried to use pscp to get the file, I encountered an error that I hadn't seen before:

Fatal: Received unexpected end-of-file from server

Some quick googling didn't turn up any hits on this issue, but I thought of something as I was poking around.  When I connected to the VCSA via SSH, it didn't drop me to a BASH shell until I did the usual "shell.set --enabled True" "shell" operation that it prompts you with.  Since PSCP (and SCP in general) is just establishing an SSH connection to the host and then doing a copy command, I figured that my issue was probably that the default root s…

Parsing Palo Alto Config XML into PowerShell Objects

One of my customers is converting into an NSX-based network design.  In order to facilitate this conversion, they need to understand the rules that exist on their Palo Alto firewall and then recreate those desired behaviors in the NSX microsegmentation.  Their challenge was that their Palo Alto had a fairly complex ruleset, one that no one wanted to try and recreate by hand in NSX.  I'm sure that you can see where this is going.

Before we could create anything in NSX (via the ever-evolving PowerNSX module), we had to understand the configuration of the existing firewall.  When I asked about exporting the configuration, the networking team told me that they had two options: JSON or XML.  Not knowing what I was likely to get working, I asked for them both, then tried convertfrom-JSON and import-clixml on the provided files.  Neither worked, so I had to do some digging.

After banging my head into a wall for a while, one of my coworkers gave me a copy of a script that he got from Palo…

PowerCLI's RunAsync Parameter Rocks!

I've recently been playing around with the -RunAsync parameter in some of my PowerCLI scripts, and I'm super impressed!  I'm also super late to the party; I mean, LucD was writing about it back in 2010, but still!  So, what's it do?  It speeds up tasks that don't need to be run sequentially, that's what it does.

For example, if I have a list of VMs that all need to move into a new folder, I could do it like this:

$folder = get-folder "New Folder" $vmNames = get-content MyList.txt foreach ($vmname in $vmNames){ get-vm $vmname | move-vm -destination $folder }
And that would move one VM, then the next, then the next, etc.  Depending on the number of VMs, it could take a real long time.  This process could take a while because, the way this script is written, the system will wait for each "move" to complete before initiating the next.  That's where -RunAsync comes in.

$folder = get-folder "New Folder" $vmNames = get-content MyLi…

Testing Many Suspected Root Passwords on Many vCenter Appliances

One of my customers ran into a situation where they had lost track of the root passwords for their vCenter and Platform Services Controller appliances.  As they logged into devices with expired passwords, they changed them, but they had lost track of which devices had had their passwords changed and which password each device was using.  Since there was a decent sized list of potential passwords and quite a few devices, I decided that we'd all be better served by writing a script to test them for us, rather than trying them all by hand.  Aside from the boredom that would come from running the tests by hand, I was concerned about human error introducing false negatives to our results.

Well, such a script is pretty trivial - I can just make an array of server names and an array of potential passwords, then nest a foreach inside of another foreach to try each password against each server.  And that's true, but then I got to thinking about security.  I really didn't want to ty…

Truth in PowerShell

PowerShell does a lot of hand holding for you, which generally makes using it really easy.  For example, the concept of "true" is very important when building logical structures in a script, and PowerShell does its best to help you out.  And it generally does a good job, but there are some details that you should probably be aware of.  The below are all true statements:
"true" -eq $TRUE"false" -eq $FALSE"false" -ne $TRUEif("true"){$TRUE}if("false"){$TRUE} So, what's happening with that last one, if we know that "false" does not -eq $TRUE?  Well, -eq is your buddy, and when you ask it if a string that reads "true" is equal to the boolean $TRUE condition, it says, "sure!".  Same thing, when you ask it if a string that reads "false" is a boolean $FALSE, it knows what you're asking and will tell you that it is indeed $FALSE.  It reads your string and figures that, if you're askin…

Transporting Custom VM Fields Between vCenter Servers

One of my customers recently migrated a bunch of VMs between two vCenter servers.  When they finished, they realized that none of their VMs' custom attributes followed the VMs into the new vCenter environment; apparently those attributes are owned by the vCenter server, rather than stored in the VMX file.  Fortunately, they had an export of their VM inventory that included those custom fields, but they had no idea how to repopulate that data across their horde of VMs.

You can see where this is going... and, as expected, I helped them put together a quick PowerCLI script that would set things straight.  This script takes 2 parameters as input: a CSV file that contains the data from the VM inventory (including each VM Name and columns for each of the custom attributes), and an array of which custom attributes need to be set (since that inventory export file is probably going to contain a lot of columns that aren't custom attributes).

Once it's executed, the script goes throu…