Kaviza in Action
The installation and setup process for Kaviza VDI-in-a-Box involves importing the appliance into a virtual machine, configuring the Kaviza grid, setting up the user database (standing alone or linked to Active Directory or LDAP), defining templates, creating virtual machines and deploying virtual desktops.One of the first things I was impressed by was the ease of initial deployment-The main Kaviza management element runs as a virtual appliance on Citrix XenServer and proved to be very easy to set up and configure. Only some basic chores had to be performed, such as creating a storage pool and assigning an IP address.The Kaviza virtual appliance is managed via a browser-based console called kMGR. kMGR is easy to navigate and offers a wizard-style experience. From kMGR I was able to select what hypervisor to use, configure my grid, create users and start building virtual desktop templates, as well as create system images. With the initial planning behind me, the next step in the setup process involved creating templates for virtual desktops. To create those templates, I had to start with a base operating system to run on the yet-to-be-defined virtual machines. Creating the images to build templates is a straightforward process that involved running the host operating system inside a virtual machine. For example, I was able to create basic templates by launching a wizard and inserting my original Windows XP CD and my Windows 7 DVD. Basically, all you are doing during this stage is building a virtual desktop using the OS of your choice. The real magic begins once you start creating templates to deploy those virtual desktops to users. Templates offer a great deal of flexibility: I was able to create templates that contained a primary operating system, line-of-business applications and some custom settings quite easily. A template can then be associated with particular users, allowing you to quickly supply them with customized virtual desktops. You can also modify templates as needed to add applications, apply patches and make other changes. Ultimately, templates become the most important part of a Kaviza deployment. Kaviza includes some basic settings to speed up creation of templates; however, I found that there are several options available for designing a template, covering aspects such as disk usage and allocated memory. Once I had my templates created, the next step was to move on to a deployment experiment with some desktop PCs. Arguably, the most important element of VDI is the end-user experience (although I don't know who would argue against a good end-user experience). Creating an acceptable experience has been a challenge for many VDI vendors, simply because of the complexity of managing connection brokers, balancing loads, countering latency and scaling on demand. Kaviza eliminates many of those issues by eschewing connection brokers and incorporating other technologies directly into the Kaviza appliance. While that makes deployment and management easier, does it actually benefit the end user? In Kaviza's case, it does-Kaviza incorporates Citrix Systems' HDX technology, a display protocol (with associated elements) that delivers what Citrix refers to as a high-definition experience for users of VDI desktops. Simply put, HDX incorporates advanced algorithms and compression techniques to reduce latency, increase throughput and manage I/O, which the company says gives a desktop virtualization user the best possible experience. I found that to be true during my tests: The virtual desktops I ran from my client PCs performed very well, perhaps as well as a local virtual machine would on the desktops I tested. Kaviza offers multiple paths by which an endpoint can connect to a virtual desktop. You can connect your physical PCs via a browser session or by downloading and installing a small Java client application. For those who will be using a virtual desktop consistently from the same PC, I recommend going the Java client route. When first accessing the Kaviza appliance from a PC, users are given the option to install the Java application-sort of a self-serve approach to VDI. However, it may prove to be beneficial to push the application down to the desktop using a policy, removing the end user from the equation as much as possible.