WilliamLam.com

Can the VCSA 6.5 forward to multiple syslog targets?

by // 2 Comments

I had a couple folks ping me recently asking whether the latest vCenter Server Appliance (VCSA) 6.5 release supports forwarding to multiple syslog targets? Currently today, only a single syslog target is officially supported which can be configured using the VAMI UI. I know this is something our customers have been asking about and I know this is something the VC Engineering team is considering.

Having said that, it is possible to configure additional syslog targets on the VCSA, but please be aware this is not officially supported. A couple of these customers understood the support impact and were still interested in a solution as some of their environments mandated multiple redundant syslog targets and using a syslog forwarder/relay was not an option for them.

Disclaimer: This is not officially supported by VMware, please use at your own risk.

When configuring syslog forwarding from the VAMI UI, the configurations are all written to /etc/vmware-syslog/syslog.conf on the VCSA.

With this information, if we want to add additional targets (which can be of the same configuration or different), you simply append additional targets to the syslog configuration file. For example, if I have two syslog targets 192.168.30.110 and 192.168.30.111 and I wish to use the default log level, TCP and 514, I would use the following:

*.* @@192.168.30.110:514;RSYSLOG_SyslogProtocol23Format
*.* @@192.168.30.111:514;RSYSLOG_SyslogProtocol23Format

Once you have saved your changes, you will need to restart the rsyslog service for the change to go into effect. To do so, run the following two commands on the VCSA:

systemctl stop rsyslog
systemctl start rsyslog

One additional thing to note is that the VAMI UI will only show the very last syslog target within the configuration file but if you monitor syslog servers, you will see that logs are indeed being forward to all servers that have been configured in the syslog configuration file.

Automated NSX-T 2.0 Lab Deployment

by // 21 Comments

Last week, I had spent some time exploring and getting myself more familiar with NSX-T, which is the next generation release of the NSX platform from VMware. One of the first thing I do when learning about a new product is to setup a lab environment that I can using. Having gone through the deployment once by hand, I realized it would be quite painful if I needed to do this again, which I know I will and I did 🙂 I wanted to have a simliar experience to my vGhetto Automated vSphere Lab deployment script which also including setting up the entire vSphere infrastructure along with deploying and configuring NSX-V and extending it to support NSX-T.

Since my original script leverages PowerCLI to access both the vSphere and NSX APIs, I wanted to do the same with NSX-T. Funny enough, the PowerCLI team had just published an update release (6.5.3) which also added support for NSX-T and I thought this was perfect timing to try out the NSX-T APIs, which I had never used before.

UPDATE (01/01/2018) - I have verified the script also works with the latest NSX-T 2.1 which was just released before Christmas. The script has also been updated to create a new Edge Uplink Profile along with an Edge Cluster and automatically associate all Edge VMs to Edge Cluster.

I have created a new Github repository called vghetto-nsxt-automated-lab-deployment which contains detailed instructions along with the PowerCLI script.

Here is what the script is currently performing:

  1. Deploy and configure vCenter Server Appliance 6.5u1
  2. Deploy and configure 3 x Nested ESXi 6.5u1 Virtual Appliance VMs and attaching it to vCenter Server
  3. Deploy NSX-T Manager, 3 x Controllers & 1 x Edge and setup both the Management and Control Cluster Plane
  4. Configure NSX-T with IP Pool, Transport Zone, Add vCenter Server as Compute Manager, Create Logical Switch, Prepare ESXi hosts, Create Uplink Profile & Add configure ESXi hosts as a Transport Node

Similiar to the vSphere version of this script, all deployed VMs will be placed inside of a vCenter vApp construct as shown in the example screenshot below:


Here is an example output of a succesful deployment and you go from nothing to a fully functional NSX-T environment in just 50 minutes, which is pretty awesome if you ask me!?

[Read more...]

Introducing Alexa to a few more VMware APIs

by // 3 Comments

Over the weekend, while taking a break from putting together some furniture as it was my time for my daughters nap, I got that the chance to explore and create a new Alexa Skill which integrates with a few of VMware's APIs. This has been something I wanted to try out for some time but have not had any spare time. I had even purchased an Amazon Echo Dot but its just currently being used as a music player for the family. A couple of weeks back I saw an awesome blog post from Cody De Arkland where he demonstrates how to easily integrate the new vCenter Server 6.5 REST APIs into an Alexa Skill which can then be consumed using an Amazon Echo device.

Cody's write-up was fantastic and I was able to get everything up and running in about 20-25minutes with a few minor trial/error. It was great to see how easy it was for a non-developer like Cody to easily consume the new vCenter Server REST APIs which includes basic VM Management as well access to the VMware Management Appliance Interface or VAMI for short. Given Cody already did the hard work to create the initial Alexa integration, I figure it might be cool to extend his work and introduce Alexa to a few more VMware's APIs including the traditional vSphere API (SOAP) and the new vSAN Management API.

UPDATE (06/15/17) - Just added support for PowerCLI, it was a little tricky as Flask app is written in Python and so poor man workaround was to call Powershell/PowerCLI using subprocess.

Since Cody's integration module was written using Python, it was pretty simple to add support for both pyvmomi (vSphere SDK for Python) and vSAN Management SDK. To install pyvmomi, you can simply run

pip3 install pyvmomi

and for installing vSAN Management SDK, have a look at this blog post here.

Here is a quick video that I had recorded which demonstrates the use of both the vSphere API and vSAN Management API using my Amazon Echo.

You can find all my changes in this forked repo lamw/alexavsphereskill and make sure to follow Cody's blog post here for instructions on how to get setup. For those wondering if Cody will be publishing an Alexa Skill for general consumption, I know he is working on some awesome updates to make it even easier to consume. Here is a sneak peak at just some of the recent updates that Cody is working on ...

Stay tuned on this blog and Github repo for future updates!

One thing to note which I was not aware of until Cody mentioned it, is that once your Alexa Skill is built, you can directly access it from your own personal Amazon Echo without needing to publish it. You need to activate the Alexa Skill by saying "Alexa Start [APP-NAME]" where name is the name used in the "Invocation Name" field as shown in the screenshot below when setting up your Alexa Skill. I should also mention that if you decide to change the Alexa Skill name itself, which I had initially done and called it "vGhetto Control", make sure you update the Flask App name in __init__.py to the same name (spaces are converted to underscores) or you will run into issues.