Weblog of Mark Vaughn, and IT professional and vExpert specializing in Enterprise Architecture, virtualization, web architecture and general technology evangelism
I regularly work with organizations that are wary of mixing public and private workloads in a common virtualization environment. Whether it is mixing public and private workloads, mixing multiple organizations on a common virtual infrastructure or simply mixing workloads from various internal networks, there is still a lot of concern around the security aspects of this discussion. Many people still look at one physical server, and get uneasy about different workloads sharing that server. Logically, many people relate it to sharing an operating system and that is the root of many concerns. This is an easy misconception, since traditional deployments have long been just that, one operating system for each physical server. If not properly explained, virtualization remains a black box to many people and old perceptions remain in place.
This is where we, as consultants and virtualization architects, need to do a better job of explaining new technologies. In this, case, it is not even a new technology, just a real lack of education in the marketplace. In 2001, the National Security Agency (NSA) worked with VMware on a project called NetTop to develop a platform for mixing secure and non-secure workloads on a common device. Previously the NSA maintained an “Air Gap” policy of not letting servers with mixed security needs touch each other. With the NetTop project, the NSA leveraged virtualization to bring these workloads onto a common server or workstation. This was not 2 years ago, but 10 years ago. And the security measures deployed in NetTop have only been improved on since then.
In fact, in 2007, the NSA came back to VMware to develop their High Assurance Platform (HAP). I won’t pretend to know your security needs, but I know virtualization has long been used for mixing highly sensitive data by people who live and die by data security.
In my MBA studies, many classes touched on Herb Kelleher and Southwest Airlines. Mr. Kelleher was an excellent example of how leadership should be done, and he led Southwest to growth in a very difficult market. As I revisit my previous studies, I now see technology lessons that parallel the business lessons.
<IMAGE MISSING>
Southwest simplified operational costs by selecting a single model of airplane and focusing on high-density routes. They also rode out some short term spikes in oil prices by leveraging advanced purhcases of airline fuel.
Had to throw out a quick comment on the new iPad vCenter Client from VMware.
For over a year now, VMware has offered the vCenter Mobile Access (vCMA) appliance. I have used it internally, but it has never caught on as well as I had thought. One drawback was the lack of SSL support, and that was fixed last week. Here are some quick screenshots of vCMA in action (these were on an iPad, it is really made to be viewed on a smaller PDA or phone screen, so some screens have excess whitespace):
<IMAGES MISSING>
vCMA was a great tool, but it just got better. VMware has developed a new iPad vCenter Client that leverages the vCMA to provide an even better user interface. Like the vCMA, the iPad vCenter Client can only do about 50% of the standard functions available in the Windows vCenter Client, but they are now committed to growing this application and adding more functionality. From some of the pre-launch discussions I was able to be in, VMware is very excited about this tool and anxious to begin expanding it’s functionality. The iPad client connects through the vCMA, and I am not sure I will be exposing it to the internet any time soon. I only operate a lab, and the vCMA now has SSL support, but I have VPN access and will likely use that to allow vCMA to stay behind the firewall…for now. Here are some shots of the iPad client, and you can see how much it improves on the previous vCMA interface:
<IMAGES MISSING>
As you can see in the images above (click on any to enlarge them), you can view the stats for ESXi hosts and for the VMs from the main screen. There is a small stats icon in the upper right corner of each VM’s image that will change its image form a banner representing the OS to a stats chart. Once you drill down to a VM, you can perform start/stop/suspend/restart functions, as well as restore snapshots. You can also view recent events, monitor stats and perform tests (ping and traceroute). Not bad for a convenient app you take with you on an iPad.
Eric Siebert (virtualization guru and fellow vExpert) also wrote a great post on this at vSphere-Land. Be sure to follow the “full article” and “part 2” links at the bottom of the article to get more information and installation instructions.
As great as this client is, do not feel left out if you do not have an iPad (or if you use one of those inferior tablets…Aaron ;-), you can still use the vCMA from almost any mobile browser on a cell phone or tablet. Though the interface is not as refined, it will provide the same basic functionality.
Virtualization management tools are popping up everywhere, and some are much better than others. In fact, few really shine at this point.Part of the problem is that these tools are attempting to tame a wild animal. Virtualization technologies are expanding and growing at a blinding pace, and no one can truly keep up with the current pace of change…let alone manage it.
Vendors like VKernel, Veeam and Quest are doing a good job, but don’t hold your breathe looking for one tool to rule them all. There will always be advanced features within a hypevisor that management tools have not caught up to. You will either have to limit yourself to the tools supported by your management platform (better pick a robust platform or you will be crippling your hypervisor and destroying your ROI), or you will have to accept that you will still use the native hypervisor management tools to manage advanced features (limiting the ROI on the new management tool).
This trade off is frustrating, but one that will not go away until the pace of change within virtualization technologies slows down considerably. In other words, this will not change any time soon.
Though I generally recommend against it, I admit there may be reasonable cases for mixing hypervisors within an environment. As you evaluate decisions like that, be sure to consider the impact on ROI. OpEx can go through the roof in those scenarios and easily wipe out the CapEx savings used to justify the decision. If you are then looking to a management tool to bring the two hypervisors together in a single pane of glass, do not set your expectations too high on the capabilities of any tool to provide a high value in that scenario. The few tools that could make any real impact there may be cost prohibitive. Before you know it, you have pushed both the CapEx and OpEx through the roof trying to manage a mixed environment.
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.
