Ladies and Gentlemen of VMworld 2019.
Wear comfortable shoes.
If I could offer you only one tip for the conference, comfy shoes would be it.
The long term benefits of comfortable shoes have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience…
I will dispense this advice now.
Enjoy the knowledge and learning imparted at the breakout sessions; oh nevermind; you will not understand all the knowledge and learning imparted until you watch the recordings.
But trust me, in 20 years you’ll look back at your notes from the event and recall in a way you can’t grasp now how much technology lay before you and how fabulous that UI really looked…
You can’t fit in as many parties as you imagine.
Do one thing everyday that scares you.
Present a session.
Don’t ignore other people’s opinions, don’t put up with people who ignore yours.
Talk to people.
Don’t waste your time on free pens;
Sometimes there’s T-shirts,
Sometimes there’s LEGO.
The swag list is long, and in the end, it’s only what fits in your suitcase home that counts.
Drink plenty of water.
Maybe you’ll do the Hackathon, maybe you won’t, maybe you’ll watch a vBrownbag, maybe you won’t, maybe you’ll get an early night, maybe you’ll dance the funky chicken at the VMworld party.
Whatever you do, don’t worry too much when someone says on-premise.
Enjoy your time at the conference, Use it every way you can… Don’t be afraid of doing new things, or what other people think of them,
Spending time wisely is the greatest investment you’ll ever make…
Use that Early Bird pricing, you’ll miss it when it’s gone.
Be nice to your peers in the vCommunity; They are the best way to learn and the people most likely to stick with you in the future
Go to VMworld US once, but leave before it makes you hard;
Go to VMworld EU once, but leave before it makes you soft.
Accept certain inalienable truths, vBeards will grow and turn grey, vendors will talk FUD, you too will get tired, and when you do you’ll fantasise that when you were younger vChins were clean-shaven, vendors were noble, and the flash client was the best thing since sliced bread.
But trust me on the comfortable shoes…
For several years vSphere admins have been able to use the Log Insight tool for free as a “25 OSI” license was included in vCenter. This has meant that deployments of up to 24 hosts (plus vCenter) have been able to use the VMware tool as a syslog server and troubleshooting tool without having to purchase further licenses.
Due to changes in licensing this is no longer possible- see KB55980: vRealize Log Insight for vCenter Server – End of Availability (EOA). Version 4.6.x of Log Insight was the last to support this free license. This KB was released summer 2018, but now (spring 2019) it’s becoming particularly relevant because of the release cycle of vCenter.
vCenter 6.7 Update 2 has recently been released, and using the VMware product compatibility matrix you can see that this requires existing Log Insight installations to be upgraded to 4.8 as Log Insight 4.6.x (and therefore the “free” license) is not compatible. So be aware, without proper preparation patching your vCenter can break your established log management environment.
To keep running Log Insight in this environment it will be necessary to now purchase separate licenses from VMware. Talk to your re-seller or VMware account manager about this as there are options for both replacing the OSI licensing model or switching to a per-CPU model which would also enable the product to collect logs from any number of guest VMs on the licensed hosts.
In the process of upgrading a vSAN ReadyNode cluster from ESXi 6.5 to 6.7 a warning appeared in the vSAN Health check. The first host in the cluster had gone through the upgrade and was now showing the warning “Controller driver is VMware certified” (Note 1 in the image below, click on it for a larger view). The Dell HBA330 card was using an older version of the driver (2 in the image below) than recommended (3).
All workloads were still online, but running VMware Update Manager (VUM) did not clear this warning. Looking in the VUM patch listing showed the driver for ESXi 6.5 (4) but not the version recommended for 6.7.
It was necessary to manually load these replacement drivers in. A quick google showed they could be sourced from VMware’s download site. Extract the ZIP file from the download and then use the “Upload from File” option in VUM (5) to upload the ZIP file which was inside (in this case “VMW-ESX-6.7.0-lsi_msgpt3-17.00.01.00-offline_bundle-9702440.zip“). The new driver should then appear in the list (6) and will automatically be added to the “Non-Critical Host Patches” baseline (7). Final remediation is now just a case of applying that updating baseline to the host.
In this particular instance the hosts were Dell PowerEdge R630 vSAN ReadyNodes with the HBA330 SAS HBA Controller option but the principles outlined in this post should apply to other configurations with the same symptoms.
If you’re running VMware vCenter and ESXi 6.0 it’s time to start planning to upgrade as General Support ends on 12 March 2020- one year from now and five years from it’s release. Thankfully the upgrade from 6.0 to 6.5 or 6.7 is usually quite straightforward, and VMware have put a lot of work into streamlining this process.
Looking at the Product Lifecycle Matrix other notable products in the VMware stable worth keeping an eye on include NSX for vSphere (NSXv) 6.2, Site Recovery Manager (SRM) 6.0 and 6.1, and vSAN 6.0-6.2.
A powered off VM on ESXi 6.5 will not power on and returns the error “Failed to power on virtual machine…. The attempted operation cannot be performed in the current state (Powered off)”.
(i.e. the VM cannot be powered on BECAUSE it is not powered on!)
Prior to being powered down the VM properties had just been modified. In this particular case it was immediately following a manual Ubuntu install and the install DVD (from a datastore ISO) was disconnected and the CD Drive switch to” “Host Device”. These operations were performed from the ESXi Web interface.
Repeated attempts to start the VM all fail the same way.
Unregister the VM, then locate the vmx file in the datastore and re-register it. The VM should now power on.