t's been a long time coming, especially since they're one of my favorite concepts in VDI, so I finally decided to sit down and get hands-on with Kaviza's VDI-in-a-Box solution. I had high hopes coming out of the gate, and I wasn't disappointed. Kaviza has so many interesting features out of the box, it's worth listing some of them here before moving forward:
- Simple to stand up - each server is just a virtual appliance
- Simple to expand - just load more virtual appliances on to more hosts
- Works with XenServer or ESX
- They licensed HDX from Citrix, so you can use it with your virtual desktops
- Local storage model, keeps data replicated between hosts, no need for expensive SAN
- Low cost, and low risk for implementation
It's fairly easy to follow the process from start to finish, so that's the route this review will take. The most complex part is actually creating the master VM, but we're not talking anything extraordinary. You just get spoiled when it takes less than 30 minutes to install the hypervisor and the Kaviza virtual appliance.
Before I get started, though, I want to mention that each step in this process is meticulously documented in the support documentation from Kaviza. If you're curious about VDI-in-a-box, and you have a free day (or even afternoon), you should be able to get it up and running pretty easily.
Like I said, this is crazy easy. Install the hypervisor, download the virtual machine image from Kaviza, and import it. My test was done using XenServer since I had the install disk right in front of me. This is the free XenServer, too…no add-ons or anything. I thought about recording video, but there's not really a point to it since it's so simple.
Kaviza's simplicity is due as much to its ease of installation as it is to it's grid operating model. Standing up more VM hosts is just a matter of importing the virtual appliance, setting the IP address, and pointing it to any other Kaviza server in the grid. I installed XenServer in ten minutes, and five minutes later I had another Kaviza server in the grid.
Once in the grid, each server watches all the other servers to maintain usage and load balancing information. Servers can be pulled from the grid for maintenance through the management console.
Building the base VM
As I mentioned, creating the Base VM is the most time consuming process when setting up VDI-in-a-box. Part of the reason for this is just that installing and tweaking Windows takes some time. There are also some steps that Kaviza introduced that, while the may take a bit more time, makes image management easier down the road.
Creating a VM is, at the highest level, a three phase process: creating the VM, importing the VM into Kaviza, and preparing that VM for users.
Phase 1: Create the VM
Since I'm using XenServer, I created a VM from XenCenter and installed Windows 7. Since I'm not performance testing, I didn't pay much attention to the settings, but I did use the recommended 1.5GB of memory that Kaviza suggests. I used Windows 7 32-bit, but 64-bit is also supported.
After getting Windows installed, there are the steps that are taken to get the VM ready for import into Kaviza:
- Activate Windows and enable the local administrator account, which is disabled by default
- Install the hypervisor tools, in my case, the XenTools
- Enable remote desktop connections and allow Domain Users (or whatever group you want) to connect
- Tweak the Windows firewall to allow remote desktop connections (and HDX on 1494 and 2598, if you're using HDX)
- Install Microsoft Hotfix KB976494, "Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2"
- Test RDP connections from another box
- If you're using HDX, install .NET Framework 3.5
- If you're running ESX, you need to uninstall the VMware SVGA 3D driver
Phase 2: Import into Kaviza
This part is pretty simple. You first log in to the Kaviza management console and browse to the Template tab. This is where the bulk of image management takes place. At this point, you'll create a "Working Image" by importing it into the system.
The import process reboots the VM and checks to make sure that the proper communications exist between Kaviza, the hypervisor, and the VM.
After importing the VM, you'll install the Kaviza VDA, which contains all the bits that let the Kaviza management box talk to the VM. Next, Next install.
Phase 3: Save the "Working Image" as a "Desktop Image"
Once all the prerequisite steps have been completed and the VDA installed, it's time to convert the "Working Image" to a "Desktop Image." This boils down to sysprepping the image, which the Kaviza management console takes care of for you.
After completing this process, Kaviza recommends you start the image and test it out, then re-sysprep it (Kaviza calls it "prepare) before deploying it. I actually followed this instruction, and I'm glad I did, because I uncovered a name resolution issue between my domain and my DHCP server that made it so I couldn't join the domain automatically.
Creating a Desktop Image
After creating the base image, of which you can have several, you can then create the actual desktop images that will be provisioned to users. During this process, you can do some basic configuration:
- Choose which base image to use
- Configure how much memory each VM will use
- Choose whether or not to connect local disk drives, printers, serial ports, or smart cards
- Maximum number of desktops to use this image
- Number of pre-started desktops for fast user logons
- …and a few other template-specific things
After creating the desktop images, you can provision them to users or groups within your organization. You can integrate Kaviza with AD, or you can have Kaviza maintain its own user database. This is all done from the management console, and is all pretty self-explanatory. It's one more thing that "just works" with this solution.
Connecting to virtual machines
Kaviza uses a Java-based client, which means they can support just about any endpoint you can think of that also has an HDX or RDP client. The list from their documentation includes:
- 32/64-bit Windows XP, Vista, 7, plus embedded versions
- 32-bit RHEL 5.x, CentOS 5.x, Ubuntu 10.x, plus embedded versions
- MacOS 10.5 or 10.6
- Apple iOS devices (iPad, iPhone, iPod Touch)
- Several 10zig and Wyse thin clients, including the Wyse Xenith (this is Wyse's zero-client that supports HDX)
If you're using Kaviza with the HDX option, you're able to connect directly to Kaviza desktops using the Citrix Receiver without a Kaviza client (which is why Wyse Xenith is supported). You lose some functionality this way, namely load balancing (meaning you need to know exactly which VM to connect to when using just the Receiver).
The logon process via the Kaviza client is relatively simple. You can download the java applet that consists of the "normal" client, then launch it to connect, or you can browse to the web interface and launch the desktop from there.
Kaviza can fail back to RDP if the Citrix client isn't available. When connecting, Kaviza checks the following things:
- You're using an HDX licensed version of Kaviza
- The endpoint device isn't connecting via the Kaviza Gateway
- The Citrix Online plugin is installed
If any of those requirements fails, RDP is used instead of HDX. Users can also connect via RDP even if HDX is possible by clicking a link on the Kaviza client logon screen.
There are detailed instructions in the "Kaviza VDI-in-a-box User Access Device Configuration Guide" for the endpoints listed above.
Image management in Kaviza is a fairly simple process that appears to be quite effective. When the need arises to update an image, you can simply create a working image based on an existing image. From there, you can decide whether the new image, when saved, will replace the original image or become its own standalone image.
If it replaces the original image, the image will be refreshed according to policies that you configure on the image properties screen. This can be on logout, at scheduled intervals, or both. Admins can also force desktop refreshes.
On ESX, Kaviza supports Linked Clones right out of the box. In order to support thin provisioning on the local disk in XenServer, you must reformat the local storage repository to the EXT3 filesystem as opposed to LVM. The only downside to this is that you need to know this before you set up your Kaviza test lab on XenServer because the process wipes the local storage :)
So, if you want to use thin provisioning on XenServer, follow the "Instructions to enable thin provisioning on XenServer.pdf" document FIRST, then proceed as you would normally.
The Kaviza Gateway is a remote connection solution that uses the TS Gateway role on Windows Server 2008 to wrap RDP traffic in an SSL tunnel for secure external access to Kaviza desktops. The Kaviza Gateway service is a Java application that runs on the TS Gateway server and connects you into the Kaviza environment to take advantage of load balancing and session reconnection.
One thing to note is that the Kaviza Gateway is RDP only, which is kind of a bummer because HDX has better performance on the WAN. Hopefully there will be a future update that fixes this.
I had to think a little bit about how to wrap this up. There were so many good experiences with this product, I wanted to make sure I balanced the review with what I thought could use some work. Here's what I came up with:
- I'd be interested in hearing how well Kaviza scales both upward and outward in real-life scenarios. It seems like the grid architecture is pretty chatty on the network, and that there might be a limit to how many hosts you can have in the grid. I also wonder how many VMs per host it can support. Not that I see anything that concerns me with the implementation. It's more out of curiosity.
- The Kaviza Gateway bring RDP only is unfortunate. I hope to see an update in the future (even if it means they have to roll their own gateway instead of using the TS Gateway) that supports HDX.
- I'd like to see some sort of branch office solution in there. I'm sure you can add hosts to remote locations, but configuring your environment so that a) users get a desktop on a server that's local to them and b) there isn't much replication traffic across the WAN would be pretty cumbersome. If there was a way to configure one server at a remote location as the "master" to save replicating data across the WAN multiple times, that would be a big deal.
So, that's three things I could come up with. One of them is just a question I have, one is an actual problem I have with the product, and the other is a feature that I made up. Not bad!
I don't test scalability in these First Look articles because I don't have the hardware to do it accurately and, even if I did, my use case would be different than yours. With Kaviza, this is no big deal. It's so easy to get running that anyone with a few hours (say, this Friday after Thanksgiving in the U.S.) can try it out. The installation documents take you through the process step-by-step, and you'll have it running in no time. If you haven't seen the product yet, give it a shot. I bet you'll be surprised. If you have any experiences to share, please do so in the comments.