Forward vCenter Server Appliance Log Files to Remote Syslog Server

A few days ago I was required to obtain some audit logs from our SIEM system (Sumologic) and from vCenter and I noticed that our vCenter logs weren’t going in to Sumologic and that the log files required for SSO auditing or the VPXD log (where, among other things, stipulates what client was used by who to connect) were rotating every 7 days. This was not good. So I decided what better time than now to forward vCenter syslogs to Sumologic.

It was a little more complex than just enabling syslog through appliance management as by default, this does not collect the SSO logs, like:

  • /var/log/vmware/sso/ssoAdminServer.log – Auditing SSO logins
  • /var/log/vmware/sso/vmware-identity-sts.log – Auditing SSO user changes

I found this out by scouring the internet and piecing little pieces together and eventually, creating a rock solid syslog source for our vCenter Servers.

Please note: This is not an officially supported configuration by VMware and for larger environments, this could potentially have an impact on the vCenter Server service, so please take caution in the logs you decide to forward. And as always, test this in a lab first.

I also want to mention that this needs to be done on each VCSA instance, i.e. if you have a vCenter with an External PSC, this would need to be done on both servers, in order to collect all the logs.

So, lets begin:

Continue reading Forward vCenter Server Appliance Log Files to Remote Syslog Server

Upgrading VCSA 6.5u1 to 6.7

Murphy’s Law, just as I upgrade to  6.5u1, 6.7 gets released. So, I am going to do an upgrade in my lab so I can start playing around with all the cool new features.

Before moving on, it is HIGHLY recommended you read through the following VMware articles:

Also, as a prerequisite, and mentioned in the 6.0u3 to 6.5u1 upgrade,  I recommend moving all systems to a single host, disabling DRS (or setting it to manual) and performing a snapshot of the VMs.

The upgrade path also seems identical in the sense that you need to do ALL PSCs FIRST then do the vCenter. But you might have additional VMware systems, so please follow the Update sequence for vSphere 6.7 and its compatible VMware products (53710) article.

Continue reading Upgrading VCSA 6.5u1 to 6.7

Upgrading VCSA from 6.0u3 to 6.5u1

After about 6 months of planning and preparing for our VCSA upgrade, we had to completely revamp our upgrade path.  In our environment, we use Netapp, and along with Netapp comes some extension like Virtual Storage Console (VSC) and now, the new Netapp Snapcenter.

I spent a lot of my time planning the deployment for an upgrade of our environment which included a upgrade of VSC from 6.2.1 to 7.0 and the install of SnapCenter 3.0, not wait, 3.1, no wait 4.0.

Yes, that’s right, SnapCenter released 2 version in the time of my upgrade planning and it still couldn’t to what needed it to do, mainly cross-domain authentication, so, we had a little shout at our account manager who confirmed cross-domain authentication will be available in August 2018, so lets see what happens. So, this process is still required, however, this made the upgrade a lot easier.

Continue reading Upgrading VCSA from 6.0u3 to 6.5u1

Configuring NFS networking for a nested ESXi VM

I have just begun planning and building a lab for my ESXi / vSphere environment so that I can do a upgrade of our vSphere environment (more to come on this process), but I got stuck with an issue for NFS storage. The issue was that I could not mount the datastores on the nested ESXi host, I was not able to find any clear information quickly on the web, so I decided to do a “settings” process here.

A brief background of the environment:

  • Networking: Cisco 3850, with Trunk VLAN configured.
  • Storage: NetApp cDOT with NFS volumes
  • ESXi Version: 6.0U3

The important changes are in bold below and the reasoning is VERY well outlined in this “ancient”, yet 100% valid post by William Lam: Why is Promiscuous Mode Forged?

Continue reading Configuring NFS networking for a nested ESXi VM

Resetting vSphere 6.0 Password

So, its been quite some time since my last post, dealing with personal issues and the festive season and and and, so, here I am, back in 2017 and hopefully bringing awesome content.

So, lets kick it off with resetting the vSphere password. This works on the vCenter, an external Platform Service controller or an AIO system.

The reason behind me doing this is due to the password expiring and someone resetting it and not recording it in our password management software.

Requirements:

A Live boot ISO – I used this one: ADRIANE-KNOPPIX_V7.2.0gCD-2013-07-28-EN
Console access to the VM you want to reset.

Caveats:

Be sure to have ESXi host access to the host where these VMs reside as the VMs WILL require a reboot, meaning your entire vCenter will be offline for the during of this password reset.

Let’s begin:

I assume you have some basic ESXi / vSphere knowledge so I will not go in to how to do simple things like mount the ISO – I will continue from the boot process.
Boot from the ISO, till you reach

Continue reading Resetting vSphere 6.0 Password

Clone Datastores from one ESXi host to Another

As we I progress with our server refresh and I continue to build our global virtualised infrastructure, I am constantly trying to make things easier for my less experienced colleagues and so that there will be consistency in what we do. One of the most tedious tasks must be NFS datastore creation. While we could script this out and create each datastore individually, I figured I would try find a way clone the datastore configuration from one host to another. This way you simply execute the script and let it run along, giving you time for other cool stuff.

This little script will save you hours, especially if you have hundreds of datastores and hosts.

Script 1: This is for host to host clone only

$Source_Host = Read-Host "Enter The Source Host"
$Destination_Host = Read-Host "Enter the Destination Host"
$Source_Root_Password = Read-Host "Enter Root Password for Source Host"
$Destination_Root_Password = Read-Host "Enter Root Password for Destination Host"
Connect-VIServer -Server $Source_Host -User root -Password $Source_Root_Password
Connect-VIServer -Server $Destination_Host -User root -Password $Destination_Root_Password
foreach (
			$datastore in (Get-VMhost $Source_Host | Get-Datastore | where {$_.Type -eq "nfs" -and $_.Accessible -eq "true"})
		)
		{
			New-Datastore -VMhost $Destination_Host -Nfs -Name $datastore.Name -Path $datastore.RemotePath -NfsHost $datastore.RemoteHost
		}
Disconnect-Viserver * -Confirm:$false

Script 2: This for host to Cluster wide .

$Source_Host = Read-Host "Enter The Source Host"
$Destination_vCenter = Read-Host "Enter the vCenter you want to connect to"
$Cluster = Read-Host "Enter the name of the Cluster to connect to"
$Source_Root_Password = Read-Host "Enter Root Password for Source Host"
Connect-VIServer -server $Source_Host -user root -password $Source_Root_Password 
Connect-VIServer -server $Destination_vCenter
foreach (
			$datastore in (Get-VMhost $Source_Host | Get-Datastore | where {$_.Type -eq "nfs" -and $_.Accessible -eq "true"})
		)
		{ 
			Get-Cluster "$Cluster" | Get-VMhost | New-Datastore -Nfs -Name $datastore.Name -Path $datastore.RemotePath -NfsHost $datastore.RemoteHost
		}
Disconnect-Viserver * -Confirm:$false

Copy the above text in to a text document and save it as a ps1 (powershell) file and run it using PowerCLI.

Scripted configurations of SNMP v2

Today I went through the process of scripting the configuration of SNMP configurations for multiple OS/devices. The reason for this is that there has never been a formality or standardisation of this and sometimes we tend to forget this and or that. So, in case you would also like to script it, here is what we use.

The defaults:

sysLocation:
For this, you could either use “3rd floor, of some office” or, if you are a global company, with  monitoring system that makes use of the GoogleMaps API (e.g. Observium) and would like to show various location globally – use a google API name – e.g. London, UK or Cape Town, South Africa etc.

sysContact:
This could be a name or an email address or telephone number

Community:
Something that is configured on your server and on your device/workstation/server that allows communications. There is also a permission set that will get applied to this.

target:
This is the place you are sending information to

port:
This is by default, 161/UDP, unless you change it.

Continue reading Scripted configurations of SNMP v2

Creating vSwitch Names for new vSwitches on ESXi Hosts using Host Web Client

A little while back, I wrote on Changing your vSwitch Names on ESXi Host.  I found another way to do this, but unfortunately, this method ONLY works for NEW vSwitches.

Once the vSwitch has been created, you cannot change the name to something else. If you made a mistake and need to change it, you would need to either:

a. Removing the vSwitch and recreating it
b. Doing the Changing your vSwitch Names on ESXi Host option.

login
Login to the ESXi Host directly – https://ip-or-hostname/ui/ (note the trailing “/” after ui)

Continue reading Creating vSwitch Names for new vSwitches on ESXi Hosts using Host Web Client

Changing your vSwitch Names on ESXi Hosts

So, yesterday I thought to myself, hey, wouldn’t it be cool if we could change the names of the vSwitches on ESXi hosts. That way, it will quickly allow any one to see the different categories of switches – e.g. storage/management etc.

Turns out, this is possible. Thanks to a little bit of “hacking”, you can change the names of your vSwitches.

 

Continue reading Changing your vSwitch Names on ESXi Hosts