Kaviza VDI-in-a-box comes closer than either Pano Logic or NComputing to being a one-size-fits-all desktop virtualization solution. It is also straightforward to deploy. Available as a preconfigured virtual machine, Kaviza installs into an existing VMware ESX/ESXi or Citrix XenServer infrastructure, and it provides connection brokering, load balancing, user access control, and guest VM management in a single browser-based console. It supports both Microsoft RDP and Citrix HDX remote access protocols, as well as Kaviza's own Java-based client, so client access is nearly universal.
Unlike Pano Express, Kaviza doesn't come in a big box with lots of geeky goodies to install and configure. For deployment, IT will simply download the Kaviza virtual machine from Kaviza's website and import it into their existing VMware or XenServer host (support for Hyper-V is forthcoming). At first glance, the requirement to have a hypervisor already in place would seem like a deal breaker when compared to other solutions that include the server hardware (Pano Express) or require nothing but a good desktop PC (NComputing). But if you crunch the numbers, a typical virtual desktop using Kaviza can be had for about $425 per concurrent user (based on 50 users) -- including server hardware, VMware hypervisor, the Kaviza software, and Windows client licensing.
One reason the cost is almost half the price of a standard desktop PC is that Kaviza runs just fine on a "commodity" server, by which I mean a server with about eight CPU cores, 32GB of RAM, and some form of fault-tolerant local storage. There's no need for an expensive high-speed SAN or redundant servers. Kaviza claims this platform can handle at least 30 concurrent users. I didn't try to replicate that in my lab, but I had no trouble with 10 simultaneous users running 32-bit versions of Windows XP Pro and Windows 7 Pro on similar hardware.
Kaviza installation and configuration
For my test, I installed Kaviza on a dual-Nehalem server with 24GB of RAM and 900GB RAID 5 array of SAS drives. My hypervisor of choice was VMware ESXi 4.1, and while I had two Gigabit Ethernet NICs in the server, I connected only one to my production network. Installation of the Kaviza virtual machine into ESXi was very straightforward, and it took only about 15 minutes. Once Kaviza was installed and running, I was able to complete the initial configuration using my browser in just under 10 minutes.
Part of the configuration process is defining a grid -- Kaviza's term for a collection of servers hosting the Kaviza management system. The grid allows a Kaviza infrastructure to grow over time and provides load balancing across Kaviza hosts. As VDI needs increase, IT can simply configure another host server with Kaviza's management virtual machine and insert it into the grid. Kaviza will dynamically load balance among hosts based on the underlying server hardware. For instance, if I added a server to my existing grid that only had 16GB of RAM and one quad-core CPU, Kaviza would run twice as many virtual machines on the dual processor server than on the one with a single CPU. This makes it very easy to scale a VDI deployment up without re-architecting the whole system.
Getting a guest virtual machine into production is not as straightforward as simply spinning up a new VM. The multistep process begins with importing an existing virtual machine into Kaviza as a working image. (You can't create a VM within Kaviza.) Primping the working image takes the most time, and it includes installing the Kaviza desktop agent, making sure all business applications are installed, and "preparing" the image -- basically a Microsoft sysprep function.
Once the image is prepped and saved, IT can create templates based on the image that define how much RAM to assign to the virtual machine and what client-side resources (such as disk drives, printers, and USB serial ports) can connect to the VM. In addition to creating a standard configuration, a key function of the template is to set policy as to how many virtual machines to automatically have running (and waiting for users to log in) and the maximum number to spin up.
Kaviza virtual desktop options
Probably the most important function of the Kaviza template is to define the refresh policy for the assigned virtual machines. In most cases, you would use Kaviza to deliver a standard desktop image to multiple parties -- spinning up clones from templates and working with Active Directory roaming profiles to assign personal settings (the My Documents folder, Outlook email settings, printer assignments, desktop icons, and so on) when users log in. But because the users' desktops are based on virtual machines, you also have the option of providing more persistent desktops. The refresh policy determines how persistent -- if at all -- a virtual machine will be.
For example, based on a template for basic office work, I created one VM that was refreshed -- that is, destroyed -- at user logout. Kaviza dutifully deleted the virtual machine and spun up a new one based on the template to replenish the pool. By refreshing on logout, no matter what happens during a user session, the next time the user connects the "PC" is just like new. Other options are to refresh on a set schedule (midnight each night, for example) or manually.
The manual refresh option is as close as you can get to providing a user with a traditional, persistent desktop. The user can install programs and customize the environment, and all of their changes will survive from session to session -- until a virus or other problem creeps in, and the virtual machine must be reset. In order to sustain these persistent desktops, IT will need to back up the virtual machines -- a task that falls outside the realm of Kaviza (and its competitors). Another downside of persistent VMs is significantly greater storage requirements. Because dynamic VMs are based on linked clones, they require only a fraction of the disk space of a full virtual machine.