Virtually Jason

System upgrades are a fact of life in the world of IT.  As systems grow more complex and interrelated, upgrades become more and more difficult to plan, as each of those interacting systems creates a dependency that may or may not support the new version!  In the VMware world, there's a couple of great tools that I use every time one of my customers asks for help with an upgrade project... so I figured that I'd write about them here! If the customer wants to upgrade their ESXi servers (which they almost always do), the first thing that I check is the VMware Compatibility guide .  When I'm using this tool, I typically select the new ESXi version under Product Release Version  and then just use the search bar to find the hardware platform that the customer is using.  After selecting the right server, the page will show us what firmware versions on that server platform are supported (or other interesting notes to be aware of).  These days, it's pretty rare for ...

One of my customers is organizing a cloud migration and asked for help with the onboarding process.  My team and I started doing research and we come across VMware's Hybrid Cloud Extension (HCX) technology.  It's incredible, how did I not know about this before!? The long and short of it is that it bridges customer networks into cloud datacenters so that VMs can be vMotioned to and from the cloud.  That's a very powerful position to put the customer in, as they can now migrate workload dynamically onto the cloud without taking a service outage.  How's it work? HCX requires several appliances, both in the cloud and client datacenters.  Those appliances serve 2 major functions: they bridge production networks and they proxy ESXi hosts. As far as network bridging is concerned, the HCX appliances function very much like an NSX Edge that is doing its own L2 bridging.  From a network perspective, HCX basically looks like an upstream switch, behind which ar...

One of my customers was doing some work on their storage network and so wanted a list of all ESXi hosts and their WWNs.  This struck me as another excellent scripting opportunity, so I pulled out my old Brocade 1:1 Zoning script and went to work.  I really only needed a one-liner for this situation, so I extracted my needed syntax from that script and quickly put it together.  Here's the (admittedly, ugly) command that I came up with: get-vmhost | select name,@{N="WWNs";E={($_.ExtensionData.config.storagedevice.hostbusadapter.PortWorldWideName | % {("{0:X}"-f$_ -split '(..)' | ? {$_}) -join ':'}) -join ", "}} That'll spit out a list with two columns, ESXi host names in one, and a comma separated list of WWNs in the other.  So, what's that ugly expression in that select statement doing?  Well, it's collecting all of the port WWNs on that ESXi host, then converting each one from decimal into hexadecimal (the "{0:X}...

One of my customers has been deploying App Volumes, using their SQL Always On availability group for the database.  They pointed at the listener and everything looked good... until they initiated a failover.  Fortunately, the fix was really simple, although two part. First, we noticed that the ODBC connections were using the default "SQL Server" driver.  That immediately stood out to us as a problem, as that driver can't handle AO failovers (exactly what we saw).  So, we switched it over to the Microsoft ODBC Driver 13 for SQL Server driver and figured that we'd be good to go.  Almost. When we attempted to connect to the App Volumes Manager, we received a DB access error.  We saw that it was using the correct driver (yay!), but it was getting a credentials error because it was trying to use the server's computer account.  Some quick google searching pointed me at an article about changing database credentials in App Volumes , but that was for a fai...

As a next-gen firewall, NSX allows us to get very dynamic with our firewall rules and create complex behaviors out of comparably very few rules.  Let's look at the same example 3 Tier Application rule set that I wrote about in my post about the Direction and Applied To fields in NSX Firewall rules  post, and look at how these groups could be configured and then we can look at how these rules could be made even more secure.  First though, here's the example rule set: Source Destination Action Applied To Any InfraServices Allow DFW Client Devices Web Allow Web DB, App Web Deny Web Web App Allow App DB App Deny App App DB Allow DB Web DB Deny DB SolutionA SolutionA Allow SolutionA SolutionB SolutionB Allow SolutionB SolutionA Any Deny SolutionA SolutionB Any Deny SolutionB These rules will allow default 3 Tier Application communications (Web can talk to App, App can talk to DB) while blocking nonstandard communication within the solution and blocking all...

I've had the chance to learn about NSX lately, which has included really diving in to how the firewall behaves.  While it can certainly be used very much like a traditional firewall, you're not doing yourself any favors by doing so.  Remember, this is a policy-based firewall, so our goal is to define as many general behaviors as possible and then have them apply intelligently to the correct VMs based on attributes such as Security Tags. There's a lot to dig into on this topic, but for now I want to focus on two attributes of a firewall rule: Direction and Applied To.  These two settings can be used to dramatically simplify a firewall configuration and can lead to some unexpected results if not used correctly (also, they took me quite a while to wrap my head around). The most important thing to remember is that, like all firewalls, NSX eventually boils down to a sequential list of rules.  NSX will do whatever action is specified in the first rule to match a given ...