Scripting SolarWinds VMan Deployment

Virtualization Manager 7 has just been released – Analyze the Past, Fix the Present, Prepare for the Future

It’s pretty epic with some great new features, but I’m going to concentrate on the deployment of the virtual appliance (vApp) itself.

As any reader of mine knows, I’m a big fan (here “fanatic” is accurate) of PowerShell.  I’ve also been very pleased with the progress that Hyper-V has made in the recent years, so that’s how I’m deploying this vApp.

First I need a name for the virtual machine.

Next I need to get the link to the download itself.  If you are an existing customer, this is found in your customer portal.

We’ll also need a name for the virtual machine.

I need to define a space on my server where I’ll hold the files after download.  I almost always refer to this as my scratch space.

Next we need to download the bits themselves.  For this I use Bits Transfer.  A note on Bits Transfer – it cannot be used in a non-interactive shell.  So, I do this work directly on the server.  You can use other ways, but I personally prefer this one.  Oh – we also need to tell it where to save…

Now that we’ve got the bits we need to expand them.  This is easy with Expand-Archive, which ships with PowerShell 5.0 and is part of Windows 2016.  If you don’t have this, you’ll need to either install PowerShell 5.0 (nice!) or use the Shell ComObject to expand the Zip (ugly, but effective).  Here, I’m taking advantage of everything that the new Windows Server offers.

Next, I need the paths to the existing system and data drives from the virtual machine.  I just use a little Get-Item goodness to get this.

I’ll also need to know where to store these files for the hypervisor, so I ask… nicely… with Get-VMHost.

Now I convert the VHDs to VHDXs.  Why?  Because Microsoft recommends it for *NIX-based machines.

You may ask yourself, “Self, why doesn’t SolarWinds provide these drives in this format out of the gate?”

I’ll answer that for you: backward compatibility.  The way that these bits are shipped “will just work” pretty much in any version of Hyper-V since it’s inception – so it’s better for all parties.

Enough banter – let’s convert!

Yay!  Now we have the drives converted to VHDx format, tagged with the VM’s name, and stored in their proper place.  Now that we have all the building blocks, we’re ready to actually build the Virtual Machine.

This is an intense block, so I’ve tried to comment it out pretty well.  In summary, it builds the VM, moves the DVD-ROM Drive, assigns the new drives, sets the processor and memory count, sets the VLAN for the virtual NIC, and finally sets the boot order.

It’s ready to go!  Cross fingers & turn it on.

It's alive! ALIVE!!!
It’s alive! ALIVE!!!

Now that it’s up and running, you can feel free to get crazy and install the Linux Integration Services or maybe the SolarWinds Orion Agent.

Now that the vApp is deployed, we need to integrate it with the rest of your SolarWinds Orion infrastructure, but that’s for another post.

Leave a Comment