A first look at Virtual Bridges VERDE

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.

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.

Supported OSes

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...
  • Storage

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.

Offline VDI?

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?)

Branch Offices

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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Gabe, thanks for taking such a thorough look at VERDE!

We have tried to focus on ease-of-use, even for folks who know little about Linux, and you have made us proud ;-)

One thing to keep in mind is that once this is set up, it is really drama-free. Operating requirements are simply a matter of updating gold masters as needed and adding and deleting users.

We feel the cherry-on-top of VERDE is our TCO story --  the combination of higher densities, lower storage requirements and lower software acquisition costs uniquely deliver a VDI value proposition where the numbers finally add up, whether a Windows 7 refresh or just an XP desktop infrastructure make-over. This is really where we stand apart from the field.

Thanks, again!


What does VERDE cost and how is it licensed? And what's the story with IBM? Is there a reason I'd buy it through them instead of Virtual Bridges?


Hey Gabe, thanks for a great article! I really like these "First Look" articles. Great stuff.

Also thanks a bunch on the Likewise Open hint., didn't have a clue about that. Man, I need to spend more time with than Linux thing. Heck, I will try to build OS XenClient on the Lenovo I ordered.

Here's for those interested:





VERDE Suite is available in two forms - in a paid up license and as a hosted service (announced first here). The paid up license for the full VERDE Suite is $200 per seat. VERDE Suite includes VERDE VDI, VERDE SMART (disconnected use/CSH), VERDE Cloud Branch (branch users) and VERDE LEAF (a type 1 hypervisor plus a VDI client on a USB Stick). Each of the individual components can be purchased for $100 each per seat or $200 per seat for the complete suite.

We offer volume discounts as well as government, non-profit and educational discounts that get the price down even further. We also offer special programs for under-privileged and at-risk communities.

The hosted service will be formally announced over the next few weeks.

For more info on licensing, discounts or hosted options interested parties should send an email to sales at vbridges dot com.

Virtual Bridges and IBM have a relationship across several fronts. Customers can buy from IBM as part of either an IBM Client for Smart Work (ICSW) adoption from Lotus and IBM partners or as part of an IBM Smart Business Desktop Cloud from IBM Global Services End User Services group where we are one of three official Offerings (Vmware and Citrix being the other two). By buying through IBM users can get the advantages of integrated product and service delivery with other IBM offerings. Virtual Bridges will often support IBM, either directly or through our wide range of international partners, in the background of these adoptions, especially in international markets where IBM has a closer relationship with the customer already established. Virtual Bridges is happy to sell direct, through partners, or in partnership with IBM depending on the customers preference.

There are two other product areas that will be announced shortly with IBM. We will be sure and let you know as soon as they are public.



Gabe -

thanks for the great write-up, and for getting VERDE installed+reviewed so quickly with so little help from us...

Just a couple of small points I wanted to expand upon:

1. While it's definitely cluster-oriented, it can still be deployed single server: we do have a web-based console for real-time monitoring.  It lets you view and sort virtual desktop usage, users, and server stats, as well as gracefully shut down or abort user sessions with the click of the mouse.  The console we have coming in the 4.0 release will introduce web-based provisioning and configuration as well as the existing monitoring functions that we have now.

2. Once you set up the infrastructure, you can use rules-based provisioning to make it so that all your "VERDE administration" is done in your Active Directory (or whatever enterprise directory) console.  Basically you just create simple rules that say things like "if user is member of group <x>, he/she gets instance of gold image <y>", and then all you have to do is set group membership in AD.

3. As you mentioned, managing gold images is as simple as logging in to the infrastructure using our GUI Client program and just launching the gold image - there is no command-line work needed (or any type of work) to deploy the changes made.

At the end of the day, once you install VERDE, you actually do the day-to-day admin and help desk tasks using your AD console and a web browser.  It's true that we have a good deal of command-line stuff to get it set up, but most of that is a one time thing.  And our upcoming 4.0 console will eliminate virtually all of the command-line work beyond first time package installation.

Thanks again for the great article, and thanks very much in advance for the opportunity to circle back once our 4.0 hits the streets in a few weeks,

Leo Reiter

Virtual Bridges, Inc.


Gabe, are you planning on writing about the SPICE situation in the near future?  I hope so as I'd really like to hear about it.


@Scott - Yeah, I'm trying to acquire as much info as I can.  Look for something next week, maybe the week after at the latest.



Køb Therma Power Therma Xtreme Stacker Køb ThermaPower Slankepiller Køb mere end 1 stk Therma Power og får rabat. ThermaPower Shop.



as a VERDE user I must say that you hit several main targets at a very first look! Even knowing VERDE, I have appreciated your deep and professional approach to the analysis of a new platform.

I would like to add just few words concerning Virtual Bridges' choice to go for a Linux platform. I understand you are not so familiar with Linux, but this is the best choice from the point of view of data security:

- hypervisor is executed in a protected kernel;

- Linux PAM authentication is compliant with the best security standards;

- Linux server filesystem is highly reliable, robust and safe;

- Each virtual session is executed as a Linux-discrete process, in the userspace;

- Each user's file and document is stored on the Linux server, owned by the user itself, and protected by Linux permissions and grant policies.

I am happy to know the VERDE 4.0 will provide a full GUI administration console, but I have never missed it. Putting the hands on VERDE switches through the console was a matter of just one time at the beginning, just few minutes. Further to this, my opinion is that modern GUIs are sadly pushing administrators away from the machine and this reduces their level of knowledge of the system. IMHO.

Thanks again for a great article!