Vizioncore vCharter Pro is designed to help VMware ESX Server administrators manage the utilisation of system resources such as RAM, CPU and disk allocations. It monitors resources used by ESX Server systems and also of the VMs they are running. If you’ve seen its predecessor, vCharter, it’s important to understand that vCharter Pro is not an update, it’s a complete re-write. For example, the vCharter Pro is a fully web based management system, so administrators could access all its features from any web browser connected to the vCharter Pro server. The suite also accommodates multiple users, each of which can have their own login and customisable user interface.
Overall we were impressed by the new version. For example, it issued alarms about the resource utilisation of various servers and VMs. Compared to using vCharter, we found vCharter Pro made it much easier to find information that we could use to tune the performance of our virtual infrastructure.
Installation
We installed vCharter Pro 3.0 (04/17/2008) onto a workstation running Windows 2003 Small Business Edition, VMware VirtualCenter 2.5 and fitted with 2GB RAM. Vizioncore says vCharter Pro cannot be installed on a VM.
Installation was straightforward, although we needed to patch our installation with an updated cartridge file (new cartridge version 5.2.1.5) and a new data collector DLL (vizioncore.dll dated 05/23/2008) before we could use the software.
For most of our tests we connected our web browser to vCharter Pro via a VPN link.
Once we had the system up and running we were initially greeted by a large number of alarms from vCharter Pro warning us about various potential problems.
For example, several alarms told us about VMs with RAM that had been swapped out to the VMware swap file. We could confirm this by clicking on a link in the alarm message box that took us to a page with detailed information about the VM stretching back over the last four hours. These detailed views included a graph showing memory that was active and memory that had been swapped out. This made it easy to see that that the RAM had been swapped out because the VM had been allocated more RAM than it was using. Therefore we could reduce the RAM allocation to those VMs, thus enabling us to host more VMs on the same ESX Server.
In other cases we received alarms informing us that a VM was actively using more than 85% of the RAM it had been allocated. In these cases we increased the RAM allocation to those VMs so they would not need to use their own, relatively slow, virtual memory.
Some of the other alarms were less useful. For example, we received warnings that most of our Linux VMs had reserved around 90% of the RAM allocated to them. However, this is very common with Linux VMs so we decided to deactivate the alarm. We did this by referring to some Vizioncore training material. This explained that rules could be deactivated using the “Manage Rules” option in the “Administration” dashboard. From here we needed to select the rule to edit its definition, and then click on the “Rule Summary” drop down, and select the “Rule Status” item. Without access to this documentation we would have struggled to find the correct way of deactivating an alarm.
Having said that, there were 58 preconfigured rules that would post alarms to the vCharter Pro console if various conditions were met. We found all but three of these to be useful. Indeed, one rule sent us an alarm to tell us that a Windows VM’s C: drive was almost completely full. For this we were particularly grateful as we could then schedule some downtime at the weekend when we could power off the VM and use VirtualCenter to expand the virtual disk and then run Gparted to expand the NTFS file system.
Sound reports
As well as providing useful data to tune the operation of our VMs, vCharter Pro also provides useful reports of historical data. For example, we configured a report to monitor a pair of VMs that ran a batch processing job every night. Using this report we could see that for most of the day the VMs used little of their RAM or CPU allocations. However, the batch processing job was so starved of RAM on one VM that the job was taking several hours to complete, rather than the 20 minutes or so needed on the other VM. It turned out that one VM had been configured with more RAM than the other. We corrected the RAM configuration so both VMs finished their batch job in reasonable time.
Similarly, our largest VM was assigned two CPUs and 4GB or RAM. We configured a graph to report the last week’s CPU utilisation, so we could provide tangible data to the VM owner to justify a CPU upgrade.
The current version of vCharter Pro works only with ESX Server systems, and requires VMware VirtualCenter 2.x. However, an update is due soon that will also manage VMs running on Microsoft Hyper-V and the Xen hypervisor.