Since Virtual Bridges VERDE didn't quite make the cut for the Geek Week: VDI Shootout that we're doing in a few weeks, I thought I'd take a look at them on the side. You may have heard that IBM chose VERDE as the core technology for their Open Virtual Client, and while IBM's endorsement of something hasn't been the be-all end-all of product awesomeness for quite a while, it does give the indication that VERDE is a complete solution. Combine that with the strong showing it had in our product poll, and you've got yourself an article!
Not being much of a Linux guy (spare a two week sensory deprivation experiment I tried in 2004), I was excited to jump right in and figure it out. I did have a lifeline to Virtual Bridges--which I used a few times--but not for anything major. (Unless you consider getting the right manual "major.")
The very first thing I learned is that VERDE (Virtual Enterprise Remote Desktop Environment) is almost 100% command line oriented, and being a visual guy, I was a little bummed. Sure, it's not the end of the world, but of the ten or so VDI packages out there, to be the only one without an all-inclusive GUI (or even web-based) management interface is a pretty big disadvantage, (especially considering VDI is sort of a Windows-oriented thing). That said, version 4.0 of the VERDE product will be released in or around April, complete with a "full-blown management console."
Let's take a look at the nuts and bolts to see what VERDE is all about:
Like Red Hat's VDI solution, VERDE uses the KVM hypervisor. I don't want to re-ignite the hypervisor war since it's sort of divisive, but many people have gotten behind KVM, and it seems to be the real deal.
On the server side, VERDE can be installed on any hardware that has VT or AMD-V capabilities. Supported host operating systems include Ubuntu 8.04 or 9.04 (not 9.10), Red Hat Enterprise Linux or CentOS 5.4, and Novell SUSE Linux Enterprise 11.
On the guest side, VERDE can host 32-bit versions of Windows 2000(!), Windows XP, and Windows 7. It can also host 32-bit versions of Ubuntu and SUSE linux as well as 32 and 64-bit versions of RHEL and CentOS.
This part was a little confusing, especially as I tried (unsuccessfully) to join one of my VMs to a domain. It turns out the default networking model--called Basic--actually doesn't allow for that to happen. While you can surf the web and access most network resources, "Basic" networking does not allow you to do certain things like network browsing or accessing UNC paths. Basic networking isolates the private, virtual network from the rest of the world via its own internal gateway that is essentially a lightweight NAT.
While I'm sure Basic has its place, and undoubtedly fits most of the needs of a Linux guest OS, it's nice to know that the more traditional approaches of NAT and Bridged are also available and behave just as you'd expect.
And so begins the real discussion. VERDE currently has the ability to use two protocols: RDP, which is provided via the VMs only, and the RFB-based VERDE protocol. (RFB is the same protocol that VNC's based on.) Since RDP is a known entity, let's take a quick look at the VERDE protocol.
At first glance, RFB is kind of frightening. After all, VNC over a LAN is pretty bad compared to RDP and ICA, so why the hell would anyone want to use it as a production VDI protocol? Before going into what Virtual Bridges has said about the VERDE protocol, though, I feel obligated to talk about my first interaction with it:
After I got my first VERDE guest OS configured, I fired up the VERDE client and connected, assuming I was using RDP. In fact at that point I didn't even know there was another protocol available. I brought up YouTube and watched a video, thinking "Damn, this is really good!" No sync issues or anything, just like you'd expect when connecting to a Win 7 box via RDP over the LAN. Thing is, it wasn't RDP--it was the VERDE Protocol.
I fired off an email to Virtual Bridges, and they responded with all sorts of stuff about the VERDE protocol and how it's not VNC, but a VERY modified version of the RFB protocol. They say that compared to RDP 5, it's superior in most situations with the exception of super-low bandwidth, where RDP excels. They go on to say that while there's no one-size-fits-all solution, VERDE Protocol holds its own in the majority of situations they've encountered with >512kbps of bandwidth and <100ms latency.
All that said, I'm not one to just accept what a company says (although I had no idea I was using VERDE Protocol the first time I used it), and it is my goal at some point to take a real look at the VERDE Protocol in much the same way as we took at look at SPICE vs RDP vs ICA a couple years ago. Which brings me to SPICE...
I asked about SPICE, which seems like a perfect fit for a VDI solution based on KVM since SPICE was originally tied into KVM before being opened up by Red Hat in December of 2009. It turns out that there are enough reasons that the currently open source version of SPICE is unusable that an entire article can be written. So, next week, keep an eye out for that. Suffice it to say that if SPICE were usable, Virtual Bridges would integrate it.
Active Directory integration
Here's a spot I wanted to pay close attention to because identity management between different systems is such a pain in the neck. Frankly it's not even something that comes to mind when using a Windows-based solution, and this alone is enough reason for most people to choose a Windows-based solution over a Linux one. Still, it's worth a look.
By default, authentication is handled by PAM, which is the standard authentication subsystem on Linux. In order for users to be able to log in to the VERDE system with their AD credentials, those credentials need to actually be ON the VERDE system. That can be accomplished by either creating and maintaining those user accounts separately (yuck) or with some identity management solution such as Likewise Open, open source software that joins PAM to AD domains.
Configuring Likewise is pretty simple, and once you get it going you can indeed log in to the VERDE system with your AD credentials, with one glaring exception: there's no single sign on. Up until now, the AD integration has just been for authentication to the VERDE system to get access to your provisioned desktop(s). If your VM isn't started (or is locked), you'll have to log in twice. The manual says that this doesn't happen too often since after signing in the virtual machine typically stays running, but users are the reason we all have jobs, and they get confused by stuff like that.
Anyway, after you've connected to the VERDE system, the desktop's own AD membership takes over and it's smooth sailing from there. (Back in the comfort zone, baby!)
Storage and Provisioning
VERDE uses copy-on-write as its thin provisioning and storage mechanism, which is standard throughout the industry. (For example VMware calls it Linked Clones, but the concept is still the same.) A "master" image is used for each session, and any changes made after launch are saved off to a delta file specific to each user. The result is a single, normal-sized master image, and smaller delta files for each user, as opposed to a normal-sized desktop image for each user.
Provisioning amounts to running a few commands that assign a master image to a user or group, at which point the master image's directory structure is copied to each user's home folder. That's where the delta file lives from here on out.
Load Balancing, Clustering, Session Brokering
(This is a fairly complex--but not unmanageable--setup, and I encourage you to check out the VERDE Clustering Overview that Virtual Bridges has made available. I simply don't have the hardware to try it out here, but we'll take a quick conceptual look at it)
These critical roles are all handled by the VERDE Cluster solution, which consists of several components:
- VERDE Satellite Servers that actually host the desktops.
- A VERDE Cluster Master Server that acts as a session directory, keeping track of desktops and sessions across all Satellite servers.
- VERDE Workstations (which we'll get into later) that administrators use to administer the master templates.
- Authentication servers such as AD, NIS, LDAP, etc...
Users connect to the VERDE Cluster Master server, which redirects them to the appropriate satellite server based on load or whether or not they have an existing session on one of the satellite servers. Since connections are redirected, in the event the Cluster Master fails, existing sessions continue to work. New sessions, however, will not work. When a Cluster Master comes back online (be it a new one or the original one), the satellite servers automatically connect to it and a new session directory is created from scratch.
From a high level, it all seems pretty normal. The key thing to note with the VERDE Cluster solution is that it is only fully utilized when using the VERDE protocol. Virtual Bridges has said that the next version, 4.0, will contain an RDP connection broker to extend this functionality beyond the VERDE protocol.
I'm pretty sure that IBM's partnership with VERDE is hinged on this section and the next one about Branch Offices. VERDE uses the SMART protocol to synchronize the server side bits of the desktop to a client device capable of running its own virtual machines. Of course, the first time this happens, the entire master image needs to be copied along with the user-specific delta file. After that, only the delta file will need to be copied.
Once everything has been copied to the client device, the the VM behaves the same way as it would if accessed remotely, which is to say that the changes made are saved to the delta file on the client device. I assume, but did not see in the admin guide, that the deltas can be synced back up to the server at a later time. (Hopefully someone can confirm this?)
VERDE has a feature called VERDE Cloud Branch (cloud…Cloud…CLOUD!!!) in order to make it easier to access hosted desktops at branch locations. Using the same SMART protocol, master images are synced between servers. Users in remote offices then access their local server to get to their desktops, rather than traversing the WAN. Master images are synchronized across the board based on a schedule that the administrator configures.
The VERDE User Console is a GUI app that's used to manage virtual machine settings like RAM, shared folders, networking, printing, and so on. Form the VERDE User Console, you can also back up your master images and create new virtual machines (although there are some limitations with the console, and using the command line is the recommended way of installing VMs until Version 4.0 comes out).
Of course this is Linux, and it's possible to use the CLI to modify all the settings as well. Rather than go into it here, you can refer to the admin guide to see all the available parameters. There are more categories than listed here, too.
Modifying the internal parts of the VM, (e.g. Windows and application settings), can be done on the server or via VERDE Workstations, which allow you to work on master images out-of-band (VERDE calls this a replica). When the replica is shut down, the changes are automatically published, and users are shown a pop-up asking them to reboot to receive updates.
For single server session monitoring, the application "verdetop" is a take on the Linux "top" command and allows you to monitor the sessions on a single server.
Client-side printing via the RDP protocol isn't any different with VERDE than anything else. Regarding the VERDE Protocol, client-side printing is fairly uncomplicated, even if it leaves a little to be desired. It uses what boils down to a PDF-based universal printing solution, and while PDF isn't necessarily the best client-side printing method, it certainly isn't the worst.
User Data / Profiles
Last up is user data. Naturally, user data can be handled any number of ways, and as an organization you've probably already got those ways worked out. VERDE attempts to make it that much easier by separating the user profiles from the rest of the system through the use of a D: (user) drive.
This is a logical representation of storage location within the Linux filesystem, and it's the default location for file saves, AppData, and temp files (or anything else in a user's profile). Of course this is easily changed by whatever policies might be in place for file storage--it's just there as a way to keep any persistent data separate from master image.
That's all for this look at Virtual Bridges VERDE. I have to admit as I first started playing around I was underwhelmed. It was mostly my fault, though, as I was trying to do it without R-ing the FM, so to speak. Once I got my hands on the manual and asked a few questions of the Virtual Bridges folks, it's pretty clear that they've put together a legitimate VDI solution. There are shortcomings--RDP support and the management console for instance--but Virtual Bridges is aware of that and is nearing a release that will address them.
It's tricky, trying to release a Linux-based solution into a world full of Windows folks. Most of us have some experience with Linux, but only a few of us (well, not me) have the ability to manage a large, Linux-based solution with the same degree of expertise as we manage Windows environments. Because of that, it feels like it's more complicated than a Windows solution, and that makes it an uphill battle for a company like Virtual Bridges to gain a whole lot of attention. I'll be very interested to get my hands on the 4.0 product to see what they've done to make it more like the big players in the industry.
I've tried to hit on everything people might ask questions about in a high level overview, but if I left something out that you want to know about, leave a comment. If I don't have the answer, I'll pass it along to those that do.