Wednesday, 27 July 2016

vSphere Upgrade 5.0 to 6.0 - Part 3

vSphere Upgrade 5.0 to 6.0 - Part 3


This is the list of services I found on 5.0 from vCenter (top) and SRM (below):


Check you've stopped them all - then we can proceed to SQL. Start by backing up the three SQL Databases to a handy location (I've used C:\Temp):
Next, configure the backup for each as follows, giving each a different name:
Then you should end up with the following files:
Copy them to the new SQL 2014 server:
Restore the Databases one at a time by choosing the "Device" option and browsing to the file:
Do this operation separately for each Database:
Then when they are restored you can edit each to change the compatibility from 100 to 120:
Finally recreate the SQL logins if you are using those or grant permissions to the domain service accoutns if not. Assign DB ownership etc as before. We have to install vCenter before we can recreate the rollup jobs for SQL Agent. 

Next go to the new vCenter and configure the DSN's for vCenter and Update Manager and test the connection for each of them:
Both components are still not 64-bit in this edition of vCenter, see below. Note that the Native Driver is used NOT the ODBC one for SQL 2014:

Now, let's try installing vCenter 6.0U2 and pointing it at an existing database and see where we get! 

So - this is new VM, Server 2012R2, DSN pointing at SQL 2014 SP1 but with restored copy of vCenter 5.0 Database, just to be clear!! 

Note: the vCenter 6.0 installer checks there are TWO vCPUs for vCenter, make any necessary adjustments to your lab. 

Here we go, install External vCenter:
Next confirm the vCenter system name: 
 Give it the Platform Services Controller FQDN:
 Click OK: 
 If you're using the right native driver you'll be able to pick the DSN and enter the credentials below:
 Now see what mess I've gotten myself into...!!!!
SO......this approach will not work. I'll have to perform a vCenter upgrade in place on Server 2008R2 and SQL 2008R2 and THEN perform the replatform and resql tasks afterwards.....darn it! Time to startup all those services again...! I'll cheat and just reboot the 4 legacy VMs..! Don't forget to clean up the databases on SQL 2014. 

Don't forget vCenter 6.0 installer checks for TWO vCPU so if you're using a lab increase them now. I've also increased the RAM to 8GB to ensure smooth sailing....

So here we are again....this time performing an in place vCenter upgrade on the old 2008R2 Server VMs: 

Once you run the installer it immediately recognises it's performing an upgrade:
 You select the external model and we've already our PSC's ready to rock and roll:
Enter the Administrator password and Click OK regarding the linked mode warning shown below:
 Enter the PSC FQDN and password:
 Click OK on the certificate validation warning:
 Make any changes you need to the destination paths, I'm in a Lab so I don't care...!!
 Tick the box and sign your life away......
Click Upgrade to process the VM and transform it to vCenter 6.0. This is a clean and pristine install of vCenter 5.0 so I'm not expecting issues but I've read about a few production systems that ran into difficulty so ensure you have good backups of EVERYTHING if you're doing this live. 
So we have a web interface we can log into and let's compare views before we upgrade our second vCenter 5.0:
 There is no sign of the other vCenter anymore in either view so linked mode is down until I upgrade the second vCenter.

So no sign of SRM plugin in the web interface of course, I checked the C# client after running the 6.0 client installer, it's still there but doesn't work. One thing I found was trying to login with "lab\administrator" fails but just using "administrator" worked fine. This was in both the Web and C# client. Probably something I need to fix in the SSO. Log in as administrator@vsphere.local to resolve. As you see there is no lab.local domain listed:
We need to define our AD domain here:
And here we add in the Domain Administrator account as a vsphere.local Administrator:
now, log out and test!

We can also upgrade the Update Manager at this point. 
 It knows this is an upgrade
 Use the FQDN always for SSL certificate use
 Enter the DSN password
 The default here is to NOT upgrade so change it
Ensure the FQDN is selected. The Download Service is an optional component for DMZ or air gapped situations, you're not missing anything with just the core Update Manager install here. 

If we take a look now in the Web and C# client we can see if both Sites are back again. This is using the PSC enhanced linked mode feature:
 The Web Client is ok but the C# client no longer shows the other Site as legacy ADAM linked mode is gone in 6.0 and you have to use the lovely, lovely web client (!) to manage both sides from here on in!!

Note: The configuration change to add in the domain admin user to SSO is only required once as we are using a unified SSO domain (!), so when you check it on Site B you'll see it already is there! 
























Thursday, 21 July 2016

vSphere Upgrade 5.0 to 6.0 - Part 2

vSphere Upgrade 5.0 to 6.0 - Part 2


This post takes up where we left off and we're ready to install a pair of Platform Service Controllers, we could do this anytime of course as 5.0 has no clue that SSO exists so we'll just spin these up and do the install ready for the vCenter upgrade itself.

Now is a good time to start using snapshots as I'm trying to figure out how to install the PSCs to get Enhanced Linked Mode working but use separate sites. They say in the KBs this is for load balancers which I'm not after so I'm wondering how this works out. My two installs were configured as follows:

This is the first PSC:
This is the second PSC: 
Now, you only get to name a site in the first PSC yet one architecture mentioned is as follows:


This is a bit annoying, I want the picture above, but how do I get it...?! Ahaa....when you run the install on the second one and click next, and move onto the NEXT SCREEN, you get this:

Now, we're talkin'! I've now got two defined Sites but a single SSO Domain for Enhanced Link Mode - brilliant! They are using self signed cert but we'll get that....!

So, now we're ready to proceed. I've found KBs on moving vCenter to a new Server, relocating the vCenter Database and the usual upgrade approaches but I've not come across anything that combines all of these while preserving settings, changing OS and dealing with security settings. So the question really is is it possible - yes, but how to do it reliably in the least number of steps. 

Note: I was using Remote Desktop Connection Manager 2.2 on windows 10 and after opening more than 5 or 6 connections my desktop would hang. I've upgrade to version 2.7 but lost all my configuration, so back yours up if you're facing a similar scenario! Mine works fine now....I am also getting huge peaks due to .NET security updates doing a optimization sweep after their reboot, so it's a matter of waiting patiently until that settles down.....I only gave my VMs a single vCPU so that's not helping! I'll have to save up for that second physical CPU!!

Now, back to those KBs:
Moving the VMware vCenter Server 4.x/5.x/6.0.x SQL database (7960893)

Updating rollup jobs after the error: Performance data is currently not available for this entity (1004382)

Migrating vCenter Server to a different host machine (5850444) 
(Note: This is for vCenter versions up to 5.5, it doesn't mention 6.0!!)

Manually backing up and restoring the VMware vCenter Server 4.x and 5.x ADAM instance data (1029864)

The first two deal with SQL, the third and fourth deal with vCenter and the linked mode ADAM database (although this is not used in vCenter 6.0). One advantage is we're using vCenter 5.0 which has no SSO to worry about, we've deployed clean and prestine PSC's so the next step really is to deal with vCenter itself. We need do to the following:
  • Upgrade from 5.0 to 6.0
  • Point upgrade at external PSC
  • Preserve all existing settings and Hosts, VMs etc
  • Replatform to Server 2012R2 - new host so new certificates will be required....!
  • Switch Database to new SQL Server - new DSN required here and recreate rollup jobs
  • Upgrade any components such as distributed vswitches, etc to 6.0 mode
There are some restrictions due to compatibility. For instance we know vCenter 5.0 doesn't support SQL 2014 so we can't do that bit until AFTER we upgrade to vCenter 6.0. 

One scenario I wondered about was if we move the database anyway and installed vCenter 6.0 would pointing it at that moved vCenter 5.0 Database trigger an upgrade? What else would we have to pre-copy over to do the install on the 2012R2 vm rather than install on 2008R2 on top of vCenter 5.0 and THEN move it?! 


So, to prep, we install the SQL Native Client from SQL 2012 SP3 Feature Pack, as the "Microsoft ODBC Driver 11 for SQL Server - Windows" doesn't work with VMware!!!:

This goes on both new vCenter Servers running Server 2012 R2. 

The last thing I will do with the old environment is to load up vCenter and check everything is working ok. In my case I'd forgotten to power up the Storevirtual lab so all my VMs appeared disconnected!! Dooh. I just want to make sure I'm coming from a stable environment before shutting things down and performing partial upgrades. 

So, I've created an Update Manager baseline, added a 5.0.0 distributed vSwitch attached to a spare virtual nic on my nested esxi hosts and checked SRM is ok and now we're good to go! 

So, to begin with I'll stop all the VMware services on the legacy vCenter and SRM VMs. then move the vCenter and Update Manager databases to SQL 2014. Stay tuned for my next post and I'll let you know how I got on!



Wednesday, 20 July 2016

vSphere Upgrade 5.0 to 6.0 - Part 1

vSphere Upgrade 5.0 to 6.0 - Part 1


So, these posts are around upgrading from vSphere 5.0 to 6.0U2, quite a big jump! I'm testing this is a Lab to see if I hit any issues or gotchas. The steps also involve changing from Server 2008R2, dealing with certificates and keeping vCenter historical data and SRM intact along the way. So, reasonably complex and I've heard of others experiencing difficulties so even if this works in a Lab, it's not a given it will work in the real world. For that I'd recommend cloning the vCenter and a Domain Controller into a test network bubble and injecting the vCenter 6.0 ISO and trying it on the actual vCenter install (Include SQL of course!).

First things first I need a Lab and I've decided on 16VMs for this lab as follows:

lab50sqla 2008R2 SQL 2008R2
lab50vca 2008R2 vCenter 5.0
lab50srma 2008R2 SRM 5.0
lab50esxia ESXi 5.0
lab50sqlb 2008R2 SQL 2008R2
lab50vcb 2008R2 vCenter 5.0
lab50srmb 2008R2 SRM 5.0
lab50esxib ESXi 5.0
lab50pscc 2012R2 PSC 6.0
lab50sqlc 2012R2 SQL 2014/2016
lab50vcc 2012R2 vCenter 6.0U2
lab50srmc 2012R2 SRM 6.1.1
lab50pscd 2012R2 PSC 6.0
lab50sqld 2012R2 SQL 2014/2016
lab50vcd 2012R2 vCenter 6.0U2
lab50srmd 2012R2 SRM 6.1.1



I've used a powershell script to deploy these:

new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50sqla
new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50vca
new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50srma
new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50sqlb
new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50vcb
new-vm -vmhost bdragon.lab.local -template "2008R2 Std Template" -Datastore Datastore1 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50srmb
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50pscc
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50sqlc
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50vcc
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50srmc
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50pscd
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50sqld
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50vcd
new-vm -vmhost bdragon.lab.local -template "2012R2 Std Template" -Datastore Datastore0 -diskstorageformat thin -oscustomizationspec "server 2012" -name lab50srmd

Now, I've just to sit back and hope I don't run out of disk space!! I'll get around to using VMFork at some stage to make this faster!

The overall plan is to upgrade vCenter in place and point at the new PSC's (Same SSO Domain, Separate Sites). I'm using HPE Storevirtual iSCSI SANs to replicate real ones so I can implement SRM recovery plans and ensure they survive the transition. Once the upgrades are done I'll replatform onto the newer OS and see how I go. Snapshots and backups are going to be important as I'm expecting to hit snags and issues as I've found parts of this plan but not a complete end to end write up anywhere. 

Most of the virtual hardware will remain low but I'll beef up the vCenter and SQL a bit to 8GB Ram. 

One of the first things to do is to check the VMware Interoperability Guide. What we're initially looking for is if we can do an in place upgrade or if the Operating Systems and Database versions preclude this.
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db
Start with the Database, we can see that vCenter 5.0 is compatible with SQL 2008, 2008 R2 and SQL 2012 but not any later SQL. We want to go to SQL 2014 or later so this is an issue. Now add in another version of vCenter, 6.0U2. This IS compatible with SQL 2008R2 once a service pack is applied (SP1/SP2). So this gives us a path forward, we can upgrade in place and THEN move the databases to SQL 2014 and we should be ok. Update Manager is much the same story.
Note: SQL 2016 is not mentioned at all.

So, we can also check interoperability between vCenter 6.0U2 and SRM 5.0 - not match of course! So, SRM will not function until it's also been upgraded and we should go to the latest version and SRA. Now, this is not as simple as it looks, the third section in the interoperability guide allows us to plug in SRM. As you can see from the chart below we can't go straight to 6.1, we have to go to 5.5.1, then 6.0 and THEN 6.1.1 !!! Now we should check database compatibility for all of these versions. So we're fine using SQL 2008 R2 (SP1 or SP2 ONLY) across all of these versions. SRM 6.0 & 6.1.1 support SQL 2014 too.


What about the Operating Systems? Well, Server 2008 R2 is 64-bit so that helps.

Build Notes: 
Open TCP Port 1433 in Windows Firewall on SQL Servers
You only need to install the x64 SQL Native Client on the vCenter Server VMs
Use C:\Windows\Syswow64\odbcad32.exe to create Update Manager 32-bit DSN (Ah, the good 'ol days!)
When installing Update Manager use the FQDN of vCenter to comply with CA Certificate requirements later (both during the connection page and port settings page)
In order to get the web interface to work use the following when replacing certificates to get the website unregistered/registered:
C:\Program Files\VMware\Infrastructure\vSphere Web Client\scripts
admin-cmd unregister https://lab50vca.lab.local:9443/vsphere-client lab50vca.lab.local lab\administrator
admin-cmd register https://lab50vca.lab.local:9443/vsphere-client lab50vca.lab.local lab\administrator

If you get Error #2046 see here and upgrade to vCenter 5.0 U3e:
There is a workaround but it needs to be reapplied after each reboot! 

Install SRM before the SRA
SRM uses a 32-bit ODBC DSN on this version (5.0)
.NET required for Storevirtual SRA on each SRM server to work at all
rename rui.pfx to rui.p12


Wednesday, 29 June 2016

VMware vSphere Syslog options - Part 2

VMware vSphere Syslog options - Part 2


To prepare I deployed a VM running Red Hat Enterprise Edition using the new Developer subscription made free by Red Hat for testing purposes. I can subscribe away lab machines and there's no $99 yearly charge anymore. I highly recommend getting hold of this to brush up on Linux skills.

Note: You may hit a console bug where the Redhat lock screen freezes, turn off screensavers and automatic lock screen behaviour in Redhat before you go to use Putty to prevent this. It may be down to particular VMware patches but I've found nothing conclusive yet, it's just annoying when you're in the middle of a Lab and worth avoiding - obviously Production will need a different approach.

This is the main reference I'm following to get this up and running as it contains exactly the outcome I was after:
http://docs.fluentd.org/articles/free-alternative-to-splunk-by-fluentd

You'll need a few Firewall ports open so start with these in the GUI for runtime and permanent:
TCP Port 5601 for Kibana web access
UDP Port 514 for syslog-ng to redirect syslog to fluentd

Note: ensure you've subscribed RHEL to the Update Repository at this point.

Next open a Putty session to the new VM. Check the Java version is ok:

[dufus@syslog5 ~]$ java -version
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (build 1.8.0_91-b14)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

Version 7 or higher is needed, so I'm ok with version 8 as shown above.

Prerequisites:
Setup for NTP

Check ulimit value:
ulimit -n
(mine returned 1024 which needs to be changed)

Edit /etc/security/limits.conf
There are some changes required the file permissions to carry this out:
Check permissions on limits.conf file:
stat --format '%a' /etc/security/limits.conf
This gives me "644"
Set permissions to allow editing of limits.conf file:
sudo chmod 777 /etc/security/limits.conf
vi /etc/security/limits.conf

Add these lines to this file (Copy & Paste the whole lot directly into VI if connected with Putty client):
root soft nofile 65536
root hard nofile 65536
* soft nofile 65536
* hard nofile 65536

Set permissions back:
sudo chmod 644 /etc/security/limits.conf

I'm not running a high load environment so that's it for me. Time to reboot to apply before going further.

Note: This is a good time to shut down the VM and take a snapshot until you get the remaining changes successfully implemented.

Now, the article might refer to older versions of Elasticsearch and Kibana, I'm going to use the latest versions currently available so adjust the download links after checking the web page sources listed below:

Elasticsearch

Check the url for the latest version here:
https://www.elastic.co/downloads/elasticsearch

You can install elasticsearch via Yum but it doesn't prepare the right version, you need to match Kibana and Elasticsearch versions.

I found installing Elasticsearch as an RPM was the best option and allowed me to run it as a service much easier:

cd /tmp
curl -O https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/rpm/elasticsearch/2.3.3/elasticsearch-2.3.3.rpm
sudo rpm -Uvh elasticsearch-2.3.3.rpm
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

Done! Now Elasticsearch is running as a service.

Kibana

Check the url for the latest version here:
https://www.elastic.co/downloads/kibana

Now open another putty session and run the following commands, adjusting the filename according to the new version you see available:

curl -O https://download.elastic.co/kibana/kibana/kibana-4.5.1-1.x86_64.rpm
sudo rpm -Uvh kibana-4.5.1-1.x86_64.rpm
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable kibana.service
sudo systemctl start kibana.service

Now the Kibana server is running you can check it on the VM console (if it hasn't locked up!) on http://0.0.0.0:5601


There no data so that's it for now.

Fluentd (td-agent)

Now open a third Putty session and we'll try to install Fluentd and get the configuration file edited and working.

http://docs.fluentd.org/articles/install-by-rpm

curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent2.sh | sh

The script above executes and installs the td-agent2

Now install the Elasticsearch plugin:

sudo /usr/sbin/td-agent-gem install fluent-plugin-elasticsearch

And next modify the td-agent.conf file (back it up first!):

sudo cp /etc/td-agent/td-agent.conf /etc/td-agent/td-agent.conf.bak
stat --format '%a' /etc/td-agent/td-agent.conf
644
sudo chmod 777 /etc/td-agent/td-agent.conf
vi /etc/td-agent/td-agent.conf

Modify as follows:
Find the section:
<source>
  type forward
</source>
Now insert a few blank lines above this and copy and paste the section below, then you can delete the section above and you're good to go! 

<source>
  @type syslog
  port 42185
  tag syslog
  format /^(?<pid>[^ ]*) (?<time>[^ ]*) (?<host>[^ ]*) (?<ident>[a-zA-Z0-9_\/\.\-]*) (?:\[(?<pid>[0-9]+)\])?(?:[^\:]*\:)? *(?<message>.*)$/
  time_format %Y-%m-%dT%H:%M:%S%z
</source>

<source>
  @type forward
</source>

<match syslog.**>
  @type elasticsearch
  logstash_format true
  flush_interval 10s # for testing
</match>

sudo chmod 644 /etc/td-agent/td-agent.conf
sudo /etc/init.d/td-agent start

Syslog-NG

This section deals with installing Syslog-NG. The inbuilt rsyslog engine I found doesn't preserve the source host address easily so I thought I'd use the more powerful syslog-ng tool instead for this purpose. I hit a problem with a dependency when trying to install syslog-ng but found a suitable binary using www.rpmfind.net so you may need to watch out for this if versions change etc.

Error: Package: syslog-ng-3.5.6-3.el7.x86_64 (epel)
           Requires: libnet.so.1()(64bit)

My solution to getting syslog-ng installed on RHEL 7.2:

cd /tmp
curl -O https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo rpm -Uvh epel-release-latest-7.noarch.rpm
yum repolist
curl -O ftp://195.220.108.108/linux/fedora/linux/releases/23/Everything/x86_64/os/Packages/l/libnet-1.1.6-10.fc23.x86_64.rpm
sudo rpm -Uvh libnet-1.1.6-10.fc23.x86_64.rpm
yum -y install syslog-ng
vi /etc/syslog-ng/syslog-ng.conf

Replace the existing contents with the ones below - replace the IP Address with the local IP of the system you are installing to and where Fluentd resides.

@version: 3.7
@include "scl.conf"

    options {
        time-reap(30);
        mark-freq(10);
        keep-hostname(yes);
        chain-hostnames(no);
        };
    source s_network {
        syslog(transport(udp));
        };
    destination d_syslog_udp {
        syslog("192.168.10.104" transport("udp") port(42185));
    };

    log { source(s_network);
          destination(d_syslog_udp);
        };

systemctl stop rsyslog.service
systemctl start syslog-ng.service
systemctl disable rsyslog.service
systemctl enable syslog-ng.service
yum -y remove rsyslog

Now check Kibana and you should see message appear.


The host, ident, message and @timestamp fields should all line up. I found I had to use some online parsers to get the format line in the syslog-ng.conf just right or I would be missing data, or worse get errors in fluentd as follows:

tail -f /var/log/td-agent/td-agent.log

2016-06-02 14:12:32 +0100 [error]: "<167>1 2016-06-02T13:12:30+00:00 bdragon.lab.local Vpxa - - - verbose vpxa[FF88DAC0] [Originator@6876 sub=PropertyProvider opID=HB-host-9@1193-44773711-1e] RecordOp ASSIGN: info.state, session[5270aadd-231b-3521-e317-dbd316cd75e4]52c63ee9-fe3d-d55a-6128-51ec302ec66d. Applied change to temp map." error="invalid time format: value =  2016-06-02T13:12:30+00:00, error_class = ArgumentError, error = invalid strptime format - `%b %d %H:%M:%S'"

The frustrating thing is that the issue above was caused by the "<167>1" and not the format of the date! Even after long hours figuring out the correct format I was still left with an error. The websites below held the key, I'm no Ruby expert but it let me quickly try out different expressions until I arrived at the ones above finally. I've left the full link deliberately to reflect the final expression I tested that worked.

https://fluentular.herokuapp.com/parse?regexp=%5E%28%3F<pid>%5B%5E+%5D*%29+%28%3F<time>%5B%5E+%5D*%29+%28%3F<host>%5B%5E+%5D*%29+%28%3F<ident>%5Ba-zA-Z0-9_%5C%2F%5C.%5C-%5D*%29+%28%3F%3A%5C%5B%28%3F<pid>%5B0-9%5D%2B%29%5C%5D%29%3F%28%3F%3A%5B%5E%5C%3A%5D*%5C%3A%29%3F+*%28%3F<message>.*%29%24&input=<167>1+2016-06-02T12%3A40%3A38%2B00%3A00+bdragon.lab.local+Vpxa+-+-+-+verbose+vpxa%5BFFCA7B70%5D+%5BOriginator%406876+sub%3DVpxaHalCnxHostagent+opID%3DWFU-564af32b%5D+%5BVpxaHalCnxHostagent%3A%3AProcessUpdate%5D+Applying+updates+from+6463+to+6464+%28at+6463%29&time_format=%25Y-%25m-%25dT%25H%3A%25M%3A%25S%25z

http://rubular.com

So, you fire all syslogs out of your ESXi hosts over UDP port 514 to the central RHEL server and it listens for them, syslog-ng forwards them to UDP Port 42185 where Fluentd listens and then onto Elasticsearch via logstash. Easy!! At least you can view the results in a cool web browser and do all the searching you need.

I've not looked at long term storage requirements here so you'll need to monitor disk space and ensure Elasticsearch doesn't run out, best to test this with one or two Hosts in a Lab before sizing and deciding on log retention etc.

It's not a particularly easy combination, it may be possible to use rsyslogd instead of syslog-ng but this is the combination I found to work and enable more powerful searching and indexing of syslog files from VMware. That or just use their Log analyzer product if you prefer!


Tuesday, 14 June 2016

VMware vSphere Syslog options - Part 1

VMware vSphere Syslog options - Part 1


The troubleshooting facilities in VMware vCenter and vSphere are fairly good in my opinion. Through my work I can access a support dump analyzer for ESXi Hosts that provides very useful information. I can crack open the vCenter dump to access specific logs and see what's been going on. I can tail the vmkernel.logs to monitor realtime activity and with the introduction of the Syslog collector service in vCenter look back in time - just add the logs or vCenter VM to the backup schedule and see if a particular problem existed previous to a patch or upgrade.

Where I don't get involved is in deep investigation of issues. Support typically go deeper in their analysis of particular problems and the in built syslog server uses flat logfiles which make tracing a particular fault more difficult.

I heard about a few options in this area and wanted to explore them here and try them out.

Pay versions:

VMware vRealize Log Insight
https://www.vmware.com/products/vrealize-log-insight/
Commercial, free for up to 25 OSI (Operating System Instances) when you own a supported vCenter license but $$ beyond that. This might just do some smaller businesses and from what I've seen is a great product with contents packs to extend monitoring beyond VMware Products. They don't charge for the storage of large amounts of log data. The product is deployed as a virtual appliance.

Splunk
http://www.splunk.com/en_us/products/splunk-enterprise.html
This is the main competitor to VMware's product and has been out there a while with a good knowledge base. They have cloud options and a Splunk Lite. The pricing is per GB of logs, hence you need to know the volume of logs generated but this could spike when experiencing an issue which is not so good! It installs on Windows, Linux, Solaris and Mac OS.

Kiwi Syslog Server
http://www.kiwisyslog.com/products/kiwi-syslog-server/product-overview.aspx
I've used this myself in the past with their CATTools to backup Cisco switches. Cost is a flat fee of €240 and installs on windows only.

Free/Pay versions:

PRTG Free Syslog Server
https://www.paessler.com/free_syslog_server
Well, it's free up to 100 sensors, they estimate  each device will use 5-10 sensors but I'm going to test it with just syslog on an ESXi host to see if I could get 100 ESXi hosts out of it. You want more of course you pay more and it's not free at that point. But it could be just enough for you.....

Free versions:

Syslog-NG
https://www.balabit.com/network-security/syslog-ng
https://syslog-ng.org
https://github.com/balabit/syslog-ng
Well, this is completely free and open source but requires Linux. You can use the VMware virtual management appliance (vMA) to get this up and running. I'm interested to see how much work there is to get it capturing logs from multiple ESXi hosts and then query the product as with most Open Source solutions, they are no easy to use / get working out of the box. But if you're up for a challenge then so am I!!

My ideal is an open source, free product, easy to set up, Kibana web front end with Elastic Search and little to no configuring for vSphere logs!! I can dream right?!

PRTG Free Syslog Server

So this one is interesting. Once installed and loaded up it began discovering my network and picked up everything running on the same subnet. This included vCenter, ESXi, network devices etc. All I was interested in was the syslog server but it's not enabled by default. You have to add a new probe device to the local probe called "Syslog Receiver" and choose the settings if you want them different from the default, mine worked fine as is. Once I configured ESXi from KB2003322 I got a few messages through and could see how it worked.

So it's getting message but how easy is it to retrieve specific message levels. There is a message tab to list all recent ones.
Then you can select a specific severity as shown below. There is some rudimentary text searching.
The historic data tab allows exporting of specific errors to html or csv.

That's as exciting as it gets! 
The trial license stays for 30 days even after putting in the free key, then limiting you to 100 devices. I was able to remove a lot of the discovered entries and sensors to reduce the amount in use. Windows Firewall Rules were added automatically. There was a web interface but I didn't spend too much time with it. 

Kiwi Syslog Server

This one is also Windows based and required .NET 3.5 so add that Feature into Server 2012 R2 if required to allow the install to proceed. After install I pointed ESXi at the new syslog IP and off it went. You can see immediately the new logs hitting the server. 
There is no search or filter really in the main screen. You can schedule archive options as shown to deal with historical records but it just stores things in a flat file much like the VMware equivalent. You can do more filtering of course over what it captures and output it to different "screens" but it's no better than when I last looked at it over 10 years ago....there web interface failed on install so didn't get a look at that. 

Splunk Enterprise

Simple to install. I went with the Enterprise version to see what features it provided. There is a VMware App you can add in but after 10 minutes while this was heading in the direction I wanted I gave up as it appears complex but very powerful, not so easy to get to grips with. Very well worth checking out though....

VMware vRealize Log Insight
Erm, I downloaded the appliance and found that you need a supported version of vCenter to get a free 25 OSI license, but they then say go to the downloads page and click on Read More to get the 5.5 and lower version key which is listed right there?! The OVA deployment was standard, I let DHCP do everything as I was only going to test it for a few minutes. 
Blog entry here from VMware:
Now, how does it stack up? Well I couldn't connect to it at first with the browser, after a few minutes it rebooted and was doing some configuration by itself so I left it alone. Wait until you see this in the console.
Now you'll be able to connect with the web interface


I clicked New Deployment. Once you finish all the initial setup questions you can configure integration. As it's a VMware product for monitoring VMware primarily I know this is going to be easy! 
To start with I just configured my ESXi Host to sent logs to the Log Insight appliance and didn't configure vCenter integration. Just to see what happened. There are content packs for vSAN and more.
I was definitely getting logs in from the host so I decided to configure vCenter integration next.

The VMware specific dashboards are interesting.
And you can drill into these to get the interactive view which is absent in the other products where I tested it. 
So, I'd be fairly happy to give HPE Support access to VMware's Log Insight and be sure it would help them out. PRTG would also tick my box but I'm less sure about Kiwi Syslog Server. Splunk with effort in setting it up would most likely beat all of these but cost is a factor and the slight complexity which when you've limited time for a Lab session isn't workable. I'm sure there's good Blogs out there you can find that would help you set it up correctly and to test it out. 

Syslog-NG

This one troubles me as there doesn't appear to be any web interface or search engines so what's the point!?! I did find some good articles using other open source software so I'm going to give them a try, document the results and add them as my next post so stay tuned. If it works I just need to find a suitable Linux distribution to deploy and see how manageable that becomes over time. 

Disclaimer: I work for HPE as a Consultant.

Friday, 1 April 2016

VMware Web Client Fling

VMware Web Client Fling


This post will be nice and easy! I heard from a colleague that there was a new Web Client out this week. I thought this was to do with the Host Web Client now built into 6.0 Update 2 but no, it's the potential replacement for the awful vCenter Web Client. Finally a HTML 5 version. I know it would be early days and not fully featured but I was curious to see what it was like in my Lab.

Links:
https://blogs.vmware.com/vsphere/2016/03/vsphere-html5-web-client-fling-getting-started.html
https://labs.vmware.com/flings/vsphere-html5-web-client

You deploy an OVF but for the windows version you also download a BAT file. I tried running the script on my workstation but got path errors. Then as I read through the release notes realized it needs to be run on the vCenter server itself. I did this and got path errors again. It creates files but not the ones you're looking for!! Then an updated Blog post out of VMware admitted you need to edit the script to change the path if you installed vCenter somewhere other than the C: drive, like most of us do in the real world!! I edited the following two lines and it 66% worked but still gave an error.

REM Path to javas' keytool
SET KEYTOOL=E:\Program Files\VMware\vCenter Server\jre\bin\keytool.exe

REM Path to vecs binary
SET VECS_CLI=E:\Program Files\VMware\vCenter Server\vmafdd\vecs-cli.exe

C:\temp\ks>server-configure.bat
Generating store.jks file...
Generating webclient.properties file...
Creating ds.properties file...
The system cannot find the path specified.
Done.

There is another Path that needs changing:

E:/ProgramData/VMware/vCenterServer/cfg/store.jks >> %PROPFILE%
echo keystore.jks.path=/etc/vmware/vsphere-client/store.jks >> %PROPFILE%

and further down:

echo Creating ds.properties file...
SET CLIENT_DIR=E:\ProgramData\VMware\vCenterServer\cfg\vsphere-client

Once I had all four of these paths updated from C: to E:, I ran the script using an elevated command prompt and it generated the three files. 

Finally it works(!!):

C:\temp\ks>server-configure.bat
Generating store.jks file...
Generating webclient.properties file...
Creating ds.properties file...
        1 file(s) copied.
Done.

I uploaded the three files into the directory paths you've to create and started up the web service. 

vcsa:~ # /etc/init.d/vsphere-client start
Starting vSphere Client Web Server
vSphere Client Web Server successfully started in 87 seconds

The interface is VERY responsive compared to the current clunky one. 



It's still got a ways to go but I could see myself using this interface whereas I've given up on the current web interface and revert to the C# client wherever possible! I hope it matures quickly and makes it into the next vCenter version. Give it a shot if you get a chance!

Notes [Update]:
URL is https://<ip of web client appliance ip address>:9443/ui
To get at the management interface of the appliance to apply upgrades:
https://<ip of web client appliance ip address>:5480
user: root   pass: monova