As promised I’ve been chipping away at the VMUG Wiki. I’ve spent the last couple of weeks updating the vCenter chapter based on the Windows edition. I say weeks, in truth I spend a couple of hours each week on the Wiki, just fitting it in around my other interests that are focus of my gap year. I’ve been toying with recording the “sets” that I’m “touring” (more grand term, than it really implies) around various acoustic sessions in my local area. The other week someone said I should go to Sheffield and put myself up on stage all mic’d up and plugged in. Not sure I’m quite ‘seasoned’ enough for that yet! But perhaps I might record each monthly set and put it up on SoundCloud for those who are interested.

ANYWAY. Digression. This post is supposed to be about the VMUG Wiki. So the main “news” is the chapter on the Windows vCenter setup is completed and live – you can find it here:

Install VMware vCenter (Windows)

To any old hands here. There’s isn’t much to report in the “What’s New” stakes – but there were a couple of notable changes which I thought I’d bring to people attention.

Platform Services Controller

You’ll probably know that vCenter 6.0 has this “new” Platform Services Controller or PSC. The Stephan Fry like speech-marks are deliberate, as I’m not really that sure what’s significantly “new” about this development. The PSC term seems more of tidying up exercise in bring together a collections of various services that support the core VPXD (or vCenter Server Service). Since the arrival of VMware Signal-Sign-On there’s been this model were each vCenter “instance” is unique, but can “share” other components – the key one being SSO. My model for writing about this remains the same. Two Site (New York and New Jersey) each with their own vCenter ‘instance’ but ‘sharing’ single Microsoft Active Directory “Domain” as well as a single VMWare SSO Domain. There are as many flavours of this as there stars in the sky. I’m probably not alone in feeling like many that this SSO service has brought people more woes than happiness, and often feels like distraction from the main “management” benefits of vCenter. It strikes me most people will opt for the embedded option rather than what feels like an over-complicated distributed model which then introduce availability concerns and load-balancer requirements – all to just manage your VMs.

 Windows supports Postgres

One thing I was pleased to see is the Windows version of vCenter does now support the Postgres DB. Setting up the Windows vCenter with an external database is something I’ve been doing since version 1.x – and its always been complete bore/chore to go through the hoop-jumping exercise which is meeting all the Windows dependencies (Services Packs, Drivers, and DSNs – you know the usual b******t that accompanies any Windows deployment of any product!). This postgres support in designed for very small environments (20 hosts and 200 virtual machines) that cannot use the Linux/Appliance version of vCenter. So it might be of interest to homelabbers (like me) or people doing demo’s where they need the Windows version but want to spare themselves the agony of Microsoft SQL permissions…

Lockdown Mode – Strict

The other thing I discovered is “Lockdown Mode” has new setting called “strict”. As you most likely know “lockdown mode” allows you to restrict access to the VMware ESX host by the classic “vSphere Client” as well as some other access mechanisms such as SSH and the Direct Console UI (DCUI). Previously, lockdown mode would block direct access to host via the vSphere Client and SSH, however, if you possessed the “root” account for host – and could access the host physically or via BMC style connection – you could still get to the DCUI and enable the DCUI shell to get an interactive command-line prompt on the host. The new “strict” mode prevents even that. So the only way to manage the host via vCenter (thus ensuring only SSO or AD authentication is allowed). I guess this extra tightening of the screw will be of relevance only to folks who demand this kind of security. Most people actually appear to weaken the security of the VMware ESXi host by enabling SSH – because its so convenient to have that access for troubleshooting purposes. As ever these settings remains a compromised between security versus ease-of-use.

Optional Stuff…

The other change I saw is how other optional services are now handled. Previous version of vCenter have had a couple of optional mini-services such as a Dump Collector and Syslog Collector (I say optional, but sometimes these are mandatory – such as if you boot from USB/SD-CARD you need to redirect the VMkernel Dump which normally happens at PSOD – because there’s not enough storage to save the dump to local media). You used to have to setup each of these service individually, and each one would have its own install routine together with configuration. That seems to have been dumped (if you forgive the pun!) in favour of just installing them and then leaving the admin to either complete the post-configuration (such as using ESXCLI or PowerShell to make the host(s) aware of these services) or edit XML file that change the configuration of the service. Typically, the Dump and Syslog Collectors store their files in some Progman location on the C driver (never go place to store anything IMHO), so at the very least you’d want to change these default paths to some other location. There’s no handy single image that summaries this change in a blog friendly manner – so if you are interested (and that’s a big IF) you could toddle off to here on the VMUG Wiki:

http://wiki.vmug.com/index.php/Install_VMware_vCenter6_(Windows)#Configuration_Other_vCenter_Services

The only really interesting thing is the fact that VMware ESXi still supports method of forcing a PSOD on demand. When I first started working with VMware ESX 2.x – these were a bit of “unicorn” thing for me. I’d heard of them, but never seen one before – so a part of me doubted their existence (I mean PSODs, not unicorns – I know unicorns exist along with the fairies at the bottom of my garden!). You can do this using the command:

vsish -e set /reliability/crashMe/Panic 1

How long this will remain in VMware ESX, and its of concern to you – then perhaps you do need that strict lockdown mode after all?

Screen Shot 2016-02-23 at 12.44.10