Meetups, PowerShell, Expanding My Horizons

20160714_184947

I’m not sure what it’s like in other major cities around the world.  But currently Melbourne is going through an IT meetup boom.  On any given week you can find at least one if not multiple meetups going on somewhere in Melbourne.  A big change of years past where we would have only a couple major conferences a year to look forward to.  It’s really quite an exciting period for meetups we’re going through.

So what is going on with all these meetups  —Meetup being the new buzz word we’re seeing slowly replacing the traditional User Group we’re all probably use to.  I think it’s in small part to do with the website meetup.com.  Sure, many of these User Groups have existed well before meetup.com became a thing.  But to find them you had to be part of the right Facebook group, follow the right twitter user, or just learn of it through some word of mouth.  I lost count before meetup.com on how many User Group meetings I missed by learning about it the next day.

We now have a common place we can visit to find all these User Groups and meetups.  Type in DevOps, PowerShell, VMware and dozens of meetups pop up in your local area.  RSVP and see all the other local users also going, not sure what the meetup is about, post a quick question and receive an answer right back.  There’s an update to a meeting, receive an email notification immediately.  I see it as a symbiotic relationship between a globally accepted meetup site and the user group.  We at the Melbourne VMware User Group have even started using it in conjunction with the traditional VMUG website to extend our community base.

CnUF-fZUsAEfGWd

This is how I found out about the recent PowerShell meetup I attended in Melbourne.  With all the scripting I’ve recently been doing in PowerCLI and PowerShell I wanted to expand my horizons a little further and find out how the wider PowerShell community works.  The group has only existed since the start of the year and this was their fourth meetup held in the seek.com.au offices.  The setting for the meetup was very casual and devoid of any advertising or marketing.  That is if you can overlook the office seek logos all over the place.  But considering the worst seek can actually do is find me a new job I’m more than happy to tolerate this 🙂   Of course there was the obligatory Beer and Pizzas which we all know elevates a good meetup to an awesome meetup.

sccm2012A found the format and atmosphere of this PowerShell meetup very appealing.  Heavy on practical content & demos and light on PowerPoint slides.  The setting around a large boardroom table with beer and pizza in hand also lead to a more comfortable environment to engage with community and presenters.  The meetup tended to have a slant towards DevOps practices using PowerShell rather than using PowerShell.  So less about how to connect to this server or use that cmdlet and more around processes and integration.  I was also lucky enough to receive a copy of the book, Learn System Center Configuration Manager in a Month of Lunches, from its author James Bannan.

Due to work commitments of the organiser, the PowerShell meetup was pushed out a day which turned out conflicted with an Azure meetup on the same night.  With so many IT meetup groups current listed and running in Melbourne.  There’s bound to be a small culling, a kind of survival of the fittest, happen.  So whether this PowerShell meetup group succeeds or not only time will tell.  I certainly hope it does and they continue to find that DevOps centric content it aims for.

Until the next meetup…

Melbourne VMUG Meetup Group

VCP 6, My Last VCP

VMW-LGO-CERT-PRO-6-DATA-CTR-VIRT

Ok, so I say this every time but this time I mean it… well, at least I think I do.  This is my last VCP exam.  I took the VCP 5.5 Delta a few years back now.  Before that were a few VCP 5s.  There might have even been a VCP 4 thrown in there somewhere.  I’ve taken this exam more times than I want to think about.

Last week I took the VCP6-DCV Delta.  I could have held off a few more months before my VCP 5 expired but i had some spare capacity to study so I committed to retake the exam.  Work was kind enough to give me two dedicated study days to prepare.  I used them as well as I could have.  I had also hoped to get in some solid study in the weeks leading up to the exam but unforeseen personal issues got in the way which wrote that off.  So I really wasn’t feeling confident going into this exam.  To my surprise, though, I actually passed with a decent mark.

The VCP is a real solid exam for its type, it always has been.  Personally I think one of the harder ones out there too.  Of course exams like the VCAP are on a different level but as for the standard multiple choice exam it’s right up there.  VCP exams really require that you have solid experience with the technology, especially the VCP-DCV focusing on vCenter, along with vSphere Replication, a little vCloud Air thrown in, vSAN features, and the new PSC.  it has really become quite broad.

The Delta I took was comprised of 65 questions over 75 minutes, 20 questions less then the full VCP exam thankfully.  As a guide I usually work out how many questions 70% is and treat that as what’s required to pass.  It’s usually treated me well as a format for passing.  So when I scribbled down 15 questions I was uncertain with at the end of the exam I felt it could have gone either way.  I was quite worried.  So seeing that I passed in the high 400’s out of a possible 500 was quite pleasing.

I think the community has finally gotten over and accepted this 2 year expiration with VMware certifications.  I’ve never really had an issue with it.  I’ve known this is where the industry has been heading with certifications for a while now.  It doesn’t mean it’s not frustrating though.  Which is why I’m hoping I won’t have to do another one again.  Now it’s not to say that I won’t do another VMware cert.  I just have to be a little smarter and play the game a little better by upgrading to the new VCIX cert.

In any case, it’s done, it’s out the way.  I get to use the new little logo.  And, well, that’s about it 😛

Get-View | Show-Object

I was recent watching a PowerShell presentation where they mentioned a cool module called PowerShellCookbook and in particular discussed a cmdlet in it called Show-Object by Lee Homes.  I instantly knew how perfect and powerful it would be with VMware’s PowerCLI Get-View.

Bare with me for a minute while I lay the ground work with Get-View.  If you’ve ever used Get-View in PowerCLI you’ll know that it brings back a ridiculous wealth of information.  When you run a cmdlet like Get-VMHost it’s really only bringing back a small subset of information back on that object.  Sometimes this is fine but sometimes we need that little bit extra to reach our objective.

For example you can run Get-VMHost esxi01.ukoticland.local

Windows PowerShell ISE-000282

What you get is a default formatted table view displaying only a few key values.  A trick some of us do is then pipe this out to a list.  Get-VMHost esxi01.ukoticland.local | Format-List

Windows PowerShell ISE-000283

Heaps more information right, but it’s still not the full picture.  There’s still a lot of information on this object that we’re missing.  Take the original cmdlet we ran above and this time let’s pipe it to Get-View.  Let’s also store it in a variable called $myHost, just so we can work with it.

$myHost = Get-VMHost esxi01.ukoticland.local | Get-View

Windows PowerShell ISE-000284

Okay, on first glance it doesn’t look like much.  But all those values that start with VMware.Vim are properties that can be drill down into.  For example $myHost.Config and $myHost.Config.Capabilities

Windows PowerShell ISE-000288

So it’s pretty cool right.  We can now start retrieving a huge amount of new information that wasn’t available to use before.  But this is like finding a needle in a haystack.  I know I’ve wasted so much time typing $something dot something dot something in the hopes of finding a value I can work with.

Well finally this brings us to Show-Object.  This is an awesome cmdlet that will let you display the object retrieved with Get-View in a grid view window that you can navigate through similar to a directory in File Explorer.  Using it is as simply as piping our variable to Show-Object.

$myHost | Show-Object

Windows PowerShell ISE-000287

Now we can explore and click around at everything available to us.  As you navigate the object in the top pane for results you’ll get member data in the bottom pane.  I see this becoming a great reference tool to help find what you’re looking for.  Not only that but it will give you the syntax to retrieve the information selected in the view pane.

So how do you get Show-Object?  Well, it’s not in PowerShell by default but can easily be obtained from the PowerShell Gallery, which, if new to you, is basically a public repository for PowerShell content.  If you’re using Windows 10 you’re half way there.  If not go get yourself the Windows Management Framework (WMF) 5. This will give you the latest version of the PowerShellGet module.  Then it’s just a matter of typing Install-Module -Name PowerShellCookbook.

Once the module is installed from the PowerShell Gallery, Show-Object is now available to use.  It’s worth noting that PowerShellCookbook comes with a huge array of extra cmdlets also worth exploring.

Finally if you do try out Show-Object and like it, there’s a “jacked up” version of it over at PoshCode by Justin Rich

 

Melbourne VMUG, Stronger Than Ever!

Held this week was the quarterly Melbourne VMUG.  The location was sponsored by Telstra, as it has been for a little while now, in one of their conference facilities in the CBD.  Telstra have shown to be a great supporter of the Melbourne VMUG with the continual use of their facilities.

I’ve been semi regular attendee to the local Melbourne VMUG for quite a number of years.  So it’s a great privilege to have now become a committee member.  I’m still very green to the role and learning the ins and outs.    What I can say so far is that it’s run by a great bunch of guys committed to putting on the best event possible.

The Melbourne VMUG is an awesome event, hands down.  Where as other user groups run very regular meetups (monthly).  The Melbourne VMUG has taken a quality over quantity approach.  We run a large annual UserCon at the beginning of the year plus another three regular meetups throughout the year.  In between the meetups we run vBeers where like minded people can just sit and chat over some drinks (Beer).

We’ve now reach a point in the Melbourne VMUG where we can comfortably run two tracks side by side at our regular meetups.  Our May meetup had some great sponsors and some of the best content I’ve seen -with some great prizes to boot.  Our first session had vendors HP and Runecast presenting.  I sat in on Runecast and was really impressed on what they have to offer.  Our second session was VMware.  We had Chris Garrett talking about everything new in vSphere 6.0 Update 2 and Kevin Gorman talking containers.  I sat in on Kevin’s preso.  Kevin puts on a great talk and is a really great guy to listen to. The last session of the night was allocated to community speakers.  We had the leader of the Melbourne Docker User Group, @benitogriffin, present and an awesome Panel Session on Home Labs.  Okay, I may be a little bias on this last one.  I was one of the four panelists.  That’s me on the far right.

CiQB3WQU4AA8KAf

The night didn’t end there.  We had vendor sponsored vBeers and pizza at Troika Bar.  A cool little bar around the corner covered in what looked like aluminum foil that made you feel like you in a satellite or something.  A great end to the night where everyone could wind-down and talk about that awesome Home Labs panel session that I was in 😛

CiQC8gtU4AA8bKN

Recently on social media there was discussion going around on how to make VMUG great again.  People comparing VMUG of the past to what it is today.  I was a little disappointed to read some of the comments.  VMUG certainly isn’t what it use to be.  That doesn’t make it worse… just different.  Just like in IT things change and we have to adapt and change with it.  If you feel you need to make VMUG great again look no further than the Melbourne VMUG.  Best VMUG  Ever

Links

VMUG Homepage
Melbourne VMUG Workspace

 

Cannot validate host customizations for host ‘fqdn’. null

I’ve been doing a lot of work recently with Auto Deploy and Host Profiles in vCenter.  I feel both of these technologies are very underrated in vCenter.  With Host Profile, prior to using Auto Deploy, I always felt they were just a little more trouble then it was worth.  Trying to get every host compliant at the same time seemed like this loosing battle I was facing.  But Auto Deploy and Host Profiles go hand in hand so it was an opportunity to get it right.

While deploying Host Profiles to our Cloud environment I ran into a few interesting errors.  One of these were the below.

Cannot validate host customizations for host x.x.x.x. null

host_profile_null

The error was generated in the vSphere Web Client while trying to validate the Host Profile and apply.  This error was very non-descriptive and provided little in the was of help.  As much as I tried not to I defaulted back to the C# Client and tried to apply the Host Profile once again to the host.  This time I received a much more informative error message.

Host Profile execution failed: ‘Balanced’ CPU policy not supported by system

Now this was now much clearer.  What had happened was that I generated the Host Profile on a physical host with slightly different hardware.  I was able to quickly fix the issue by deselecting Power System in the Host Profiles configuration.

The interesting take-away here was not what caused the error but having to revert to the C# Client to get some meaningful information on the error.  So it’s worth trying both the vSphere Web Client and C# Client when facing similar errors.

References

Applying the Host Profile settings on an ESXi host using vSphere Auto Deploy fails with the error: Host Profile execution failed: ‘Balanced’ CPU policy not supported by system

ESXi Host Client Officially Released

A few days ago ESXi 6.0 Update 2 was released.  Quietly added in was version 1 of the ESXi Embedded Host Client.  I’ve spoken a few times about the Host Client.  It started out as a VMware Fling by VMware engineers Etienne Le Sueur and George Estebe.  Since then it has gained a hugely positive response from the community that it has finally found its way into ESXi.

If you’ve recently upgraded or installed ESXi 6.0 Update 2 you can access the host client via a browser connecting over standard SSL (https:/myesxi-host/ui/).   You can login with the host’s root account.  If you’ve never seen the Embedded Host Client before you’re in for a huge surprise.  You’ll be amazed at how similar it looks to the vSphere Web Client.  Not only that but it’s extremely snappy and fast built upon HTML5.

I recently upgraded my NUC home lab hosts to Update 2 to check out the production build.  It looks and feels just like the Tech Preview.  It’s going to be a great replacement to the C# Client.  If you’re running a previous Tech Preview release of the fling there’s a few things to note before you upgrade to Update 2.  Initially I did an upgrade of a host with an old Tech Preview 5 fling installed.  Update 2 left that version of the fling in place.  So on my subsequent hosts I removed the Tech Preview fling before upgrading the host.  That resolved the issue and installed the v1 production release.

Below are the steps to remove the Tech Preview fling before upgrading a host.  The -f represents a force removal just in case you have any third party vibs that may conflict with the uninstall as I did.

[root@esxi03:~] esxcli software vib remove -f -n esx-ui
Removal Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed:
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.3357452
VIBs Skipped:
[root@esxi03:~]

If, like me, you upgraded a host before removing the Tech Preview version of the fling. You can download the official Host Client from the VMware download portal.  List with the ESXi 6.0 U2 Zip and ISO images is the Host Client VIB and Offline Bundle.  Then just run through the steps to remove and install the VIB.

There is a newer build also available up on the flings page --Tech Preview v6.   I chose to upgrade to this build as it’s just my home lab.  The process is simple, I outlined the steps to update the Embedded Host Client to a new build in a previous post.

Latest v1 Production Build

host-client_v1

Latest Tech Preview Build

host_client_tp6

References

Embedded Host Client Fling Page

VMware Host Client Release Notes

Auditing and Alerting on vCenter Permissions – Part 2

In my previous post I discussed auditing permissions in vCenter via PowerCLI.  Going through the process of identifying account and group permissions and what objects they have been set on.  In this second of a two part post, I look at creating a vCenter Alarm in PowerCLI that will trigger when a permission is Added / Removed / or Modified which will then show up in vCenter Alarms.

Part 2 -- Generating a custom alarm on a vCenter permission change

The objective here is not to catch someone out (though you could see how it could help).  The Alarm is by no means meant to be as a deterrent or even used for auditing.  Where it’s useful is as an identifier that a permission add / remove / modification as taken place.  Once triggered a person can review the new permissions and acknowledge the alarm.

Working with vCenter Alarms in PowerCLI hasn’t reached the maturity as many other Cmdlets.  So creating new alarms with PowerCLI is not as straight forward as using a Cmdlet.  To create a new alarm ww have to use the powerful Get-View Cmdlet which exposes us to all the richness of the SDK APIs of vCenter.

Creating an alarm requires a few pieces of information.  First we create the alarm object, give it a name, description, and set its state.

Next we create our Triggers or expressions.  Creating the expression is where the magic lays.  The key piece is the EventTypeID.  This is the specific vCenter event that will trigger the alarm.  I found finding this information through VMware was extremely difficult.    With a little searching though, and playing around, I found the information I was after with Get-View eventManager.

$event = get-view eventManager
$eventman.description.eventinfo | Where-Object {$_.key -like "*permission*"}

Running the above without any filters returned a huge amount of information with possible events to trigger on.  Using the Where-Object Cmdlet I was able to filter the results to anything with the word ‘permission’.  This narrowed down the results to just four.  The key three being  PermissionAddEvent,  PermissionRemoveEvent, and PermissionUpdatedEvent.  Of course if you want to see everything just remove the pipe and everything after it.

With these events and a little more research I had enough information to now create a script for an alarm.  Below I created three expressions.  One for each Permission event and set it’s status to Yellow if triggered.  The alarm is created in the root of vCenter and will propagate down to all objects.

$alarmMgr = Get-View AlarmManager

# Create AlarmSpec object
$alarm = New-Object VMware.Vim.AlarmSpec
$alarm.Name = "Permission Modification"
$alarm.Description = "Track permission changes"
$alarm.Enabled = $TRUE

# Event expression 1 - Permission Added
$expression1 = New-Object VMware.Vim.EventAlarmExpression
$expression1.EventType = "EventEx"
$expression1.EventTypeId = "vim.event.PermissionAddedEvent"
$expression1.ObjectType = "VirtualMachine"
$expression1.status = "Yellow"

# Event expression 2 - Permission Removed
$expression2 = New-Object VMware.Vim.EventAlarmExpression
$expression2.EventType = "EventEx"
$expression2.EventTypeId = "vim.event.PermissionRemovedEvent"
$expression2.ObjectType = "VirtualMachine"
$expression2.status = "Yellow"

# Event expression 3 - Permission Modified
$expression3 = New-Object VMware.Vim.EventAlarmExpression
$expression3.EventType = "EventEx"
$expression3.EventTypeId = "vim.event.PermissionUpdatedEvent"
$expression3.ObjectType = "VirtualMachine"
$expression3.status = "Yellow"

# Add event expressions to alarm
$alarm.expression = New-Object VMware.Vim.OrAlarmExpression
$alarm.expression.expression += $expression1
$alarm.expression.expression += $expression2
$alarm.expression.expression += $expression3

# Create alarm in vCenter root
$alarmMgr.CreateAlarm("Folder-group-d1",$alarm)

# Add action to email alarm
#Get-AlarmDefinition $alarm.Name | New-AlarmAction -Email -Subject "vCenter Permission Modification Occurred" -To me@mydomain.local
#Get-AlarmDefinition $alarm.Name | Get-AlarmAction | New-AlarmActionTrigger -StartStatus 'Green' -EndStatus 'Yellow'

Commented out is also the ability to email a notification out when an event occurs.  This just feels a little overkill but never the less is a notification option.

The beauty of this script is that it can also easily be modified to alarm on any trigger-able event in vCenter.  Whether you need one expression or multiple expressions it’s easily modifiable.

Virten.net has a good article on how to create custom alarms and find events that I used for a reference.  If you don’t want to search for your own events to alarm on.  Virten maintains a database of all events that can be alarmed on.  I’m not sure how current it is but it’s a good starting point.

References

How to create custom vCenter Alarms from Events | Virten.net

Vmware Data Object -- EventAlarmExpression

Auditing and Alerting on vCenter Permissions – Part 1

In this two part post I discuss and cover how to audit vCenter permission using PowerCLI.  How to enumerate basic permissions and then expand it out and send it to a CSV file for further auditing.  In Part 2, I’ll discuss how to create custom alerts using PowerCLI to trigger an event on a vCenter permission modification.

Part 1 -- Auditing vCenter Permissions

Reviewing and auditing vCenter permissions has always been awkward at the best of times.  Unless you’re on top of permissions from day one, over time you can be left with a mess of vCenter permissions.  If you’re not explicitly looking for it you won’t know it either.  This is certainly what I found recently in one of my vCenter environments.

There are a few different ways to view permissions in the C# and Web Client.  You can click on an object and view the Permissions tab or you can go to Roles.  The Roles section is certainly much more useful but still far from ideal.  You have to click on each Role and there is no way to export that information.  Using PowerCLI on the other hand you can consolidate the above two methods into one view and have it exportable.  The quickest and easier way to get started is with Get-VIPermission once connected to a vCenter in PowerCLI.

Get-VIPermission | Format-Table -AutoSize

Get-VIPermission in its default form gives you a quick overview of all Principals / Users defined with explicit permissions along with their Role, whether it’s a group, and if it’s set to propagate down the tree .  Ideally you’ll only have a few groups listed here and nothing else.  Unlike myself, where I had a large amount of individual users explicitly listed on many different objects.

When using Format-Table we loss a little information on the screen. Namely, we can’t see on what objects these permissions are set on.  So we can work with the Get-VIPermission cmdlet to expand it out a little further.

 Get-VIPermission | sort | Format-Table Entity, EntityID, Role, Principal -AutoSize

The two extra values we are looking for here are Entity and EntityID.  In most cases Entity will aid in identifying the vCenter object that has the explicit permissions set on it so you can review.  The Entity could be a Virtual Machine, a Cluster, or a Datastore.  In some cases, though, you will find the Entity is blank.

Again, in my case I had a lot of permissions with a blank Entity.  Using EntityID I could see that the objects appeared to be networking related.  So in this case we need to get a little more creative with the querying of the SDK APIs using Get-View.

Get-VIPermission | sort | ft @{N=”ObjectName”;E={(get-view -Id $_.EntityID).name}}, Entity, EntityID, Role, Principal -AutoSize

This now gets us 95% of the way there.  We use Get-View using the EntityID as the Get-View ID to find the actual name of the vCenter object for that missing Entity value.  In the case of the networking objects we will now get the exact names of the networking switches.

get-vipermission01

Putting it all together.  In this last part I turn the one liner into a little script, make sure the correct snap-in is loaded, make it a little easier to read, and have it output to a CSV file that can be used to audit and review at a later stage.

# Import Snap-in
if ((Get-PSSnapin | where {$_.Name -ilike "Vmware*Core"}).Name -ine "VMware.VimAutomation.Core")

{
Write-Host "Loading PS Snap-in: VMware VimAutomation Core"
Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue
}

$Date = (get-date).tostring("yyyyMMddHHmm")
$result = Get-VIPermission | sort-object -Property Principal | Select @{N="ObjectName";E={(get-view -Id $_.EntityID).name}}, EntityID, Role, IsGroup, Principal

$result | Export-CSV -Path "$pwd\vCenter_PermissionAudit-$date.csv" -NoTypeInformation -UseCulture

In the above script the results are outputted to a CSV file appended with the date.  The benefit of doing this is you can schedule it to run and now have a history of the state of permissions over time.  Simple as it is, I think it’s really handy.

In the next post I will look at creating a basic Alarm in vCenter that will trigger when a permission is modified on an object.

Patch Release ESXi550-201601501-BG breaks connectivity to vCenter

A few days back I upgraded an ESXi host from ESXi 5.1 to 5.5.  I had downloaded the latest image my vCenter and hardware would support.  The upgrade went well.  Once the host rebooted and was connected back in vCenter I performed a patch scan to see missing patches.

I had about six missing patches.  One being ESXi550-201601501-BG, released only a few days beforehand on 4 Jan.  It was marked as a Critical Bugfix.  As I have always done with Critical Bugfixes I Remediated.  After all, it was Critical and a Bugfix.  Once the host remediated and rebooted I found that I could no longer connect to the host via vCenter.  Receiving the below error when attempting to connect.

Cannot contact the specific host (hostname). The host may not be available on the network, a network configuration problem may exist, or the management services on this host may not be responding.

I opened a C# Client and was able to successfully connect to the ESXi host directly.  So all looked good there.  I decided to look up the KB article of this latest patch (KB 2141207) to see what it fixed.  Nothing came up.  No page could be found!

With a lack of information on this patch the best thing I could do was just to revert the patches.  The fix was simple.  I rebooted the host.  During the Loading VMware Hypervisor I pressed Shift R for Recovery mode.

recovery01

The VMware Hypervisor Recovery screen then appears.  It shows the current build and the previous build that it will Roll Back to.  Pressing Y starts the process.  It was quick and simple and I was back up and going on the previous 5.5 build I had just upgraded to without the addition patches I installed.

recovery02
(The above screenshot was not the host that I Rolled Back but rather is a base 5.1 image)

The KB article page now works.  It is quite clear you shouldn’t update to version 5.5 Update 3b before you upgrade your vCenter to the same version of 5.5 Update 3b.  The interesting note here is that I didn’t realise that I was updating the host to ESXi 5.5 Update 3b.  My upgrade image was ESXi 5.5 Update 3a and I thought I was just installing a critical bugfix patch.  Where I can undone was this was an esx-base patch that brought the effective build number of the ESXi host up to the same level of a full ESXi 5.5 Update 3b build.

So what was actually going on with this patch…

Reading the KB article isn’t entirely obvious what’s going on.  Yes, we now know not to update unless vCenter is on Update 3b but why?  The article states that the patch updates the esx-base vib to resolve an issue when upgrading from ESXi 5.5 to 6.x, where some VMs and objects may become inaccessible or report non-compliant.  That’s clearly, though, not what we’re doing here.

The KB article now has a new link to a second KB article (KB 2140304) which describes the issue you will face if you don’t upgrade vCenter first.  What it describes is that SSLv3 is now disabled by default in this esx-base vib.  So I can only presume that vCenter wants to connect to the ESXi host using SSLv3.

Fortunately the resolution wasn’t that complex.  I was able to resolve the issue and get the host up and going relatively quickly and all within my outage window.  This is the first time I have experienced an ESXi patch break a host.  I’m surprised that a patch is actually changing the default behaviour of a host.  I can understand, and even support, VMware making the change in the latest ISO image build of ESXi 5.5 but not in a patch.

The Lesson…

So the lesson here (and there’s probably a few but I’m going with), stay away from any esx-base patches that have been released post 4 Jan 2016 until vCenter is upgraded to 5.5 Update 3b.

As a side note I would assume SSLv3 could be re-enabled on the host but I haven’t looked into this yet.

References

After upgrading an ESXi host to 5.5 Update 3b and later, the host is no longer manageable by vCenter Server (2140304)

VMware ESXi 5.5, Patch ESXi550-201601501-BG: Updates esx-base (2141207)

ESXi Embedded Host Client v4 released

Unless you’ve been hiding under a rock recently you must have heard of the ESXi Embedded Host Client Fling by now.  This is one of the more exciting Flings of recent.  Actually there’s a couple really cool ones atm but this one definitely stands out.  And it’s just undergone another update.  With each iteration the engineers, Etienne Le Sueur and George Estebe keep adding more features and bug fixes.  It’s really progressing along really nicely.

I did a vMug community talk recently on VMware Flings and spoke about the Embedded Host Client.  For my first community talk it’s been really well received.  If you’re not up on what Flings are about or what the ESXi Embedded Host Client can do please check it out.

Installing the Fling is really easy, especially if you’re already running v3 of the Fling as I was.  If you’re currently running v3 you can use the Update method under the Help menu like I did.

Updating ESXi Embedded Host Client from v3

Firstly you need to grab the latest build from VMware Flings.  Download the vib and upload it to a datastore accessible to your host.  I used the Embedded Host Client and used the Datastore Browse feature to upload.

Log into the Embedded Host Client as you normally would and click on Help in the top right and select Update.

embedded_host_client_03

Next enter in the path to where you uploaded the vib file.  This can be a little tricky as you have to manually enter in the path.  It took me about seven tries to get the path and file name correct.  A feature request I’ll be submitting for the next version will be a browse option to paste in the correct path and name.

embedded_host_client_04

Click Update and if you got it path correct you should see a task similar to below.  You’ll know pretty quickly if it didn’t work because the task will end instantly and you won’t see a progress bar in results.

embedded_host_client_05

Once complete reload your browser session and sign back in.  Your build version should show the latest version.

embedded_host_client_06

Of course if you’re not already running the Embedded Host Client or an older version to v3 you can still install/update using the ESXCLI command from the ESXi console.

I’ve covered in previous posts how to install a vib from the console using ESXCLI.  Examples are also given on the Instructions tab of the Fling’s page.  Basically, upload the vib to a datastore on the host.  Then use the command below substituting the path for where you placed the vib.  No reboot or Maintenance Mode is required, which is really nice.

esxcli software vib install -v /vmfs/volumes/datastore1/esxui-signed.vib

That’s all that’s required and hopefully the installation goes well.  You should now be able to access the host via https://esxi_host/ui/

I can’t wait to see this become an official product.  No doubt there’s a long and tedious process to get the ESXi Embedded Host Client certified and ready as a VMware supported product.  Hopefully we see it sometime in 2016.

References

ESXi Embedded Host Client Flings page.

My talk on VMware Flings and the ESXi Embedded Host Client