- ✓Delivers a wealth of information that can be used to tune server and virtual machine configurations
- ✕A few rough edges mean that the suite takes some getting used to
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.
Next we defined an application to model our mail system. We could then use the Services dashboard to verify that our services were running within the SLA and to see a summary of the number of alerts that could affect our application. We could also use the Application Detail dashboard to get a more detailed view of the alerts from the servers that together made up the applications.
We noticed a few rough edges. For example, one of the main hierarchy items is called 'Hosts'. However, we found many of the items in this Hosts hierarchy reported 'No data to display'. Vizioncore told us that this was linked to the common host model used by Foglight, and recommended that the Hosts dashboard be left alone until the host model is updated in a future version of vCharter Pro.
We were disappointed to see the Billback reports from vCharter were no longer available in the latest version, and surprised that the default password policy is even stricter than it is on Windows Server 2008. vCharter Pro requires passwords to contain both alphabetical and numeric characters, including at least one capital letter plus a non-alpha character too.
Overall, this is an extremely useful but rather complex product. For example, we wanted to configure the email interface used to send reports to administrators, but couldn't find all the information we needed in the online documentation. We did get help from some training materials, and would recommend that users attend a training course to learn how to get the best from this powerful platform.