Category: vSphere

vSAN deployments in brownfield environments are simple. New hosts are configured based on projected workloads (plus points for utilising vSAN Ready Nodes), they’re purchased, racked, built, and absorbed into an existing vCenter workload domain before vSAN is finally enabled and configured. But how would we deploy vSAN into a greenfield environment? An environment with no vCenter, no shared storage, but only brand new ESXi hosts with valid (yet unconfigured) cache and capacity vSAN disks? As vSAN is reliant on vCenter for its operations, we seemingly have a chicken-and-egg scenario.

In this article, I detail the process of deploying (Stage 1) and configuring (Stage 2) a vCenter Server Appliance into a greenfield environment and, more specifically, onto a single-node vSAN cluster in hybrid-mode (Note – this is in no way supported by VMware for anything other than deploying vCenter and vSAN into a greenfield environment). I then add additional hosts to the cluster and configure vSAN storage and networking via the brilliant Cluster Quickstart tool (Stage 3), before applying a vSAN VM Storage policy to the vCenter Server Appliance (Stage 4). Once complete, our vSAN cluster will be ready to host live workloads.

Patching my lab’s vCenter Server Appliance this evening raised an issue whereby the root password had expired. Unable to login via root, I can still administer the appliance via a vCenter’s SSO domain account (administrator@vsphere.local, for instance), however, attempts to perform any updates will not be possible until the appliance’s root account password is reset. This an easy exercise, however, this is not possible via vSphere UI or console, only bash.

Following a recent upgrade of VMware NSX Data Centre for vSphere from 6.4.1 to 6.4.4, the option to access NSX’s Networking and Security extension from within the vSphere Client (HTML 5) had simply disappeared. This left me scratching my head a little, more so as I’ve completed this upgrade (what seems) a million times.

Scenario-wise, I had completed the initial NSX Manager upgrade, but after logging in to the vSphere Client, I noted the Networking and Security extension failed to display.

Yesterday, Tuesday 16th October saw the much anticipated release of VMware’s vSphere 6.7 Update 1, however, shortly after the announcement a number of Veeam users decried the release due to compatibility issues with Veeam’s Backup & Replication suite. None other than Veeam’s Anton Gostev first announced the issue with the below tweet:

Looks like vSphere 6.7 Update 1 completely breaks backups, so please avoid updating until further notice. I must say I really miss those times when we didn’t even have to test vSphere updates, and literally supported them by default because they never broke anything – for years!

The very next day the Veeam team announced a workaround in the form of Veeam KB2784, as well as ‘out-of-the-box’ support being included with highly awaited (and much delayed) next release, Update 4.

vSphere 6.7 U1 compatibility issue has been researched, and the simple workaround is now available for use in test labs. Official out-of-the-box support for vSphere 6.7 U1 will be included in Update 4. See this Veeam forums topic for more details > https://t.co/BNgMNWDOmS

Where the fault lies with such release/compatibility issues is not the goal of this post (which Twitter seems to be more focused on). However, with a high number of pros likely raising internal changes to upgrade their vCenter(s) and ESXi hosts, you’ll want to implement the Veeam workaround in-line with this upgrade, as well as a number of solid backup/restore tests.

Not only will this year mark my first ever visit to VMworld Europe, I’ll also be taking part in a Customer Panel session.

If you are interested in hearing my VMware NSX Data Center journey, how we implemented and operationalised NSX; how NSX continues to increase security and application performance, while simplifying troubleshooting and improving network provisioning time, then join me on Thursday, 8th November at 12:00-13:00 to hear more.

With the release of vSphere 6.7 back in April 2018, a host of new enhancements, features, and goodies had the vCommunity going wild. With enhanced feature parity between the legacy vSphere Web Client and new HTML 5 vSphere Client, as well as the vCenter Server Appliance boasting performance increases of ~2X faster performance in vCenter operations per second, ~3X reduction in memory usage, and ~3X faster DRS-related operations (e.g. power-on virtual machine); these two areas alone made most of us want to upgrade. Nice.

vSphere 6.7 also boasts the new Quick Boot feature for vSphere hosts running the ESXi 6.7 hypervisor and above. This feature allows users to a) reduce maintenance time by removing the number of reboots required during major version upgrades (Single Reboot), and b) allows users to restart the ESXi hypervisor without having to reboot the physical host (essentially skipping the time-consuming hardware initialisation). Very nice!

Thursday 14th June saw the latest London VMUG take place at Tech UK, London, with the User Group marking it’s third outing for 2018 in just six months! Rarely does any event see such heavy hitters as Duncan Epping, Frank Denneman, and Niels Hagoort in one place, but today, we got to see all three in attendance. Add to that line-up further awesomeness in the form of vCommunity member, Chris Porter, and this was one truly great London VMUG indeed! I’ve been to a number of VMUGs around the UK, however, this was to be my first time joining the London gang.

By design, there are certain virtual machines and/or appliances within vSphere which are protected to prevent editing (this can include NSX Controllers, Edges, Logical Routers, etc.) In a live/production environment, you’d not normally care about editing these appliances, however, in a lab environment (especially one where resource is tight), reducing memory and/or CPU allocation can help a lot. As such, this article will cover the process of removing the lock on protected VM in vSphere, in order to enable editing.

The scenario: a customer needs to reduce the resource allocation of an NSX Controller, however, due to the VM in question being protected/locked, editing the VM’s resources is not possible via UI or PowerCLI.

The process of removing this lock is quick and easy, however, we first need to identify the virtual machine’s Managed Object Reference (moRef ID). Please note, VMware do not support or recommend this procedure in any way. As such, this procedure should not be implemented in a production environment.

In Part 1 of this series we covered the simple installation and configuration of VMware vRealize Log Insight. In Part 2 we will cover how we can further configure and customise Log Insight via Content Packs in order to leverage further logging capabilities.

As mentioned in Part 1, one of the caveats of utilising this ‘free’ version of Log Insight (or more aptly, the 25 OSI license available to all vCenter Server licensees), is the ability to use VMware-only Content Packs. This is far from a bad thing and, as a result, enables us to integrate with other VMware products including NSX, Horizon, SRM, etc. In this article we will focus on the former product.

If, like most of us, you forward vCenter and ESXi host Syslog data to centralised Syslog targets (and if you don’t, then I’d advise you do), then you’ll be pleased to hear that (as long as you have a valid vCenter Server license) you’ll be able to utilise the power of VMware vRealize Log Insight to interrogate this data.

This article will be the first in a two part VMware vRealize Log Insight series, the first of which will detail the simple installation and configuration process, with the second article focusing on advanced configuration and integration with VMware NSX via vRealize Log Insight Content Packs (vRealize Log Insight add-ins enabling further integration with both VMware and 3rd party products).