WilliamLam.com

Search Results for: vsphere events

A Hidden vSphere 5.1 Gem - Forwarding Virtual Machine Logs (vmware.log) to Syslog Part 2

by // 7 Comments

In Part 1 I showed how you can forward virtual machine logs to ESXi syslog using an advanced virtual machine setting that was introduced in vSphere 5.1. A caveat with this solution is that the ESXi syslog file contains both system logs as well as virtual machine logs which is not very ideal from an isolation perspective. With virtual machine logs being quite verbose, if you are not forwarding logs to a remote syslog server, important system events can easily be rotated out of the local logs.

To work around this caveat, we can create a new logger specifically for handling virtual machine logs within the ESXi syslog client. You can view the existing logger types by looking in /etc/vmsyslog.conf.d directory. You will need to create a new logger configuration file which I named vmx.conf and it should contain the following:

[vmsyslog-logger]
# unique id for this logger
id = vmx
# description of this logger
descr = VMX Logs
# idents this logger is interested in
idents = vmx
# output file (e.g. foo == /var/log/foo.log)
file = vmx
# file logger class
fclass = FileLoggerSyslog
# network logger class
nclass = NetworkFilterSyslogTimestamp

Here is a screenshot of of my configuration file and noticed the highlighted text in yellow is what needs to be modified:

Note: Ensure that idents property matches the vmx.log.syslogID string specified for your virtual machines. This also means you will not be able to specify the virtual machine's name for the advanced setting, but will need to keep it generic so it can be filtered by the logger.

Once you have saved the vmx.conf configuration file, you will need to reload the ESXi syslog client for the changes to go into effect by running the following ESXCLI command:

esxcli system syslog reload

You now should see a new log file in /var/log called vmx.log which will contains only virtual machine logs:

If your ESXi host is forwarding its logs to vCenter Log Insight, you can easily create a filter for the keyword "vmx" in the log source or whatever string you decided to set it to if you are not using the default.

One final caveat to be aware of now is that the custom syslog logger (vmx.conf) will not persist after a system reboot. To preserve this file, you can either automatically re-create the file during bootup and reload syslog client using this article here OR create a custom VIB using this article here.

Creating Custom vSphere Reports is a Breeze with CloudPhysics

by // 2 Comments

Creating reports is a common task that every vSphere administrator must deal with at least once if not many more times in their career. Whether you are tasked to provide an inventory report of all your virtual machines and their configurations to your manager or to provide a compliance report for your security team to ensure that all virtual machines are hardened according to the vSphere Security Hardening Guide, report creations can be a challenge.

The vSphere platform provides a very powerful and rich set of APIs (Application Programming Interface) that can be consumed by both vSphere administrators as well as developers. However, there is a high learning curve when using the API and it takes quite a bit of time to learn and of course your manager is expecting the report to be done in the next 5 minutes. Even with abstraction tools such as PowerCLI, quickly building a robust, scalable and performant script is not always a trivial task, not to mention the maintenance and updates to the script because your manager wants to continually add more things to the report.

So how can we make reporting so easy that vSphere administrators will no longer have to spend time digging through API documentation and instead they will be able to quickly put together reports within minutes? Well, this is something that the CloudPhysics team has been working on as part of their CloudPhysics card platform and they have built a very unique card solution to help solve this problem. I had the opportunity to get an early preview of this new card and I have to say that I am very impressed at how easy and intuitive the interface is to build simple to very complex reports using this new card solution. The coolest part of this solution is that no programming or scripting skills are required!

To give you an example on how easy it is to use the interface, I recently helped a customer with a script to identify all virtual machines that had a virtual disk using the 2gbsparse disk format. I would like to think I know the vSphere API pretty well, so putting the script together took just a few minutes because I knew exactly where to look for this information. That evening I decided to go through the same scenario, but using the new CloudPhysics card solution and I was literally able to create the report in seconds! It probably took me longer to name the report than to actually create it. As you can see, I am pretty excited about the new card solution and it will be interesting to see all the cool new reports customers can now create and share with each other.

Here is a sneak peak at what the interface looks like when creating your own custom reports:

Here is the final report that is produced:

As you can see, I have quickly narrowed down the specific virtual machine that contains a 2gbsparse VMDK and I am able to see exactly which virtual disk that is. 

If you would like to learn more about the new card solution, Irfan Ahmad, CTO of CloudPhysics will be hosting a live webinar to go over this new solution next Tuesday, June 25th at 9am PST and I would highly recommend you register for it to learn more.

Below is a bit more details on what you can expect from the webinar and you can register here.

vSphere Analytics Without Writing Code: The Quest for Missing Reports

While vSphere, the best-of-class virtualization platform, brings great efficiencies to the datacenter, reporting still presents challenges and pain to sys admins on a daily basis. CloudPhysics offers a radical new way to complete reporting for your virtual infrastructure. In addition to 20 high-impact reports, you can easily build your own and share the report template and output. When asked for asset reports, trending, activity, auditing and more, you’re never more than a few clicks away from delivery.
  
In addition to best practices and secrets to amazing mashups, you’ll learn to:
  • Create easy, visual reports for your vSphere environment
  • Add multiple vCenters in one view
  • Automate the report generation

Blocking vSphere C# Client Logins

by // 8 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

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

Login to your vCenter Server and locate a file called version.txt

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉