By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In our one-on-one interview at the summit, Stevens told us: "We're taking an architectural approach, a ubiquitous approach to operational costs, trying to reduce the times you have to touch a product to get it to do what you want, be it HA [high availability] or resource management or software deployment.…Virtualization and virtual appliances provide ways to reduce how many times [IT managers] have to touch the software and hardware."
SearchEnterpriseLinux.com: Why is Red Hat's first virtual appliance for managing Intel vPro-based desktops, as announced here?
Brian Stevens: Our first phase of virtual appliance work is centered around delivering management applications. That's where a lot of costs can be cut for IT organizations. Working with Intel, we want to build into their chip set the underpinnings you need to manage a secure platform via virtualization -- to be able, for example, to have Windows as your primary operating system for an end user but to be able to run Linux OS in the background as your management gateway.
We're providing the virtual operating system so traditional vendors can build their management capabilities on it and deliver it preconfigured. Right now everything is done by arduous packaging styles.
SearchEnterpriseLinux.com: VMware has been working with ISVs to produce virtual appliances. How is the Red Hat-Intel approach different?
Stevens: We work with VMware on a weekly basis on interoperability and performance. We've also made an appliance available through VMware. But our approach is a bit different.
With Intel, we'll build a full open source platform for virtual appliances, and we'll build it around a modern hypervisor that allows multiple appliances to run on the same platform. This will enable people to [use appliances] to manage an IT desktop because if you're going to manage a desktop, you'll need to do more than one thing with your appliance. You'll need it for provisioning, asset management, lights-out control and so on.
SearchEnterpriseLinux.com: How will this appliance model play in a heterogeneous operating systemenvironment?
Stevens: IT managers tell us their biggest problems around the desktop are security, management costs and the need for desk-side visits. We'll create a simple architecture to deliver a broad-based management platform that doesn't have to be Windows or Linux, but allows for choice within a consistent architecture.
SearchEnterpriseLinux.com: Speaking of Windows-Linux environments, our readers have shown great interest in running Windows as a guest OS on Linux, as opposed to the Microsoft-Novell SUSE scheme of doing just the opposite. Have your customers expressed an interest in this?
Stevens: We've actually been surprised by the interest, but we've moved quickly, investing in writing optimized Windows drivers on RHEL5. We didn't expect to see the amount of Windows users interested in doing that [running Windows as a guest OS on Linux], but it comes down to the desire for a common platform for management. They want to get away from agent-based management and get a common management platform, and that will help them drive utilization up. That's why they're hosting Windows on top.
The issue is performance. You'll see about a 2X performance drop running Windows as an OS on top without optimized drivers. We expect the optimized drivers to cut this loss.
SearchEnterpriseLinux.com: Drivers seem to pose constant problems for Linux users. Do you see any relief coming from open sourcing device drivers?
Stevens: The vendors' IP is in their hardware, and drivers are a good way to mask their IP investment. It's the same as many companies that won't publish the specifications for their hardware. So, when the open source community comes along and talks about open drivers, in many cases it's done without the specifications of the hardware. Then, it's often the case that a lot of IP for the hardware driver gets moved into the software as well, so it's a legitimate claim for driver vendors to feel like keeping those drivers proprietary. So, you have the situation where even the hardware and driver vendors who are participating in the open source community are not giving their specifications, which means the open source drivers are sort of a 90% solution.
SearchEnterpriseLinux.com: So how much will the emergence and adoption of virtual desktop infrastructure (VDI) and other virtual desktop models solve some of these driver problems?
Stevens: Many of the physical drivers will start to move into a common driver domain, and then what we could do, say, in the case of Windows, is turn their drivers into VM logical drivers -- the front-end drivers, if you will. That's probably what will happen in the first version, but there's a lot more work that needs to be done on the hardware side.
SearchEnterpriseLinux.com: We've also seen a lot of interest in centralizing desktop environments to alleviate the management burden they present. Have you? Why not take that approach, as opposed to the approach taken in Red Hat Global Desktop?
Stevens: We've seen the need, and we've seen them try many things to solve the problem, such as thin clients and thick clients and past versions of virtualization. We've been cycling through these things for the last 25 years.
We've put out a roadmap. We're not saying that this [Global Desktop] is the way it will always be. We're just saying that next year we can make a meaningful impact into operational costs with it. This is just a good first step.
SearchEnterpriseLinux.com: There are so many models now for centralizing desktop management, from Terminal Server and Citrix to virtual desktop infrastructure (VDI). Is this amount of choice good or a source of confusion for IT managers?
Stevens: It's all good, as long as they present meaningful ways to drive down costs and increase manageability. There's not going to be, and there shouldn't be, standardization on one architectural model for clients. Users' needs are always different, whether in security, mobility, desktop versus shared desktop. You can't assume that you can virtualize every desktop from the server room, for instance, because it could hamper a user's mobility.