This is a powerful performance monitoring and reporting system for servers running VMware ESX Server. Web-based dashboards show the resources in use by servers and their VMs, while the reporting module delivers printable reports of historical data.
Vizioncore's vCharter Pro provides comprehensive monitoring of alerts and resource utilisation for servers running VMware ESX Server and for the virtual machines (VMs) running on those servers.
If you're familiar with its predecessor, vCharter, forget everything you've seen before: vCharter Pro is not an upgrade — it's an entirely new implementation of much the same idea. Following the acquisition of Vizioncore by Quest Software, vCharter Pro runs on Quest Software's Foglight systems management platform.
The shift to Foglight has several advantages. First, Foglight is a web-based platform, so vCharter Pro can be accessed from any suitable browser via a LAN or VPN connection. Secondly, vCharter Pro is a truly multi-user system. User accounts can be allocated roles and permissions so that people can manage the systems relevant to their job.
vCharter Pro works only with VMware systems, but a forthcoming update will also handle systems based on Xen and Hyper-V. Currently the suit integrates only with VMware VirtualCenter for ESX Servers and cannot be used without it.
We tested vCharter Pro by installing it on a workstation fitted with 2GB of RAM, running Windows Server 2003 and VMware VirtualCenter 2.5. vCharter Pro cannot be hosted on a virtual machine (VM), according to Vizioncore.
Overall we were impressed. Its web-based interface provides much more detail than its predecessor. The user interface is pretty conventional, with a left-hand 'navigation' panel showing a hierarchy of options; a click on one of these delivers a more detailed view in the central 'display' panel. The right-hand 'actions' panel has context-sensitive links to things such as shortcuts and help text. Both the navigation and action panels could be hidden or set to auto-hide when the mouse is not over their particular areas of the display.
A vCharter Pro view of an ESX Server installation.
For us, the highlights include detailed reports on resource utilisation. For example, memory utilisation graphs allowed us to see that many of our Linux VMs configured with 64MB or 256MB of RAM were actively using less than 32MB. We therefore reconfigured those VMs with 32MB RAM, allowing us to run more VMs on the same server. Having done this, we occasionally received alerts reporting that one of the VMs was actively using 88 percent of its memory, so we raised the RAM allocation to that VM. Another alert told us 33 percent of the RAM allocated to a VM running Windows was actually filled with zeros, and suggested that we could reduce the RAM allocation to that VM without affecting its performance.
We could also configure our own dashboard displays by dragging and dropping elements from the right actions panel onto a 'blank canvas' in the middle of the screen.
A vCharter Pro dashboard.
Likewise, it's easy to produce reports showing, for example, CPU and RAM utilisation over the last 24-hour period. We configured vCharter Pro to produce these reports on a daily schedule and to keep the seven most recent reports. We were impressed by the wealth of data that could be included in these reports and the number of scheduling options for running them.
It's also possible to define 'applications' as a group of VMs or other resources monitored by vCharter Pro. For example, we used the 'Application builder' to create an application for an accountancy system. We created an end-user tier that contained the Linux firewall used to provide access to the accountancy server, and another tier that contained the Windows-based application server and its outbound firewall. A default Service Level Agreement (SLA) was automatically associated with our application to measure its availability. By default, availability was defined as the state of the component VMs: if they were available, our SLA was met. After a few days it turned out that our SLA monitor occasionally reported a red alert. We could easily see that this was because the outbound firewall sometimes used memory that had been swapped out to VMware virtual memory. As with all SLA monitoring tools, some negotiation with service consumers is needed to decide which events would actually make the service unavailable. In this case we decided that although swapping memory in this way wouldn't make the service unavailable to users, we would nonetheless adjust the VM settings to prevent it happening. A look at the vCharter Pro page for that VM showed it was using 4 percent of the 256MB allocated to it, so we reduced the allocation to prevent the unused memory being swapped out.
The vCharter Pro page for a VM running an outbound firewall.
