Saturday, February 23, 2019

Year in Review 2018

I’m alive !!!! After a long winter I’m back blogging, I have no one to blame but me, I could give a lot of excuses about how life is hard, changes on my personal and professional life and blah blah blah, but it won’t change the fact it has been 5 months since my last post.
Let’s dust off those skills and starts with my classical year in review post, even though it’s February already : (

Producing only 16 posts this past year is not a surprise none of them made it to the top 10, it might be search engines are ranking me low or I lost my faithful followers ; )

Generating 43,335 pageview, the traffic is coming from all around the world, 154 countries, US alone being 30% of all my traffic.

It’s amazing how my post about Converter is back to #1, did you run a physical to virtual project last year, please, let me know !!!

Here’s the full list:

#4. VMFS Version – VMWARE Datastore (not ranked last year)
#7. How access NSX through APIs (not ranked last year)
#8. Year in review 2017 (not ranked last year)

I think the only way now is up…let’s get this year starts for real

Thursday, September 6, 2018

vRealize Automation – Highly Available Directories Management

One of the most appealing feature of any application/solution is it’s ability to provide higher levels of availability and resiliency, it becomes even more important when the solution in question places a critical role in your business, like a self-service portal where your clients request any kind of service and been server almost instantly providing agility and faster time to market value to your business.

vRealize Automation, when configured in a highly available deployment, provides this level of availability, enabling clustered services for all it’s components, but there’s one piece of the solution that is common over looked, Directories Management.

As a Tenant administrator, it’s pretty common to configure a directory over LDAP to provide user’s authentication, this way your users could benefit from using it’s already familiar user’s id and password to authenticate into the portal.

The support of user’s authentication in vRA is made through the use of connectors, each vRA appliance is a connector itself, but typically only one connector is configure to perform directory synchronization.

In order to provide Directories Management in high availability you must configure a second connector, with this configuration if one appliance fails the second one takes over the management of user’s authentication.

To configure a second connector, go to Administration / Directory Management / Identity Providers and click on the specific provider.

Click add connector and select the additional connector, make sure both connectors are enabled.
Last piece is to change the IdP hostname to point to your’s vRA VIP address.

Please, be aware that this configuration should be done on each Tenant.
Have you been configuring your Directories Management in high availability ?

Thursday, August 23, 2018

Additional Charges Missing

vRealize Business for Cloud is a great tool for Cloud cost analysis and price visibility details, more and more as companies mature its operational mode it becomes imperative the ability to control its costs and be transparent with end users.

There are situations where additional charges might need to be applied in order to form a more complete pricing policy, I covered it some time ago using vRealize Automation tags;
Last week I was taking the same approach but using vSphere tags instead, my client does not have vRA yet, but for some reason, the charge has not been applied the VMs.

Let's dig deeper into how did I configure this;
On vSphere, I created a tag Category called  "Aplicação" (it's the Portuguese word for application) and some other tags for specific software licenses, all tied to the "Aplicação" Category.

 The VM has been tagged with the appropriate License tag;

Also, my pricing policy was set up to include an additional charge based on the vSphere tag

To make sure vRB was receiving the inventory information correctly I ran the VM Configuration report;

and indeed vRB was identifying the tag on the VM properly.

Everything was configured correctly !!!

Time for a deeper troubleshoot;
vRB does the collection from vCenter and caches the results on its own internal database for faster operations, while checking the collection logs we found that vRB was messing with the fancy Portuguese letters ("ç" and "ã") and caching a weird word instead, so when comparing the values for the pricing policy, they don't match and so the additional charge was not applied.

The workaround was to create tags without those characters or even special ones. This behavior was found on vRB 7.4, so if your idiom uses fancy characters as well be aware of this.
I do have an issue open with VMware for fixing this bug.

Let me know if you faced it too and what idiom were you using.

Tuesday, July 24, 2018

ESXi host upgrade failed - 0x8b in position 513

Most of my time as a Consulting Architect at VMware Professional Services I spend with clients, helping them to create innovative solutions, overcoming challenges, etc.
Since every environment is unique, sometimes I stumble to some weird situations, this past week was one of them.

The client was upgrading their ESXi hosts from version 6.0 to 6.5, while the majority of the hosts went smoothly, a couple of them presented some undesired behavior.

Update Manager was used to remediate the hosts, everything was going fine, the patches have been staged and the first reboot occurred as expected, but during the installation, it crashed with a blue screen and an error message:

An expected error occurred

See logs for details

UnicoDecodeError: ‘utf-8’ codec can’t decode byte 0x8b in position 513: invalid start byte

(I'm sorry about the image quality, I was in a hurry trying to figure it out)

And then the installation rollback automatically to ESXi 6.0
Surprisingly all hosts were the same model, installed at the same period, the same way with the same ISO, so there’s nothing special about those hosts we could think off.

After some basic troubleshooting nothing pops up and an internet search for this error did not return anything relevant.
Time to search internally, VOILA ….that’s when I found a couple of past cases with the same behavior.

Long story short, the altbootbank for some reason was corrupted, we never found out why.
The solution was to recreate the altbookbank from the bootbank partition.
First, we got rid of the content in /altbootbank and then we copied the content from /bootbank to it.

Wait a minute, what /altbootbank and /bootbank is all about ?

ESXi keeps two independents copies of its boot partition, bootbank and altbootbank. One of them will have the active image, bootbank, which is used to boot up the system and the other one will have an alternate image, altbootbank, you can imagine that as the last good known state, so in case your boot partition becomes corrupted you can reboot your host from the last good know state (altbootbank).

It really took me a while to figured out how to solve it. I’m publishing it hoping it can save some of your time too, just let me know if you faced this issue too.

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive