Posts

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…

Finding All VMs with Multiple IPv4 Addresses

Here's a quick PowerCLI one-liner.  I recently had to find all of the VMs in a customer's environment that had multiple IPv4 IP Addresses assigned to them.  Here's the command that I ended up using:

Get-VM | Get-VMGuest | select VM, IPAddress | ? {($_.ipaddress = $_.ipaddress | ? {$_ -match '\.' -and !($_ -match '^169\.254\.')}).count -gt 1}

That guy's a little dense, so lets break it down.  Get-VM gives me a list of all VMs in the environment, which is piped to Get-VMGuest which returns the VM name and all IPs associated with it (looking at the VM's extensiondata.guest.ipaddress only shows the first address).  From there, we select the VM and its IP Address and pass that to a Where clause that has some logic.

That Where clause is going to return each VM that has more than 1 IPv4 address that is not an APIPA address.  It does that by finding only the IP Addresses that have a '.' in them (since IPv4 addresses use . delimiters whereas IPv6 add…

vRealize Network Insight Overview

"It's the network!" seems like the battle-cry for some server teams.  I come from a system administration background; I get it.  When all of your services are running and the event logs look clear, it must be something external to the system... which is either the network, or something is being talked to through the network.  I've seen so many server guys chant that mantra, toss the problem over the fence and then wash their hands of the whole situation that I want to scream.  That said, I've also been in plenty of situations where I've brought a problem to the network team, asking them for help when I can't find anything wrong with a system.

One reason I like to go to the network team when I have a seemingly intractable issue is perspective.  Within a single server, I can drill down deep and get a good idea about what the applications on that server are doing, but it's much more difficult to get a picture of a whole solution.  The network team, with …

VMware Logon Monitor

When rolling out a VDI solution (or really, anything that touches on the user experience), it's crucial to understand how the change might impact the users and to ensure that they are left with a good impression of the solution.  They say that first impressions are most lasting, and the first impression that your users are going to see (for most solutions) is logon time.  That means that it's crucial that your solution does not negatively impact logon times, as that will color the entire experience.  So, how do you accurately measure it?

Well, VMware released a Fling called Logon Monitor (and, it's now baked into the Horizon 7.2 agent).  It's a tool that's sole purpose is to measure the logon process and to report on what's happening during a user logon.  After it's installed, it logs (with excruciating detail) everything that occurs during a logon, storing the file in a default location of C:\ProgramData\VMware\VMware Logon Monitor\Logs

It creates a file f…

vSAN RAID Levels and Fault Domains

One of my customers is considering implementing vSAN, so I've been researching it quite a bit lately.  The interactions of vSAN RAID levels (for all-flash configurations) and Fault Domains is fairly complex, so I figured that I should post some notes about what I've learned here.

First, the concept of RAID is a little different in vSAN than it is in a traditional array.  Traditionally, RAID specifies the algorithm used to spread data (or parity data) across a set of disks.  For example, RAID 5 specifies that data will be striped across all of the disks in a set, with a single disk's capacity used for parity.  This means that a 3 disk RAID 5 set will store data on 66% of its disks' capacity.  A 5 disk RAID 5 set will store data on 80% of its disks' capacity.

vSAN treats RAID differently.  There are 3 different RAID types that vSAN supports: RAID 1, 5 and 6.  Like in a traditional array, these RAID levels describe the data redundancy algorithm used, but the members a…

Group Policy Loopback Processing on Windows Server 2012

Every now and then (especially in a VDI situation), I need to enable Group Policy Loopback Processing.  This Group Policy setting can do a lot of things; I usually use it to allow me to create Group Policy Objects that contain User Configuration settings that only apply when the users log into a certain subset of computers (such as my VDI desktops).  When that setting is enabled, it basically instructs windows to process its computer GPOs again at user logon, so as to catch any User Configurations that are specified.

This is a setting that I configure once for each VDI deployment that I do, and I always need to look up where it is (who bothers to memorize where specific settings are amongst the thousands of options!?).  No problem, that's literally what google was made for.  So, a quick search for Group Policy Loopback Processing is in order, which brings me to a technet article about Windows Server 2003 that calls the setting simply Loopback processing.  Well, Loopback Processin…

Finding Stale Brocade Zone Configurations

I recently wrote about a situation where I was creating a zoning configuration and had to figure out which fiber channel devices were active.  After we finished that project, we decided that we should go through and actually remove the inactive aliases and zones.  We had a list of active devices, so we were all ready to move forward and say "delete everything that isn't on this list!".  That'll work great, right?

Of course not; we needed the opposite.  "Delete everything that is on this list" is a far better instruction that is way less likely to lead to painful mistakes.  Even better is "run these commands to delete all of these unnecessary objects" and I know one good way to generate such a list of commands: a script (I feel like I'm developing a battle-cry...).

I put together a script that does a few basic things.  First, it uses the nsshow command to get a list of all of the active WWNs on a given Brocade fiber switch.  Then, it compares a…