By VSM News Staff published: Wednesday, December 01 2004
VSM talks with David Crosbie, founder and CEO of Leostream.
Leostream is developing the next generation virtual data center management products, enabling companies to create a single pool of available storage and computing resources that they can deploy on demand. The Leostream VMC manages server virtualization products from both VMware and Microsoft, and integrates them with SANs from EMC, HP, and IBM. Founded in 2001 by a group of experienced industry executives and engineers, Leostream is based in Waltham, Massachusetts, USA.
VSM: Good morning David. Can you start by telling us about Leostream’s evolution and current focus?
DC: Over the last three years we’ve been driven by customer demand from a very narrow niche, which was the Test and Development market to all phases of a server life cycle – from Test and Development all the way through to Production. We see ourselves as the agnostic virtualization management layer for both VMware and Microsoft.
We have a good relationship with both VMware and Microsoft. We are a VMware Technology Partner. We are also a certified Microsoft Partner. I’ve just returned from speaking at Microsoft’s IT Forum on how we automate Virtual Server 2005, and we’re working on a number of joint opportunities. Obviously today the majority of our customers are all VMware, but we are broadening our focus to include those opportunities where people are either all Microsoft, or they’re using both VMware and Microsoft in the environment.
VMware, with their ESX product, is very strong in the production space. In practice virtualization is all about consolidating Windows machines. There are significantly more Test and Dev servers in large companies than production servers – between two and five times as many. It costs just as much to care for and feed a Test and Dev server as a Production server. So Microsoft’s focus on the Test and Dev world, whether intended or not, makes sense and will give them significant traction in that part of the market where performance is not the most critical aspect of the whole solution – and technical support is most required.
From the point of view of the technology itself, we’ve found ourselves with two strong niches:
One is automating the whole early stage. How do you convert the physical machine to the virtual machine, how do you do the testing and staging when you have to have multiple machines set up in the lab? How do you reduce the labor, the costs around managing lots of virtual machines when you have, for example, five virtual machines or five Test and Dev servers for every production server? You suddenly end up with hundreds and hundreds of virtual machines that are needed just to test an application. So that’s one area where we see ourselves as being pretty strong.
The other area where we see particular strength is we’ve done a significant amount of work on SAN integration between VMware ESX and SANs. So we can do the whole SAN clustering and failover. What’s the difference between SAN clustering failover and VMotion? VMware’s VMotion is where you have a running virtual machine, one host, and you can get it to move as if by magic from one machine to the other machine. The end customer, the person using that virtual machine, has very little insight that this virtual machine has actually moved its residence.
That’s great when you want to update the underlying host OS. However, if somebody pulls the plug out of the back of the server, it doesn’t help you very much. A machine goes down, and so do your virtual machines, and you have to cold reboot them.
Failover is basically where you have a series of servers all linked together into the same SAN storage, so that if one physical machine goes down then they restart on other physical machines. We started building that technology about 18 months ago, and we had a series of early customers.
But we’ve really seen that coming into the fore in the last couple of months, as people have started to move out of early stage development with ESX, where they have small deployment and they’re moving to larger scale. They feel that the risk of putting too many virtual eggs in one physical basket forces them to have some form of redundancy.
VSM: Is that a separate product, or is that a feature to one of your products?
DC: We try very hard to have a single product. We have the Leostream Management Controller, which manages virtual machines running on different physical hosts. It’s a virtual machine, you download it, you register it either under VMware or Microsoft, and you start it. That is the sum total of what it takes to set up. You interface to it via a Web browser, just a plain Web browser, so you can do it from your PDA, you can do it from your Solaris, you can do it from your home. It’s very easy to work with.
Then on the host side we have a series of agents - one for Windows, one for ESX - that you install. The general idea is that you can have our software up and running in a couple of hours of getting a trial version from us. People send in requests for trials and within a couple of hours they get back a trial license, and they’re up and running.
That’s the main component. The second part, which is slightly separate but still fairly integrated, is the whole physical to virtual conversion, the virtual to virtual conversion. Again, a different focus on these conversions is really in the Test, Dev and Staging areas, where you want lots of different developers to do these conversions. You don’t want one person to do them, you want to have lots of people. You don’t need to train them. It basically works out of the box.
VSM: Could you further discuss how you’re different from some of the current offerings? There would be some overlap with VMware, in some cases.
DC: Yes. I’ve seen big accounts who’ve decided that they are an all-VMware shop, and they’re going to do everything with VMware, from a single source. That is not our market. Our market is really people who are looking at Microsoft, or both Microsoft and VMware deployments in the same location for management, for control. Or locations where they want failover today, and they have the choice essentially between ourselves and Veritas Cluster Server.
Why would they choose us over Veritas? Price and integration. And that we’re much more tightly designed for virtual machines. So in terms of our product, in one control unit you have both all the virtual machine management and monitoring and access control, and you have failover. You don’t need to do any integration between the two. From the price point of view, we’re just a lot cheaper, not only to buy but also to operate.
Finally, we’re actually designed to work with virtual machines. So we monitor the host operating system, and when that fails we check every virtual machine, whereas with Veritas it’s checking every virtual machine all the time, as if they were virtual machines. So Leostream Management Controller is much lighter on people’s networks. We handle multiple SANs, whereas Veritas will only handle a single SAN. We, uniquely, can failover between a main and a Disaster Recovery site. Those are the things customers are telling us, why they’re choosing us over Veritas. But again, the goal is not to compete head on, the goal is to reach those people who want this combined virtual machine and SAN management.
On the physical to virtual and virtual to virtual front, why do people buy Leostream? Essentially because it’s easy to use. The market really breaks down into two. First are those people who are converting machines that they absolutely don’t want to touch. They want to take an image off them, and they want to convert them across into the virtual world without changing anything.
Then there’s another group of people who are quite happy to install our little wizard onside the virtual machine. That wizard basically has all the intelligence built into it, so that anyone can use it within a few minutes. It either works or it doesn’t. You just click your way through, and a couple of hours later up pops the virtual machine.
If you absolutely need to be certain that the machine is back to the original state before the install, you just use backup software to restore the machine. What we find is that people get comfortable with it, find it very easy to use, find it very benign, and actually run it quite frequently.
We have a company in Boston that runs it every week in conjunction with a third party application to back up a running server. So every week they’re taking snapshots of that running server without ever bringing it down. They get the snapshot into a virtual machine, they can then install a patch on it and test the patch, and if that patch is working fine then they can get back on the physical machine.
So you have this system on the VMware side where it’s really aimed at the big production market, where you need to do training, and you have significant costs involved. You have this other market where people are wanting to do lots and lots of conversions, they don’t want to train people, and they want to be pretty certain that once they start they’re going to get to a successful conclusion. That’s how we divide between the two.
VSM: Will the SAN failover work with GSX and Microsoft also?
DC: The system that we have in production at the moment only works with ESX. We have a beta version that provides Windows based failover for GSX and Virtual Server.
VSM: If somebody were looking into that, would they have to check with you first about SAN compatibility?
DC: No. The way we designed our failover has been to always look through the virtualization layer or look through the host operating system. As long as the host operating system, whether it’s ESX or Windows, can see the SAN partitions, then we can see them, and we can do the whole failover that way. We’ve largely got ourselves out of the business of having to support SAN by SAN.
VSM: In a failover situation do the host and the guest all failover?
DC: No. Here is the goal of failover. You have three or four physical machines all running virtualization software. You have one machine that is more lightly loaded than the others. When one of those machines fails, then the system looks for a suitable machine to move the virtual machines to. Every time you start a virtual machine the controller itself caches the configuration of that virtual machine. When that machine goes down then we find the most suitable machine, we re-map the partitions, and we basically force down the configuration into that machine, and we start the virtual machine up.
VSM: Concerning the Veritas Cluster Software for Linux that supports ESX, comparing it to your solution, will theirs be faster?
DC: The key issue with failover is not speed; it’s reliability. It’s the false positive or false negative issue. The worst thing you could do with a failover is to instigate it when the machine hasn’t really failed.
The other big difference between the Veritas approach and ours is that theirs is basically designed for physical machines where starting them all at once is no big deal – for VMs this is an issue. A starting VM puts 2x the load on the host as a running VM, so starting a dozen VMs at once brings the host to its knees. The load has to be spread over time, which is what we do.
Coming back to this issue of human intervention, the first thing we do is we’re busy pinging away at the console OS to make sure it’s running. People came back to us and said, “That’s fine, but the console OS could stop working but the virtual machines keep running.” So we added a layer where we then check all the virtual machines. If the virtual machines kept running, we wouldn’t do failover.
Then people came back to us and said, “The console OS has gone down, the VMs have gone down, but we still don’t think we should failover yet. We want you to have a manual override.” So we built a nice big red button into the controller. We tell you, in lots of different ways, that your system has failed, but until you press the red button we won’t failover for you.
That’s a good example of an automated process where people don’t want it automated, at least not until they’re comfortable about it. And then from a failover perspective, people tend to set those delays on checking pretty long before they instigate the failover process. Once it starts, you’re basically up and running in the time it takes for a Windows machine to reboot. So you’re down for a couple of minutes.
VSM: What we hear from virtualization users is that failover clustering is one of the hotter topics. But a lot of people are confused, and think that VMotion is failover.
DC: Yes, I had that question today. VMotion requires the origin machine to be running throughout the transfer process.
VSM: We know that Veritas has failover clustering, and it’s pretty expensive, about $2,000 per server. If somebody really wants to explore this then they want to test it, or see it somewhere. That’s not plausible with the model that Veritas has. Veritas has a lab, and if somebody wants to go into the lab they can see NetBackup and some of the flagship products. But if they want to go to a specific area of the country just to see Veritas Cluster, it can’t happen.
If somebody wanted to look at your controller software, besides downloading the software, can somebody initiate this or actually test how it works?
DC: We don’t have a test lab where we can invite people in to see it, not least because we have customers around the world – half are outside the US. The irony of our company is that we have relatively few local customers. So what we’ve ended up doing is downloading it to people, and they just test it out in their own labs.
VSM: But that’s the best thing, that they can do that on their own.
DC: For sure. For example, an insurance company is doing a bake-off between us and Veritas at the moment. Veritas has come in and set it up for them.
VSM: That’s good to know, because if people can’t find Veritas locally to come in and do that they can download your software and test it themselves.
DC: Yes. The key message is that everything we talk about, we have. And everything we talk about you can have set up today. Then you can make your own decisions.
What we find is that in the very early stages of playing with it, you can get used to it, and you can do it yourself. Then when you’re starting to want the SAN and the hardware and the integration, that’s where your VAR or system integrator will come in and scale it up.
But in the early stages, when you’re not sure how much money you want to spend, not sure how big the deployment is, where you just want to take it for a test drive, we give you the “car”. We don’t sit in there and watch for every step you’ll do. We give you the car for a couple of months at a time. And we give you the support you need during the process.
Because we discovered the sales cycle is quite long in these things. We’ve gone back and called on people we were talking to a year and a half ago, and they still haven’t made a decision on the whole process.
VSM: Can you comment on the scope of your customer base?
DC: Way over half our market is overseas. Why? Because they can download and go with the software. You don’t need to do any training, you don’t need any support engineers. So we’ve had very strong pickup from VARs and system integrators and customers in Europe.
Customers range from a British food manufacturer, to a Japanese tire manufacturer, to the water utility in a desert, a series of US states, a US supermarket, Canadian and European electricity generators, even a disproportionately large number of Norwegian customers thanks to our super active Norwegian VAR.
Where are we now? We’ve really been focusing on the departmental level sale. We haven’t tried to aim at selling to the CIO in a classic big-ticket corporate sales model. We see the virtualized market as soon being a mass market. We see that most companies of any reasonable size will have deployments of virtual machines, and they’ll need some level of management. So we priced it aggressively and started to build distribution, which is primarily indirect because that is what you need when you are selling one piece of a system.
The result of that is you end up in departments of big companies. Rather than starting at the top and working into the departments, you start at the departments and get critical mass. With Virtual Server we think that the world will change slightly, and we’ll end up with more large-scale deployments.
That’s where we are at the moment. We’ve gone in the last six months from a whole lot of small-scale deployments to a fairly large number of large deployments, where all our efforts and focus has gone to managing those large accounts.
VSM: What is Leostream’s distribution model?
DC: Like all early technologies, we’ve started off selling directly to customers. Customers come directly to us because they have a problem, and we claim to have a solution. But virtualization is really a solution that consists of a series of components: the hardware, the storage, the virtualization, the access control and the management.
The people who are best suited to helping customers with that are value-added resellers and system integrators. We see our future as working with value-added resellers and system integrators to solve customer problems. We see ourselves having this indirect approach to distribution.
We found that particularly effective in Europe, where the language issues and the support issues have made moving to a VAR model much more relevant than it is in the U.S. And we expect the U.S. to follow in the next year or two. But our long-term goal is an indirect sales model.
VSM: Where do you think the world of virtualization is going? There are lots of things going on with virtualization, relating to utility computing for example. In the coming years, what’s going to change, what’s going to happen with virtualization?
DC: There’s an evolutionary stage we’re going through. Current state is that people are just starting to get their heads around what a virtual machine can and can’t do. And they’re solving very direct problems like we do, which is how do you integrate with Active Directory, how do you integrate with SANs, how do you do backup. You’re basically just trying to stitch it into the fabric of your data center.
The next stage we’re coming to is one where you’re trying to do limited levels of automation. That’s what we’re doing in the Test and Dev world, we’re semi-automating the process of testing and development. Why in that field, not production? Because that’s where people are less sensitive, and more willing to experiment.
This issue is not a technology issue. You ask where it’s going in the future, it’s got nothing to do with technology. It’s all got to do with customer comfort. Just like with a car. You can have a car that drives itself down the road, but nobody would trust it. Same with data center automation – nobody trusts data center automation today. So the place you have to start with data center automation is where you get a lot of value from automation but low risk. That’s why we’re in the test and development world.
What you’ll see over the course of the next five or ten years is that the level of customer comfort will rise, and therefore it will move gently up the value stream of the channel, going from Test and Development to Staging automation to Production automation.
What you’ll see then, even in five years, is still quite rudimentary automation, I believe. For no more reason than that people want to be involved in that loop. They don’t want the data center to think too much for itself – for the same reason people don’t want a fully automated car. And I don’t think five years is enough time to get over that psychological barrier.
I think you’re going to see lots of tools in place to make people more efficient, but you’re still going to see a system administrator taking decisions about what to do when this particular server is overloaded or this mail server has run out of disk space. I think you might see the easier questions like allocating more disk space, but the bigger ones that people talk about in a totally automated world I don’t see happening in a five-year horizon – perhaps ten years.
VSM: You do see in the evolutionary phase we’re in now that it’s logical and reasonable that a company definitely has to be experimenting with these new technologies?
DC: People have to experiment, and people need to learn what can be done, but it’s not technology that’s holding people back. There are plenty of technology companies out there with great plans for automating the whole data center, lots that we see spring up every day. Their problem, and we talk to our customers about this, is they’re just not ready for that because it requires big changes in the way IT is run in companies and the way an IT department operates. You can see this being played out in the current “outsource”, don’t “outsource” – “IT is a cost center”, “IT is a key differentiator” debate.
This is really no different from what has happened on the factory floor – companies have either highly automated the process or decided that it is so labor intensive that it has to go to China.
While this debate is going on we will see automation of particular IT tasks, and even more importantly integration of automation tools with the business automation / ERP systems – so you can use a Web page to order a complete server in an hour and all the approvals and billing get sorted out without paper - but not an all embracing system that works without System Administrators.
VSM: Where is virtualization technology itself going?
DC: I think what you’ll see is that virtualization becomes a fabric of the operating system. I think you’ll see Microsoft bring it into the operating system. I think you’ll see VMware bringing it down the range, from their ESX server they’ll bring this micro-kernel type operating system, lower and lower in the type of machine it runs on – loosening the requirement for SCSI disks, and significantly lowering the entry price point. You’ll see Sun and IBM do the same thing.
It’s going to go back to the days of time-sharing computers, where virtualization was just a natural part of a mainframe. It no longer becomes a differentiator that you put on top, it’s just the operating system. Then all the focus will just start moving up into the management layer, which is where we and a lot of other people are sitting.
VSM: Is Intel trying to do something at the chip level?
DC: Yes. Why is virtualization difficult? It’s only difficult on the Intel CPU. A couple of the Intel instructions broke the traditional model of separating operating system and application instructions and hence created this need for a whole lot of software to work around these instructions. So, for example, the IBM POWER PC is naturally virtualizable. You don’t need to do anything clever with it at all. The same with the Solaris chip. So it’s only a matter of small changes to the Intel chip that would make it very easy to do virtualization.
I think it will take a while for Intel’s Vanderpool technology to make it into the mainstream, and it has some revenue issues for them, because obviously they sell chips. And if that chip does the work of ten different ones, and it does it efficiently, it will reduce the number of chips that are sold.
But they will make those changes. Once they’ve made those changes, a lot of the considerable magic that VMware has in virtualizing the Intel chip will no longer be as crucial, and the focus will be much more on sharing the hardware between VMs. But again I think that there is an opportunity to do this in hardware rather than software – it’s not hard to put ten Ethernet NICs and a switch on a single card, and that avoids the need to share a NIC. This long-term trend is why you’re seeing them move more and more into the management space.
VSM: Why should people look at Leostream as a virtual machine management solution?
DC: The reason you should look first at Leostream is that we leave your virtualization options open, and within a couple of hours of coming to us, you can have our pretty feature rich system deployed and running. You can work out what works, what doesn’t work for you. That way you can find out what you actually need in the way of functionality. Otherwise you end up in a chicken-and-egg situation, where unless you have the product deployed on your system, you’re not really sure what functionality you have.
We have a deployment model and a support model, which means that we can get pretty much everyone who comes to us up and running within a couple of hours of coming to us. Once you have that, once you see what we do, then you can decide whether you want to buy us or not.
