One of my co-workers, Chris Reed (www.creedtek.com), uses the analogy that the most expensive pet you can get is a free dog. The initial cost is great. How can you get cheaper than $0? However, this transaction is followed by the vet bills, the inevitable property damage and the chewed up slippers. Free dogs rarely have their shots, which puppies need several rounds of. They usually need to be “fixed”, and I like to add in a location chip. Soon, you have shelled out a significant amount of cash on a free pet.

Many people will adopt a similar approach to virtualization, selecting a free product with the assumption that it will save them money. Can that work? Yes. Are there hidden costs to be aware of, and even expect in the near future? Definitely. Can those costs be significant? Yes, and they can be quite significant.

If you are comparing free hypervisors, then it comes down to features. Microsoft includes more features in their free version than VMware, but their features are less robust than the same features from VMware. And as you move into the higher licensing levels to migrate into an enterprise solutions, VMware’s features are significantly more robust. That could mean starting on one hypervisor at the free level, then having to change hypervisors as your environment matures. That can be a VERY painful process.

I wrote more on this topic in my last article “Free virtualization: It’s free for a reason“. I would also recommend going to www.virtualizationmatrix.com for a great break down of features between Citrix, Microsoft and VMware at various versions of their products. Andreas Groth has done a significant amount of research to build that matrix.

In July of 1969, the US was in a race for the moon. Astronauts Michael Collins, Buzz Aldrin and Neil Armstrong were entrusted with the Apollo 11 mission, taking the first shot at the momentous achievement. Last night, I caught a great documentary on this mission, waking through the many planning details and challenges involved in going where no man had gone before. In fact, knowing the technology of the time, I am still amazed that we were able to pull this off on the first attempt. These men were truly brave, trusting their lives to such new and really untested technologies.

<IMAGE MISSING>

One thing that caught my attention was how meticulous Mission Control was, as they faced a number of “go/no go” decisions from the launchpad to the moon and back. As Buzz Aldrin and Neil Armstrong undocked the lunar module and began their decent to the moon’s surface, they were faced with almost impossible odds. There were so many calculations that had to be made in a split second, with no prior experiences to draw from. Gene Kranz, NASA’s Flight Director at Mission Control, was faced with a number of tough decisions as the lunar module approached the surface of the moon.

They did not know exactly when they would touch down, or how much fuel they would burn in the process, but they did have a good idea of how much they would need to relaunch and connect back up with the command module for the return trip to Earth. With every second, fuel consumption was being calculated and measured to insure this was not a one-way trip. About 30 seconds after beginning their final approach, Neil Armstrong calls out “1201 program alarm”. This was a computer error code that simply meant there that the computer was unable to complete all of the calculations it was attempting and had to move on. Timing was critical, and the programmers of the flight computers knew that should this condition occur, it was more important to simply note that some data was lost and move on. I can imagine the concern this caused, both in Mission Control and cramped lunar module. This is where the many eyes and ears monitoring the situation at Mission Control had to step up and insure that the important information was not dropped.

As I watched this, I noticed much this is similar to how PCoIP handles data (you knew this had to have a virtualization tie in, right?). PCoIP uses UDP. UDP is stateless, it will drop data packets. At the most basic level of the solution, the networking layer, packets can be lost the data does not stop flowing. UDP is like the flight computers on-board the Apollo 11 lunar module. At the application layer, PCoIP becomes Gene Kranz and Mission Control. It is looking to determine what may have been lost and how that can impact the overall mission. Calculating the 100 feet in front of the lunar module was infinitely more important than continuing calculations for the 100 feet behind it. With PCoIP, the goal is an efficient and pleasant user experience. To achieve that, with a myriad of unknown factors that can come into play, UDP is recognizing that not all data is critical to the end goal. Instead, PCoIP is the watchful eye that makes the “go/no go” decisions. For USB communications, data input and other critical data, it will request a retransmit of the data to insure accuracy reliable delivery of information. For audio or video packets, where it would inflict more harm to pause communications and attempt retransmits of the lost packets, it simply makes the decision to move on.

Protocols build on top of TCP, like RDP or ICA/HDX, cannot provide this intelligent decision-making. TCP guarantees delivery of packets from the network layer, so the application has no option but to pause while waiting for the delivery of data. Sometimes, you really need to allow the software protocol to apply some intelligence to that decision.

As the Apollo 11 lunar module was rapidly approaching the surface of the moon, with nearly zero tolerance for errors, NASA knew that some data loss was acceptable. In fact, it was preferable to the penalty that could have been incurred by stopping the pending functions to complete previous ones. Had the Apollo 11 flight computers actually stopped measuring fuel consumption and distance to the moon for a few seconds to finish whatever computation triggered that 1201 program alarm, the event of July 20, 1969, may have ended very differently.