Virtual Bridges VERDE 5 has been released. Here's my take:

A couple weeks ago, Virtual Bridges announced the release of VERDE 5, which is a pretty substantial update to the VERDE line of desktop virtualization solutions.

A couple weeks ago, Virtual Bridges announced the release of VERDE 5, which is a pretty substantial update to the VERDE line of desktop virtualization solutions (here's our video with Srini Gurrapu, shot at VMworld 2010). Avid readers will remember that we took a pretty deep look at Virtual Bridges VERDE 3 back in March during our first-ever Geek Week. Shortly after Geek Week, they released version 4, which added a snazzy web interface and RDP connection brokering (version 3 only supported direct connections via RDP). VERDE 5 builds on that, offering several enhancements and one new feature that we've been looking forward to for a very long time: SPICE.

I fully intend to do a review similar to my VERDE 3 review in the next week or two, so I'll save the gorey details for that article. Still, if you have any questions, feel free to post them in the comments. Virtual Bridges is pretty good about responding to our articles, and if we can't figure it out, I'll take the question to them. For now, let's take a look at a couple key features in this release:


One thing we learned during Geek Week was that the VERDE protocol wasn't going to cut it as the world looked towards PCoIP, HDX, and RemoteFX. RDP brokering was included in VERDE 4, but the choice was still between it and the VERDE protocol. The VERDE protocol's advantage over RDP was that it was implemented outside the VM, which meant that you could watch the machine boot and not rely on in-VM services to start running before you could connect.

When I wrote about it in my VERDE 3 review, I mentioned how valuable I thought SPICE would be, especially since VERDE uses the KVM hypervisor, which is required for SPICE (and means that SPICE also runs outside the VM). At the time, the open implementation of SPICE was deemed unusable by Virtual Bridges, so it was left alone. Skip forward to version 5, and, with a lot of help from Virtual Bridges, the open implementation of the SPICE protocol is ready for business!

In VERDE 5, Virtual Bridges has replaced the VERDE protocol altogether with SPICE (Whew! Watch me dance around my opinion of the VERDE protocol during Geek Week). RDP is also available as an option, and you can configure which protocol is used based on the type of connection from the client side.

On thing that's important to note is that Virtual Bridges had to add full USB 2.0 support. Their USB solution is implemented in both RDP as a virtual channel and in SPICE as a separate client side plugin. The implementation allows the use of just about anything: USB drives, keyboards and mice, printers, scanners, barcode readers, check printers, etc. The type of devices that are allowed is configureable in the management interface.

If you've got nothing better to do and want to get your propeller hat spinning, check out the "Spice for Newbies" pdf from official SPICE Project website to learn about the ins and outs of SPICE.


Management is the other main enhancement in VERDE 5, and it's nothing to ignore compared to past versions. VERDE 3 barely had any mangement or monitoring tools that weren't command-line oriented. VERDE 4 took the first step into web-based management, and VERDE 5 has taken that to the next level. VMs can created and provisioned using the management interface, and admins are now able to select what deployment methods are available for each gold master image. Images can be deployed to any or all of: VDI, LEAF Drive, or LEAF Desktop. LEAF is Virtual Bridges' client hypervisor. I'll be taking a good look at that in my full review.

Also in the management interface is the ability to manage VERDE Branch servers and monitor all the servers and sessions in your environment. While this isn't anything new in the industry, it's all a big step for VERDE as it tries to become one of the big names in the business.


It's not all roses, as SPICE supports neither SSO through the web interface nor Aero Glass. The latter is a limitation of SPICE, however, and hopefully that will be resolved and made open in the future by Red Hat. In addition, the Red Hat QXL GPU is a fully virtualized GPU, so when you're really pushing the graphics hard there is a performance hit on the host. What that hit is remains to be seen, and I'll try to at least give an example of it in the upcoming review.

I'm excited to see SPICE in action outside the confines of Red Hat, and the fact that Virtual Bridges has put together this complete of a solution is pretty remarkable. I hope that it's still as easy to stand up as it was in the past, but we'll find out soon enough.

One last thing I want to mention, and I only do so because I want to know what everyone thinks about it, is that Virtual Bridges announced that IBM has put together a reference architecture where they use VMware ESX to virtualize servers and Virtual Bridges VERDE to virtualize the desktops. This dual-platform solution is all managed by Tivoli, and is used to provide desktops to their service provider customers like AT&T.

Having never been on the service provider side of the house, much less been in a shop where everything was IBM, what are your thoughts on it? Being able to manage both platforms from one place seems like a cool idea, but only if it doesn't over-complicate things.

That's it for now, but I'll plug the review one more time. Keep your eyes peeled in the next week or two for a hands-on review of VERDE 5. If there's anything you want me to take a look at in the lab, let me know.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

"Skip forward to version 5, and, with a lot of help from Virtual Bridges, the open implementation of the SPICE protocol is ready for business!"

What does that mean? From what I can tell Virtual Bridges aren't part of the spice community at all - no patches submitted, no bug reports, no developers involved - what exactly did they do to make spice ready for business?


@ianwoodstock - I'm sure all Gabe meant was that having made SPICE an option in their VERDE product, Virtual Bridges has gotten it into more people's hands.  Fedora 14 added SPICE support but it is still a very manual process and it is not supported yet in their virt-manager GUI at all.  Expect that in Fedora 15.  RHEL 6 doesn't support SPICE in virt-manager either but expect that in RHEL 6.1.  Oh, almost forgot... Virtual Bridges has made SPICE more usable in VERDE by including a separate USB stack, as Gabe indicated.  SPICE doesn't currently include USB support but I've been keeping an eye on the spice-devel mailing list and USB support is on their roadmap and they are making progress so perhaps it'll be there next release.

@Gabe - Red Hat's RHEV for Desktops has supported SPICE for some time and I would expect that it is "ready for business" too.  You were trying to get a RHEV environment setup so you could do a review but ran into a snag I believe. I hope you can get past whatever the issue is so we can get that RHEV review sometime in the not too distant future.

I've tried SPICE with Fedora 14 and was impressed and will be happy once Fedora 15 and RHEL 6.1 come out so getting it going is much easier.

One thing about SPICE though is that I don't think that it works very well for WAN connections under 500K/sec.  Here is a study that compares SPICE to RDP:

In addition to SPICE I'm really looking forward to the release of No Machine's NX 4.0 that adds a lot of capabilities including server sides for Windows and Mac users.  Once NX 4.0 is release, I'm guessing that Virtual Bridges will add it as an option.  In the past it was an option only for Linux VMs.  I assuming NX 3.x is still available in VERDE 5 for Linux VMs?

The down side to NX 4.0 is that it is NOT open source and if you want more than two users, it isn't free.  I can tell you that NX 3.x uses considerably less bandwidth while giving a very good experience.  With the added features in 4.0 I'm sure the bandwidth usage will increase but I'm hoping it will still be usable on slower connections whereas SPICE is not.  Also, as Gabe mentioned, SPICE is limited to use only with KVM VMs whereas NX is a general purpose remote display protocol that can be used for terminal services type use cases as well as VDI.  I was hoping that Red Hat would buy No Machine and open source NX 4.x but of course that is just a dream at this point but I'll keep my fingers crossed.


@Scott - Spice doesn't include native USB support so solutions that use Spice, for example Red Hat Enterprise Virtualization include a separate USB stack, although we are working on a native USB implementation for Spice.

Spice versions < .06 aren't optimized for WAN so there's a significant difference you'll see in the spice version in rhel 5/6 (used by RHEV and by Verde) and the work we've done upstream that will be shipped in RHEL6.1 - that will make spice appropriate for WAN and LAN workloads, amongst the many other goodies in upstream spice.


Thanks for the comments. @Ian, I'm not trying to give undue credit, but Virtual Bridges has had to roll their own USB support and build Spice into their broker. That's something that had to be done to make the open implementation of it useable with VERDE.

It seems you are ticked off that they haven't contributed anything to the open project. I'm not sure what the proper etiquette is in the OSS space--maybe that's a bad thing--but it doesn't mean that VB hasn't had to do stuff to get Spice working in VERDE.


Will that .next version of Spice be open as well? I'm not sure how all that works.

@Scott Dowdle:

I'm not aware of plans to integrate NX 4.0, but that doesn't mean they won't do it, especially if it's simple enough. If it's difficult, it might be one of those things where they wait for a customer to ask for it. You are correct - NX 3 is still in there for Linux VM's.

As for my eval of RHEV-D, I ran into some hardware snags, I think, and couldn't support the system. I have more stuff running now, so I re-added it to the (ever growing) queue.