I've been keeping tabs on Virtual Bridges VERDE for a little over a year now, and it's been interesting to watch the product grow over time. The latest release, VERDE 5, includes just about every current VDI technology in some form or another. They have a VDI broker that uses RDP, Spice, and NoMachine NX. They have a Type-1 client hypervisor called VERDE LEAF, and branch office replication via their Branch product. All of this is managed via a browser-based management console as opposed to VERDE 3 (my last First Look at the VERDE), which was mostly command-line. Additionally, all of this is also sold as a single SKU, so when you buy VERDE, you get it all.
This version of VERDE is still pretty easy to stand up, and I'm pretty certain that Virtual Bridges' CTO Leo Reiter could equal his 33 minute installation that he did at Geek Week last March. Knowing that, I decided to put on my propellor hat and give it a try on my own. I'll break this down into four main sections (VERDE VDI, VERDE Branch, VERDE LEAF, and Spice experience), plus a wrap-up.
Virtual Bridges VERDE VDI
Under the covers, VERDE 5 is similar to VERDE 3 in that it runs on the KVM hypervisor. Red Hat (who switched to KVM from Xen around the time that they purchased Qumranet) and Virtual Bridges are the only two desktop virtualization solutions I'm aware of that use it. That's not a bad thing, but it does make KVM a lesser-known entity. Detractors argue that it's not a great hypervisor for server workloads, but some feel it is a good fit for desktop workloads. IBM seems to agree, because they've announced that they'll be using VMware ESX for virtual servers and Virtual Bridges VERDE for their virtual desktops.
VERDE VDI can be installed on any server with virtualization technologies (Intel VT or AMD-V) enabled. That's kind of a no-brainer, but I only mention it so people don't mistake it as a way to re-purpose old hardware. The Cluster Master (we'll get to that later) component can be installed on a server that doesn't have any virtualization technology, but good luck finding a server like that these days.
Regarding guest OS support, rather than try to generalize it, here's the official list, straight from Virtual Bridges:
- 32-bit and 64-bit Windows XP1 Professional, any service pack
- 32-bit and 64-bit Microsoft Windows 7 Professional, Enterprise, and Ultimate Editions
- 32-bit (i386) Ubuntu 8.04 LTS ―Hardy‖ Desktop Linux
- 32-bit (i386) Ubuntu 9.04 ―Jaunty‖ Desktop Linux
- 32-bit (i386) Ubuntu 10.04 ―Lucid‖ Desktop Linux
- 32-bit and 64-bit Novell SUSE Linux Enterprise Desktop 11, any service pack
- 32-bit (i386) or 64-bit (x86_64) Red Hat Enterprise Linux 5.4 and 5.5 Workstation, any updates
- 32-bit (i386) or 64-bit (x86_64) CentOS 5.4 and 5.5, any updates
The networking is still very similar to previous versions with three options: Basic, NAT, and Bridged. Basic, you might recall, isolates the private, virtual network from the rest of the network via a lightweight NAT, but it removes the ability for each machine to appear as it's own entity on the network. It works all right for web browsing and mapping drives to UNC paths (not browsing the network), but its usefulness ends there. I've been told that this is going away in future versions, but it's still there today. If you're trying out VERDE and tempted to use it, I'd go for either of the more traditional choices and avoid the headaches.
Note: There is a video at the end showing the Spice user experience. Sure, I'd like you read this whole thing, but I understand if you scroll down to it.
This area has seen what I believe to be the biggest enhancement to VERDE 5--the addition of the Spice protocol. I talked a little bit about this several weeks ago with the announcement of VERDE 5, and it's exciting for a couple reasons:
- Since Spice runs outside the VM, you're able to watch machines boot and control them more directly without waiting for Remote Desktop Services to start. This also means that there is no need for the older, not-so-good VERDE Protocol, which has now been removed from the product.
- It gives VERDE a LAN-oriented protocol that can compete with the likes of HDX, PCoIP, and RemoteFX. It's not there yet, but with some continued enhancements from both Red Hat (who technically owns Spice and releases it to the public as OSS) and Virtual Bridges, it could be soon.
There are a few limitations of Spice in general that hold it back from being a top-notch protocol and/or experience:
- It is tied to KVM. This is not a problem for Virtual Bridges, but it does hold back its widespread adoption. Being tied to the number 3 or 4 hypervisor just doesn't get it much exposure, so there's not as many people using it or developing for it.
- There is no 3D support for things like Aero Glass. This is a limitation of Spice itself, however, and there are some rumblings of 3D support in a future version, as well as GPU offloading. Currently, Spice uses the fully virtualized Red Hat QXL virtual GPU.
- In VERDE (not sure about RHEV for Desktops), there is no single sign on for Spice sessions. This means when you log on to the VERDE web interface, you still have to log on to the VM once it starts.
I should probably add that USB support is not available out of the box in the OSS implementation of Spice. Virtual Bridges had to add USB support, which is accomplished by the use of a third-party USB stack that has been coded seamlessly into the product.
If Spice is new to you, check out Brian's article "Red Hat makes the Qumranet SPICE protocol open source. A free alternative to ICA/PCoIP," which goes into how Spice works and how it can fit into our landscape. It's from just over a year ago, but it's still relevant today. You can also check out the relatively short but informative "Spice for newbies" whitepaper from the Spice project's web site.
Also new since the last review (which was two versions ago) is that RDP is now officially supported as a brokered protocol. In version 3, users could only access VMs directly via RDP, but since version 4 the user is able to choose which protocol they want to use when the sign in to the web interface.
Active Directory Integration
I'm following the same headings as I did for the VERDE 3 review because some things have changed. In this case, nothing has changed. VERDE 5 integrates with Active Directory using a free product called Likewise Open. Installing this on the VERDE VDI server (which is super easy and takes about 2 minutes) will essentially join it to the domain, at which point users can authenticate against the domain to log into the web interface. The alternative is local authentication to the Linux server using PAM, and nobody wants that in a Windows world :)
Thin Provisioning, Applications and User Data
(Note, I pretty much rewrote this entire section after publishing. I learned some new things and it was less confusing to just rewrite it.)
VERDE uses copy-on-write technology as it's thin provisioning mechanism. Changes during a session are written off to a temporary disk image which is destroyed at logoff. Due to this, applications cannot be installed by the users (well, they can, but they won't be there the next time they log on).
User data is stored in a separate disk called a User Data Disk. The user's profile (including all documents, settings, and so on) are stored on the user data disk, and this disk is persistent across sessions. The exception to this is with VERDE LEAF client hypervisor (covered in more detail later on). Changes to the profile are stored locally, but only files and folders are synchronized back to the data center. This means that a LEAF user who signs into their desktop from a non-LEAF endpoint will have access to their files, but their settings will not necessarily be the same.
A user-installed application layer is in the works for dynamic desktops, but for the time being users will need to install applications on to their user data disks or use 1:1 static desktops in order to have them persist between sessions. This may or may not be a big deal to you (since you might have been planning on 1:1 anyway).
Load Balancing, Cluster, and Session Brokering
This is another area that fundamentally remains the same. Load balancing in VERDE involves creating a cluster that consists of a few different types of server:
- VERDE Satellite servers that actually host desktops
- VERDE Cluster Master server that holds the session directory
Users connect to the Cluster Master before being redirected to a Satellite server that actually runs their desktop. If a Cluster Master goes down, existing connections are not affected, but new connections cannot be made. When a Cluster Master with the same address (it doesn't have to be the same exact server) comes back online, the Satellite servers automatically contact it and synchronize their session information to rebuild the session directory.
Client Devices, Local Files, and Printing
A number of platforms are supported as client devices, but there doesn't appear to be any thin clients with native support for VERDE. There is a full-featured Windows client that supports Spice and NoMachine NX 3 (on top of RDP, which is already supported by the OS), so any thin client that runs an embedded version of Windows should work. Since VERDE's Linux roots run deep, there is also a full-featured Linux client with support for all protocols. Mac users are able to connect via RDP or NoMachine NX 3. As a Mac user, I hope to see a Spice client for Mac soon, but at least it's usable.
Virtual Bridges has also jumped on the iOS bandwagon and released an iPad/iPhone client. It's not a Spice client, which would've been remarkable, but it does a decent job of remoting RDP. The thing that makes it special is that it connects to the cluster master, which redirects you to the appropriate virtual machine, rather than connecting directly (which you'd have to do with a "regular" iPad RDP client).
Printing is a simple, PDF-based solution when dealing with locally-attached client printers. Acrobat Reader on the client is required to print from VERDE sessions on Windows endpoints. Printing to the client device by default can be configured when setting up the gold image by mapping to a standard, virtual UNC path that the VERDE client will connect to at launch. Of course, network printers work just as you'd expect.
Local file access works by configuring a virtual IP address in the virtual machine that points to the client device. By doing this, the VM is able to connect via a private network to the client and access any folders that have been shared. This leaves a little the be desired because it A) requires the user to share folders that they may want to see in their VM, and B) leaves open shares out there that could be accessed across the entire network. Of course, there are ways to fix both of those, but the fact that you have to put so much consideration into granting access to local files is a little disconcerting. I'd rather see something built into the VERDE Tools client that takes care of this automatically, using a virtual channel or some such technique to connect local drives to VMs (Spice calls them VDIs or Virtual Device Intefaces. That's not confusing in the least).
Virtual Bridges VERDE Branch
VERDE Branch, and the management of it, is one thing that Virtual Bridges is very proud of. They've managed to build a pretty comprehensive solution for branch office VDI that replicates gold images to servers located at branch offices, where they are executed locally by users. This means that users in branch offices can still take advantage of the Spice experience as opposed to falling back to RDP.
The data synchronization is handled by Virtual Bridges' SMART (Self-Managing, Auto-Replicating Technology…I think the Linux guys are more dedicated to acronyms than the military!) protocol, which is also the key technology behind the LEAF client hypervisor. SMART Sync works two different ways:
- For OS images, there is a block-level, one-way sync from the datacenter side to the remote location, which can be either Branch or LEAF (LEAF is covered in the next section).
- For user data at remote locations (again, either Branch or LEAF), there is a two-way, file level synchronization.
OS image data is synchronized regularly (the system checks every five minutes by default), and users' data files are synchronized once per day at an admin-scheduled time. This means that if a user were to travel to the headquarters (or the branch server were to go offline), they would still have access to their desktop and their data. All of this is managed via the web interface, and the installation and configuration is pretty straightforward
Virtual Bridges VERDE LEAF
VERDE LEAF is Virtual Bridges' Type-1 client hypervisor that is completely integrated with VERDE VDI. It works in much the same way as VERDE Branch, except on a single-user basis. LEAF can be installed on internal hard drives and replace the OS outright, or it can be loaded on an external disk or thumb drive. During my test, I loaded it on a super-fast 32GB Patriot XT USB thumb drive, and the performance was fantastic.
At first logon, LEAF uses the SMART technology to pull down the assigned gold image(s). It makes sense to do this while still on the LAN for two reasons:
- The data transfer is pretty large, and would tie up a normal WAN connection for quite a while during the initial sync.
- The user needs to log on to the domain while connected to the network. This can be done over the WAN, but if you're going to ship a drive or laptop off to a user, that user needs to be logged into the machine ahead of time to cache their credentials for offline use.
LEAF does have the ability to connect to corporate VPN's (it even has FireFox installed locally, which should be able to connect people to SSL VPNs), so there is potential to remove the need to log on to the machine as the user before sending it to the user.
Once complete, the VM can be run offline by booting into LEAF. You're still required to log on, and the VM data is stored in an encrypted manner on the boot device, which is great for security-minded folks. Any changes to the OS or user files are handled by SMART in the same way they're handled for Branch, which is to say, user files are synchronized between the datacenter and the LEAF client, and any gold image changes are pushed down as they happen. When an OS image update is received, users are prompted to reboot in order to apply the update. By default, they can defer for up to 72 hours, at which point they have to reboot.
The management console also allows you to configure the amount of time a LEAF client can go without checking in with the VERDE server, as well. The default is 30 days, but it's easily changed. Once that time has passed, the user will not be allowed to use their VM until the LEAF client has contacted the VERDE server.
This is probably the biggest change from version 3 to version 5. In version 4, the web-based management console was introduced, but I wasn't able to spend any quailty time with it to really compare it to the new version. Perhaps the most poignant thing I can say is this: VERDE 3.0 had no web interface, which meant that all configuration, monitoring, and VM creation had to be done via command line, and all connections had to be done via a less-than-pretty client application. With VERDE 5, the only time I touched the command line was to run the installation script. Everything else has been handled via the management console, which has made things remarkably easy to access compared to previous versions.
Note: The command line interface is still available, but it is not compatible with the web interface. Images created via one interface are not visible from the other.
It's worth noting that managing VERDE relies heavily on group policy and gold image lockdown since there are no policies like we're used to with products like XenDesktop. This isn't necessarily a bad thing since a lot of the principles that go into managing and securing desktops are usually in place to begin with, but it is something to consider.
There are some new monitoring capabilities as well. You can see from the screen shot below that there is a dashboard view of the entire environment, but there are also comprehensive logs of of server and VM activity such as logon/logoff times, images used (since users can have access to multiple VMs), IP address, and deployment mode (VDI or LEAF). There isn't any vision inside the OS to see what's happening with specific processes and resources, however.
The best way to show the Spice experience is to show you, so dim the lights and fire up the video below:
I learned while talking to the people at Virtual Bridges that Spice's audio/video sync is no fluke. There's actually technology built in that separates the audio and video stream at the server and reassembles the frames in order on the client side to keep them in sync. Additionally, multiple monitors and bi-directional audio are supported (which isn't new, but worth mentioning).
I don't have a WAN emulator here to try Spice in WAN conditions, but Virtual Bridges said they did tests at 200ms connecting from Europe to the US and had "good results." A protocol smackdown is one of the ideas for our next Geek Week, and if we end up doing it, Spice will certainly be involved. We might even do Red Hat's Spice implementation vs. VERDE's Spice implementation to see if there is a difference.
It's fun to watch upstart companies and products grow up, and that's what we're doing with Virtual Bridges VERDE. The first time I saw VERDE, I actually emailed the CEO of the company (who was also my main technical contact, to give you an idea of the size of the company at the time) and asked him if it was just a workstation-based virtualization product that they rebranded to being a VDI package. I was wrong (actually, I was using the wrong admin guide), but the product was very rough around the edges. Fundamentally, though, there was something there, which is the main reason that Virtual Bridges was invited to Geek Week last March.
During Geek Week, we were shown some bits of the new management console, as well as LEAF. This was at the height of client hypervisor mania (since Citrix and VMware were only still talking about their client hypervisors, and Virtual Computer was the only company actually shipping a Type-1 client hypervisor), so seeing a fully functioning client hypervisor that we hadn't heard of before was a little shocking.
Now that we're almost a year on from there, we can see that Virtual Bridges has almost put together a fundamentally complete solution that is easily configured and easily managed.
There are a few things left to be desired. One such thing is app virtualization, but Virtual Bridges has identified and is currently working on a solution. In a future release, VERDE will have an application "layering" (their word...call it what you want) technology available. It sounds like there will be options for what technology can be used, but one such supported tool will be Cameyo. Cameyo is a fairly simple application packaging solution, but if Virtual Bridges can leverage it and build management and provisioning structure around it, it could be a pretty big deal.
There are others, such as the absence of Aero Glass and single sign on to Spice sessions (both of which will hopefully be fixed in the next major release, but I haven't heard anything specific). I'd love to hear from anyone that's using or has tried VERDE in their environment. Testing in a vacuum doesn't always present problems the same way a real-world test does, so if you have any experience, let us know in the comments.
This was a really long First Look article because there are so many products that make up the VERDE Suite, and that's probably the thing I like the most about Virtual Bridges. For one price (retail is $200/concurrent user perpetual license + 20% maintenance, discounts for volume), you get everything: VERDE VDI, clustering (load balancing), thin provisioning, a branch office solution (that I don't think can be compared to any other solution out there), and a Type-1 client hypervisor. VERDE is certainly worth including a VDI assessment to see if it fits your needs.