Virtually Jason

I’ve had the chance to work with vRealize Orchestrator recently.  It’s got a bit of a learning curve, but we’re making good progress and are managing to automate some of those basic tasks that just seem to eat up time otherwise.  One of the challenges that we’ve come across is related to running PowerShell commands in the Guest OS itself (this is different than the PowerShell integration, which is a whole different ball of wax) via VMTools.  We ended up trying a bunch of different techniques, with various drawbacks and advantages. The first thing that we tried was the “Run program in guest” workflow under vCenter -> Guest Operations -> Processes.  When you launch that workflow, you’ll need to provide several pieces of data: which VM you want to execute the application in, the credentials for that VM, the path to the program and any arguments that the program will need (as well as a few others that we didn’t use in this situation).  The VM and credentials...

One of my customers recently encountered an interesting problem.  They encountered an issue that caused their Unidesk desktop backups to fail to delete from the archive datastore.  As such, that datastore filled up and backups were unable to continue.  The customer was working directly with Unidesk and VMware to resolve the issue, but in the meantime needed an easy way to purge all of the stale backups from their system. A few months ago, I posted about setting up Persistent ESXi Scratch Space for hosts using SD cards for their installations.  In that post, we covered how to mount a VMFS volume into a PowerCLI session.  Once it's mounted, we created the per-host Scratch folders, but that same technique can be easily used here to help us find those stale backups.  First, we ran this command to mount the "VDI-Archive1" datastore as a drive named DS: New-PSDrive -Name "DS" -Root \ -PSProvider VimDatastore -Datastore (get-datastore VDI-Archive1) Next, we...

One of my customers is migrating a lot of ESXi hosts (with a strong naming convention) from one network onto a new network with a pre-defined IP Addressing scheme based around fully populated HP C7000 blade enclosures (containing 16 blades).  The host naming convention is <Site>-<Enclosure ID>-ESX<Blade Slot Number>.<FQDN>.  Based on this, I've been tasked with automating as much of this migration as possible, and part of that is automatically assigning the new IP Addresses to the blades. In order to do this, I'm using the new-vmhostnetworkadapter cmdlet.  That cmdlet will need several parameters in order to work: -virtualswitch -portgroup -IP -subnetmask Most of these are trivial, as they will be constant for every host in the environment.  The big exception to that statement is the IP address parameter.  As I said earlier though, due to the strong naming convention at this site we can derive the host's new IP address entirely f...

One of my customers has asked me to help them migrate from one vCenter server to another.  In order to do this without causing interruptions, we're using ESXi servers like boats to bring the VMs from the old environment into the new one; basically the same process that I used last time a customer asked me to do this. This time, we're completing this process at many different sites and each site has many VMs that need to traverse the vCenter servers.  Since this customer doesn't yet have vSphere 6 with its inter-vCenter vMotion capability, we're left doing it the hard way.  That means doing an arduous, detail oriented, highly repetitive task... or, writing a script to do it for me. The worst part of this process comes from the VM networking.  We have to create Standard vSwitches on each ESXi host with VLAN configurations that mirror the Distributed vSwitch that belongs in the vCenter, then move all of the VMs to the appropriate Port Groups on the newly create...

Here's a short one.  One of my customers is using the VMware Distributed vSwitch in multiple vCenter inventories.  Since each vCenter maintains its own instance of the vSwitch, I was tasked with putting together an easy and repeatable process to create identically configured vSwitches across all of these environments.  In other words, I was asked for a script!  Most of the process is very well documented online, but there was one aspect of the config that was a struggle: enabling NIOC via PowerCLI.  It's a simple checkbox in the GUI, but near as I can tell, there was no simple way to enable it in a PowerShell script. Like so often in life, LucD has the answer .  This specific nugget of information is a bit buried, so I figured that I'd put together a quick note expanding on it.  There's an API method, EnableNetworkResourceManagement(), that can toggle that setting for the DVS, but that method doesn't exist under the normal PowerCLI DVS object.  ...

After installing an ESXi cluster, of course you want to validate its functionality.  vMotion/DRS are easy to validate, but how about HA?  Just pull the power cable out of the back of one of your ESXi hosts, right? Well, that will do it... but it's also a bit risky.  I've seen host configurations fail to come back from an unexpected power failure and I've heard stories of hardware damage stemming from such an event.  So, a power failure is probably not the best option... so what else can you try? You could always induce a Host Isolation event .  Simply disconnect all of the network cables from the ESXi host, which will trigger the specified HA response.  That works, but it's a bit of a pain, as you're likely going to need to unplug several cables and keep track of exactly where they belong.  If you're remote, you'll need to involve the network team to get them to shut down specific ports (and you'd better hope that there's no miscommunication rega...

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host...