Got VMware vRealize Log Insight?

Recent conversations with existing and potential clients made me realize that many are not aware that they most likely are entitled to use VMware vRealize Log Insight in their environment. For free.

Back in March 2016 VMware announced that everyone with a valid VMware vCenter license are also entitled to  25-OSI pack of vRealize Log Insight for vCenter Server. This means that you can gather logs for up to 25 ESXi hosts, VMs or other devices, in your environment.

It even allows you to use the following VMware content packs (3rd party content packs requires a full Log Insight license)

  • Horizon View
  • NSX
  • OpenStack
  • vCenter Operations Manager
  • vCloud Automation Center
  • vCloud Director
  • vCNS
  • Virtual SAN
  • vRealize Automation
  • vRealize Operations Manager
  • vSphere

This should be a no-brainer for everyone with a >24 host VMware vSphere environment, the value that vRealize Log Insight provides is enormous, especially when it comes to troubleshooting. Why 24 when you get a 25 pack you may ask? Well, you’ll want to use one of them for vCenter itself, leaving 24 for your ESXi hosts. If your environment is smaller than 24 hosts, the remaining OSI’s can be used to monitor just about anything that can log to a syslog service, like switches, routers and other devices.


So, if you’re not running it already, logon to and download it today — you can then use your existing vCenter license to activate it. You’ll be drinking from the log-hose in no time.


#vDM30in30 progress:

VMware vSAN: 2016 Edition

Both in 2014 and in 2015 I wrote pieces on the current status of VMware vSAN, and it’s time to revisit it for 2016.

My previous posts:

2014: VSAN: The Unspoken Future
2015: VMware VSAN: More than meets the eye.

vSAN 6.5 was released with vSphere 6.5, and brings a few new features to the table:

  • Virtual SAN iSCSI Target Service
  • Support for Cloud Native Apps running on the Photon Platform
  • REST APIs and Enhanced PowerCLI support
  • 2-Node Direct Connect
    • Witness Traffic Separation for ROBO
  • All-Flash support in the standard license (Deduplication and compression still needs advanced or enterprise)
  • 512e drive support

In my opinion, the first three items on that list are the most interesting. Back in 2015 I talked about VMware turning vSAN into a generic storage platform, and the new Virtual SAN iSCSI Target Service is a step in that direction. This new feature allows you to share vSAN storage directly to physical servers over iSCSI (VMware is not positioning this as a replacement for ordinary iSCSI SAN arrays), without having to do that through iSCSI targets running inside a VM.

The same goes for Cloud Native Apps support, where new applications can talk with vSAN directly through the API, even without a vCenter!

Both of these bypass the VM layer entirely, and provide external connectivity into the core vSAN storage layer.

Clearly these are the first steps towards opening up vSAN for external usage, expect to see more interfaces being exposed externally in future releases. An object store resembling Amazon S3 doesn’t sound too far fetched, does it? Perhaps even with back-end replication and archiving built-in. Stick your files in a vSAN and let the policies there determine which object should be stored locally, and which should be stored on S3? Or which should be replicated to another vSAN cluster, located somewhere else?

Being able to use SBPM for more than VM objects is a good idea, and it makes management of those non-VM workloads running in your vSAN cluster easier to monitor and manage.

Sure the rest of the items on the list are nice too, the two 2-node Direct Connect feature allows you to connect two nodes without the need for external 10 GbE switches, cutting costs in those scenarios. All-Flash support on all license levels is also nice, but as is the case with 512e drive support, it’s natural progression. With the current price point on flash devices, the vSAN Hybrid model is not going to get used much going forward.

All in all, the vSAN 6.5 release is a natural evolution of a storage product that’s still in it’s infancy. That’s the beauty of SDS, new features like this can be made available without having to wait for a hardware refresh.

#vDM30in30 progress:

VCSA – The default choice. Always.

I’ve been a big proponent of the VMware vCenter Appliance for a long time, I even did a talk called VCS to VCSA Converter or How a Fling Can Be Good for You! on migrating to the VCSA at the Nordic VMUG last year.

The VCSA has gone through a few iterations and versions by now, coinciding with the vSphere releases.


vCenter Server Appliance 5.0 August 2011
vCenter Server Appliance 5.1September 2012
vCenter Server Appliance 5.5 September 2013
vCenter Server Appliance 6.0 March 2015
vCenter Server Appliance 6.5 TBA

Since v6.0 scaling has been on par with it’s Windows based counterpart, supporting the same number of  hosts and VMs.

When it comes to features, VCSA 6.5 surpasses the Windows version. New tools like the Migration Tool, vCenter High Availability, Backup / Restore and the new Management Interface are all exclusively available on the VCSA.

In my opinion, the most noteworthy of these are vCenter High Availability and the Backup / Restore options.

vCenter High Availability adresses one of the main concerns with vCenter in general since the discontinuation of vCenter Server Heartbeat in June 2014. This new HA setup enables you to have a passive VCSA ready if your active one should fail, with the added protection of a witness that keeps track of it all. This is a native feature of the VCSA, and not available in it’s Windows counterpart (or little brother as it is now…)

The Backup / Restore feature is very nice as well. One of the (few) arguments I’ve heard surrounding running the VCSA vs the Windows vCenter is surrounding backup. Thankfully the myth regarding image level backups of it was debunked in v6, but the new backup / restore functionality takes that a step further. Native backup is now available in the VCSA, either via the management interface or via a public API. The backup files (HTTP(s), FTP(s), and SCP transfer protocols are supported) make up the entire VCSA configuration, and you can restore those directly from the VCSA 6.5 ISO image in case of an emergency. This means that you can image level backups of the VCSA as usual, and script the backup file generation as added protection.

Also worth noting is that in v6.5, VMware Update Manager has been included in the VCSA, and runs natively on the appliance. The last argument for keeping your Windows vCenter has just disappeared.

With the upcoming vSphere 6.5 release it’s clear that the VCSA should be the default deployment model for a new vCenter. There is really no question about it anymore. #migrate2vcsa you should.

#vDM30in30 progress: