Geek Week VDI Day 3: Virtual Bridges VERDE 3.0 Summary

This was actually Day 2 of our testing, and Brian was a little apprehensive because VERDE is a Linux solution that's heavy on command line and conceivably more complicated to manage.

This post, like all five Geek Week: VDI wrap-up posts, was co-written by Brian & Gabe.

This was actually Day 2 of our testing, and Brian was a little apprehensive because VERDE is a Linux solution that's heavy on command line and conceivably more complicated to manage. Gabe, on the other hand, was excited to see VERDE come in because he'd just reviewed the product, and he knew Brian would find some redeeming qualities if he got his hands on it. 

Today's article will be a summary of what we did and saw. For a more broad, big picture kind of review of VERDE, be sure to check out that review.

Virtual Bridges VERDE installation and configuration

The night before Virtual Bridges' CTO Leo Reiter came to see us, we wiped our ESX server and installed Ubuntu Linux (9.04 Jaunty Jackelope, if you're "in the know"). Other than that, we left the server alone and used the same core components that we'd been using all week (AD, DNS, DHCP, etc...).

The whiteboard

First up, we had Leo outline the product at the whiteboard. Called the VERDE Suite, Leo explained how the VERDE cluster works, where the data is stored, and how desktops are accessed.

The installation

Next for us was to prep the Ubuntu host for VERDE isntallation. To do that, Leo used SSH to connect to the Ubuntu server (you can do it from the server console, too) and install a product called Likewise Open, which connects the system to Active Directory. The installation process for this (and just about everything else we do) is run in the CLI, and consists of a single command: "sudo apt-get install likewise-open"

Configuring Likewise Open is just a matter of entering another command with the proper credentials and domain controller address. This actually binds the local authentication authority to AD so that authentications to the box are handled directly by Active Directory, not an offline replica of AD.

After we joined the domain it was time to install VERDE on the server, which was simply another command ("sudo dpkg --install verde_3.0-663.3161_amd64.deb") that took longer for me to type right there than it did to install. Seriously, we skimmed over it three or four times when looking for the command in the video, it's that short. The "dpkg" in the command stands for Debian Package, which we used because Ubuntu is based on Debian. If you were installing VERDE on a Red Hat flavored OS, you'd download a different RPM package and use the "rpm" command to install it.

Up next is configuring the web interface, which actually involves turning on VERDE Clustering. Leo edited a config file to tell the cluster that the server we're using is a "Cluster Master." The Cluster Master is responsible for maintaining a session directory of all the Cluster Satellite servers, which just plain VERDE servers. In our case, since we only had one server, it performed both roles. After editing the config file, he bounced the VERDE service to incorporate the changes.

We also learned that losing a master means that new connections will be refused, but existing connections will be kept live since those are running on the satellite servers. When a new master comes back online, the satellite servers will automatically reconnect and populate a new session directory on the master.

After configuring VERDE Clustering, we had to install Apache and PHP to get the web server for the web interface. This, again, is a single command that pulls the bits down from apt and installs them (Red Hat flavors use YUM to do the same thing). Once it was installed, we granted the web user access to control the cluster, at which point we had a web interface and it was time to start installing the OS.

Installing the OS

For VERDE, the OS installation is actually a two step process. In step one, you create a user that will "own" an image, then run a simple command to build the VM's framework (memory, disk size, product key, etc...). Since this is done by command line without any GUI to actually drive an installation, VERDE then waits for you to log on via the VERDE Client, at which point it fires up the VM and takes you through the installation (step 2).

Step 2 is our first experience with the VERDE protocol, and on a LAN it's not too bad. You'll see later in the user experience testing how it actually looks and feels. The benefit to the VERDE protocol is that it runs out of band with relation to the virtual machine, so you can watch the VM boot. Without the VERDE protocol, you wouldn't be able to even install the OS.

When logging into the VM via the client, you'll use the same logon information as the user who owns the image. For the OS, we chose to install Windows XP, but Virtual Bridges does support Windows 7. The installation is simple, but there is one added step that we don't normally take with other solutions, and that is to select a different HAL.  To do this, you have to press F5 when you're prompted to press F6 for storage drivers (yep, you read that right. It's in VERDE's documentation), and select the option with "Standard PC" in it. For some reason, KVM and XP (and only XP - Win 7 is ok) don't get along with the default HAL that's installed with XP.  After that, the rest of the setup is a breeze, and the VERDE agent is installed, hands-off, as part of the setup process.

It's here we that we learn a little bit about how connections are handled by VERDE. Out of the box, users don't connect directly to the virtual machine. Instead, they connect to the host, which allows you to watch VMs boot via the VERDE protocol (which is based on the RFB protocol--Remote Frame Buffer). It also means that the graphics remoting is being handled by the host OS and not from inside the virtual machine. This, of course, is only when you're using the VERDE protocol, because using RDP would require the machine to be booted up and accepting RDP connections.

All that was left for our master image was to install our default apps, and once we were done with that we were ready to provision the desktops. This is also a two step process, with the first step what Virtual Bridges calls "publishing," and the second step called "deploying." 

Publishing a desktop is a single command that essentially tells VERDE that this VM is ready to deploy. Deploying is something that can be done one of two ways. The first is another single command that assigns the VM to users. The second, and the way we chose, is to create a "provisioning rule," which is actually a one-line file with five columns. The file tells VERDE to evaluate which virtual machine a users gets based on their logon ID and group memberships. Obviously, this is the way to go in most environments.

Users personal changes are actually stored in delta files using copy-on-write technology in much the same way as VMware's linked clones. When a user logs on for the first time, they access the gold master image, and any changes that they make are saved to a delta file in their own personal folder structure on the storage system (in our case, the local host machine). Updating the master image, which we'll look at later, is a matter of checking out the master, making changes, and checking it back in, leaving the users' personal changes intact.

After we provisioned a desktop, Leo talked a bit about how VERDE networking works. To save a few keystrokes, here's the explanation from the review that Gabe wrote:

It turns out the default networking model--called Basic--actually doesn't allow for [joining individual machines] 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.

Updating the master disk image

After we did our protocol testing (which is the next section), we took a look at updating a master image. The Installation and Provisioning video does a great job of showing how this works, so you should definitely check it out (it starts at 34:29). We showed two separate sessions logged in with per-user customizations.

Then, Leo logged on as the user that "owns" the gold master image (the same one that we referenced during the VM installation section). When you log on as that user, you're told that you're accessing a master image, and that a replica will be created so that changes can be made without affecting other users that share the master image. Creating a replica essentially "checks out" the master image.

Once the replica was copied and fired up, we installed Skype and shut the machine down. Shutting the machine down "checks in" the master image along with the changes and notifies any logged in users that updates are available and that they should reboot as soon as they can. Simple as that. It is possible to turn off the automatic "check in" for updates that require reboots or extended testing.

After we restarted the logged on sessions, we could see that all of our personal settings are retained and that Skype was installed.

The user experience

Once again we'll turn to the videos to illustrate the user experience. In our test environment, the VERDE Protocol did all right on the LAN, but the WAN left some to be desired. Leo did demonstrate off camera his connection to Virtual Bridges' servers, and his experience was above average, for sure, but we decided to leave it out so as not to confuse it with the standard tests that we performed on each product.

In the end it will be a moot point, since VERDE will be able to broker RDP in the next version, so that experience will be very predictable.

Bonus Footage

When we were through with our testing, we were talking to Leo about how fast the install went, and we asked what his record is. He said he'd done it in an hour before, XP install included. We then challenged him, with the XP VM already created and only needing to be copied to a new machine, to bring a server from bare metal to accessing desktops in less than 35 minutes.

He did it in 33.

So, if we had an award for "Fastest time from bare metal to accessing desktops," it would go to Leo Reiter and Virtual Bridges. And the award would be like a gold statue of a garden gnome or a troll on fire or something. We don't have an award like that, though, so all we can do is show you this cool time lapse video of the 33 minute install shrunk down to about 100 seconds:

The Bottom Line

From Gabe:

For me, VERDE was sort of a known entity, having written the review of the product a shot time before. The simplicity of the solution is pretty amazing, and while that means there are shortcomings (no TS brokering or app streaming, for instance), it's an amazingly functional product considering the relatively small amount of work that goes into setting it up. From installation and configuration to provisioning and updating, everything is just simple.

Unfortunately, the lack of RDP support really hurts. The VERDE protocol was cool in that it runs out of band with relation to the virtual machine, so you can actually watch it boot up, but other than that, it's just not good enough to work over the WAN in a way that people used to using RDP and ICA/HDX are used to seeing. Add PCoIP (and RemoteFX, too) to the mix, and VERDE Protocol is way behind the curve.  That said, I'm anxious to see the next version of VERDE (version 4), which will broker RDP as well as VERDE Protocol.

Also coming in the next version of VERDE is a web interface that adds a more familiar GUI interface to the configuration and setup of virtual machines, which I think all of us Windows guys can appreciate.

Leo also showed us their VERDE Leaf client hypervisor product, which essentially turns an endpoint into a single-VM VERDE server. It's interesting to see a company building these things in a way that's sort of off to the side of the rest of the industry, and to see what looks the be the framework of a capable solution is encouraging. If we do a Geek Week: Client Hypervisors, we'll be sure to include VERDE Leaf.

From Brian:

Virtual Bridges is the product that surprised me most this week. Part of it was probably because I had low expectations from a smaller VDI player, and part was because I'm definitely a bit biased against Linux solutions in our world of Windows. But I was impressed right out of the gate with VERDE. I liked that you could add the VERDE server to AD and it would authenticate live (as opposed to replicating the credentials). I liked the simplicity in booting a bunch of copies of the same VM. I liked that guests connect through the hypervisor and can remote to VMs that have no IP address or that are rebooting. I liked that they have a solution for branch offices and clients... So there's a lot to like.

I was also really surprised to learn that VERDE had a client hypervisor (which I also like that it's based on Linux), and that they built their own remoting product (which is a lot like PC-over-IP or RemoteFX in that it does everything on the host.

The only real downside is that VERDE is going to be a real hard sell for people without Linux Experience. Sure, Virtual Bridges publishes instruction manuals and stuff, but when it comes down to troubleshooting, it's tough if you're on a platform you don't deeply understand. 

Tomorrow:

Tomorrow's vendor for Geek Week: VDI is Microsoft, so come back for our analysis, wrap-up, and lots of videos.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Going nowhere in a crowded market, mindshare will not be theirs for the masses.


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close