Every day in my (mostly) new job, I see more ways and needs for virtualization. Working within an airport environment, I deal with hundreds of displays for flight information, gates, advertising and so on. All of these do make and have made excellent virtual desktop candidates.
As I learn more about the aviation environment, I'm beginning to see even more areas where we can test and use virtualization. There does tend to be one barrier that we encounter more often than not: vendors who either don't understand or who don't want to understand and move to a virtual world. Many of these possible virtual candidates range from baggage handling to ticketing to central energy plant machines. However, when you mention virtual to many of these system designers they either say, "What's that?", tell you, "We think it can be but we don't really know", or just flat out say, "No, we don't do virtual." Frustrating to say the least.
So, what am I doing about it? Well, for starters, my basic philosophy has always been, nothing is off the table until it can be proven that it won't work. Simple. Let's try it out, either with the vendor or in spite of the vendor (take care here--you don't want to upset the vendor). So, for the vendors who say they don't do virtual, we set up a test environment and test within the IT group first. Next, we do a limited end user roll out--for an extended period. This can be 3-4 months or more. Finally, we'll get the vendor involved and ask them to come in and see what we've done, and hopefully get their blessing. If we get the blessing, we'll do a full roll out. If we don't, we'll discuss with other management and talk to the vendors more to judge what type of support we can expect if we should continue to roll out the virtualization anyway.
Some may say that 3-4 months isn't that much of an extended period to test. Others may say that it's too long. We don't have a set amount of time for these end user tests. We let the results guide us. If something works, we stick with it and ask the user to push it more, preferably until it breaks.And, we do this more than once to make sure it wasn't an accident or something else that broke it. By doing this, we get a better understanding of what we truly can and cannot do.
If something doesn't work, we step back and try to determine what the cause may be and how to fix it. Sometimes this means stripping out pieces of the OS that aren't needed to make a leaner running machine. Other times it means adjusting the resources available to the machine, such as CPU and memory. Then there are the actual applications running on the machine. How are they being used? Is this the standard way to use it? Can we modify the user behavior slightly to help make it work without the user being inconvenienced? As I said earlier, nothing is off the table until we have shown it can't and won't work.
As I write this today, we are currently testing the limits of our VMWare infrastructure with a couple of our systems. We're testing a video solution that is currently setup to stream 14 live feeds to its video viewer and alarm monitoring software all the while driving two monitors. Another item we're testing is the ability to run a software package provided by our LCD screen manufacturer that will allow us to communicate with these screens via the DVI cable and turn the screens off and on (energy savings and screen life extension!). Both of these are things that most people would say that virtualization isn't a good candidate for. But hey, unlessI see it not work for my self, it can be done.
No comments:
Post a Comment