Insystek's VMware control is decidedly more effective than its control over XenServer. We started out testing TotalView 1.1, but an upgrade to 1.2 arrived during the middle of testing, so we upgraded to it. (View a .)
While it was quite buggy and crashed when performing certain tasks, TotalView does provide quite a bit of detailed -- but mostly static -- information about the virtual machines on VMs running atop of our XenServer and VMware ESX hosting platforms. The product does not do a good job of refreshing the information it initially finds. That said, the user interface is a mess, as switching between different -- but necessary -- areas of the GUI proved to be very painful.
TotalView has a Windows-based GUI that Insystek recommends should be run in an application hosting environment using Windows XP SP2 and SQL Express 2005. Also supported, but not tested -- hosting environments include Microsoft Windows 2000 with SP4 and Windows 2003 Server. Other supported databases include MS MSDE and MS SQL Server.
Installation was more difficult than it needs to be, and we had to manually select the SQL Server Express Edition to make things work, a process exacerbated by a strange licensing dysfunction and indecipherable error messages.
With TotalView 1.2 deployed in the test bed (Version 1.1 was wrought with installation issues pertaining to managing XenServer VMs so we had to upgrade) we could complete all VM operational basics such as starting and stopping XenServer machines and cloning and uninstalling VMs. However, attempting to suspend VM operation repeatedly yielded the same opaque error message: Failure SR_HAS_NO_PBDS.
We switched to testing how TotalView could manage VMware's ESX machines. TotalView can manage VMware ESX-based VM whether or not VMware's VirtualCenter application is present. After successfully adding an ESX host to the management system, we attempted to create a new VM on that host using the TotalView interface using all methods available to us.
There were two ways to install a VM using TotalView, one was a 'typical' install that uses default settings after selecting the operating type, and the other was a 'custom' install in which we could choose more detailed options. We were able to successfully create a VM (SLES 10.2) using 'typical' with Local Storage and it refreshed correctly with TotalView. But while we were editing or changing properties, we noticed that TotalView doesn't refresh very well. It really should refresh more often because it's not very useful to monitor VMs if you have to manually refresh the display all the time.
When we tried installing from a shared DVD ISO image, we had to copy it to our TotalView machine. We couldn't install VMware Tools for SLES (the driver tools that connect the hypervisor and the guest operating system together) as we got a general system error.
We next tried a custom VMware client install using NFS storage for Windows 2008 server. After creating a 'custom'-based VM, TotalView crashed and then would not restart, the database was corrupted. We had to re-install again because it gave the same error every time we started up.
Our final creation test (creation) worked OK, with no crashing after refreshing. We installed Windows 2008 Server on this VM. TotalView indicated the creation was successful, but the new VM wouldn't show up in the TotalView GUI. When we refreshed the view, TotalView indicated that an "Unhandled exception occurred in your application" but we could hit the continue button and ignore the error. These errors seemed to happen all too frequently.
We could verify the VM's existence, but had to do so using VMware's Virtual Infrastructure Client view (the front end to VMware's VirtualCenter management server), but it oddly did not have the same settings that we chose upon creating it with the TotalView tool.
We reinstalled the software, which seemed to help matters, and after adding the ESX VirtualCenter host to the TotalView system, we could then successfully execute commands like Clone, Stop and Start although other commands like Migrate and Clone To Template were grayed out in the application and therefore unusable.
Moves-adds-changes
After creating VMS, we weren't allowed to migrate them as that option was grayed out in the options box. We could do this manually -- outside of TotalView, with VMware's tools on VMware and using Citrix XenServer tools.
When we tried to snapshot a VM with TotalView, it seemed like it took the snapshot (we used the VMware Infrastructure client to verify that), but reverting back to the snapshot that was taken, then showed only a black screen and did nothing else. TotalView snapshots did not include the option to save the VM's memory contents (an option that in VMware's client is checked by default), therefore if you take a snapshot of a live VM and then revert while the VM is on, corruption could happen, as we indeed witnessed.
Operational management
To setup TotalView for day-to-day VM management of environments, we had to connect our virtual environments to the TotalView interface. For each environment, (XenServer, VirtualCenter or plain-old ESX server), we had to enter our credentials. After that, TotalView imported all our virtual machines into its GUI and listed them for us. Then we were actually somewhat able to manipulate and control the hosts.
Our beef here is that there is no real-time data collection of what's happening in the VM farm. There are only snapshots of a single state rather than continuous monitoring or graphing of real time data.
We also need to point out that refreshing the GUI screen did always update the display after we had changed settings or performed a management task. For example, after changing the number of vCPUs allocated to a particular VM, the view showed the previous allocation until we closed the tab and re-opened it again.
User role management was lacking in comparison with the other products tested. There were different user profiles available to us, but no way to restrict what users could really do in terms of access and manipulating the managed VMs. We could only select the administrator role, which gives a user full rights to manage all machines in the virtual environments and use all administration settings (such as scheduling, creating new policies for alerts, adding new users or other admin tasks) or non-administrator roles (people who can manage the VMs but can't set any administration settings).
Each profile was considered a brand new one, and therefore, we had to manually add the virtual environments again to each profile, which is a time-consuming process as each virtual environment can be password protected.
Incident management
There are actually several options for setting policies that would trigger alarms. If they would work properly, they would be of more use, though. For example we tried created a policy using TotalView to watch VMs should CPU usage exceed a certain threshold on VMware machines, as there were not any metrics for XenServer available that went above a certain level.
We also attempted to apply a policy for network usage. We walked through the steps of selecting and applying the new policy and when we tried to view the status of the policy, the application crashed.
TotalView neither adds nor detracts from VM instance or VM farm security in anyway.