VMware, XenSource Join Forces For Linux 63
porjo writes "Peace has been established on at least one front: XenSource and VMware are working together to improve virtualization in the Linux kernel. Their original disagreement has been displaced by a commitment to work on a solution together, says Simon Crosby, CTO of XenSource, the company that builds products around Xen virtualization software. The two are trying to come up with a common approach to virtualization support in the Linux kernel. [snip] The work now under way would let hypervisors from Microsoft, VMware, and Xen work together in the same data center. Under such a scenario, it would be possible for a Xen virtual machine, trapped on a piece of failing hardware, to be automatically moved over to a VMware hypervisor on another piece of hardware."
Will it be so universal? (Score:3, Interesting)
A good move for virtualization as a whole (Score:2, Interesting)
VirtualCenter is imho way ahead of anything else available - and will be VMware's most important product going forward.
More importantly... (Score:2, Interesting)
Nobody is really going to use this. When people talk about this, it's like saying, "if it's the 3rd Tuesday of a month that ends in 'ber', I'm in an important meeting, sitting in my assigned seat, and I spill coffee on my shirt but not my tie, I can totally switch my shirt without taking off my tie with only a small hiccup in the meeting agenda that we can train the attendees to work around as long as they're sitting in their assigned seats! Isn't that great?! Let's set up our systems to support this and assign the seats now! Move all critical meetings to the 3rd Tuesday of the month!" You'll pick your favorite VM engine and hypervisor and run all your VMs in it. You might have individual users like developers running groups of VMs under a different hypervisor, but you'll be hard pressed to find an excuse to transfer a running VM versus rebooting it. And you almost never "pre-detect" failing hardware and transfer a running machine. I'm constantly reminding people that vmotion and transfering running machines has everything to do with scheduled maintenance, and nothing to do with disaster response. You can't currently (and don't want to) transfer a VM off a local disk over the network, to another disk. Transfering depends on a SAN and fast uncongested network. If your disk controller is failing, you're not going to transfer. If your nic is failing you're not going to transfer. If your CPU or RAM starts glitching you'll be very lucky to successfully transfer a blue-screened OS. If your power drops and you're running on battery and want to transfer somewhere else, you need so many prereqs like a bridged network to somewhere where there's still power, and a mechanism to seamlessly switch your users over... Maybe? If you're this size and budget you probably have the same brand of hypervisor as a hot spare in the remote bridged, SAN replicated, alternatively powered site.
The really important news here is that they're not going to be forking the kernel. Xen and VMware were submitting patches that weren't compatible. If Morton and Torvalds went with Xen's patches, then they wouldn't consider similar but different VMware patches. It'd be redundant. So VMware would need a forked kernel to put their patches in.
Microsoft will never jump in and run a hypervisor on Linux, and if they wanted to they had wanted to last week, they'd need to submit patches to Linux to compete effectively. Extremely unlikely. With this news, MS could write a VM engine or hypervisor to run under Linux. The earlier announced partnership between MS and Xen is simply getting Xen to help make sure Linux VMs work in MS Virtual Server. (In other words, the patches Xen is submitting to the Linux kernel will help make sure that Microsoft can get a few snippits of info from a Linux VM running under MS Virtual Server. It's not really important.) I *WISH* MS would tweak Windows to run more smoothly on hypervisors. But I predict that they'll only be tweaking it to run better under Virtual Server.