Slashdot Mirror
VMware, XenSource Join Forces For Linux
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."
It is great to see that big software manufacturers can help each other and build up a better product. Though, with all my reservations, I might not know enough about this debate to say this. I will do that anyway and you can read it the way you want. Consider the fact that every company making a major product would start helping each other. As far as this drive the development further it's great! This might though carry the risks for having an oligopoly driving the prices forward which is not so great. Also consider the fact that the companies that have the most use for virtualization probably have such a great win in testing that they could pay high prices for a product worth less. All this brings virtualization away from people who just need it for private use. I should also tell you that I don't even know in what extent these products do cost anything.
+1 Agree -1 Disagree
Maybe some day we'll only power down our computers after uploading them-still running-to an off site server to continue their existence. An then some day those never ending processes can mate and have children.
Suck a lemon?
Now this is great news! As VMware user on production systems, I am very pleased with such news. Now one of many thing that can go wrong in such "alliance" as that hypervisor interface will get bloated with vendor specific extensions. And we will end up with non-compatible interfaces as it was before.
At this level, it is because Microsoft VirtualPC doesn't support a Linux host, Xen requires modifications that (apparently) they can't legally use with a Windows client, UML is User Mode Linux (not Windows) and requires kernel-level modifications (obviously unavailable outside of Redmond, WA, USA), and Win4Lin has no free offering. (These are the only ones I'm familiar with) With Hypervisor, however, Xen no longer requires the legally-questionable mods, so there's hope for the future if you don't like VMWare. So, the answers seem to be: lack of support, lack of free, and lack of source.
Otherwise, there're technologies like Bochs, which emulate the actual chip, but are much slower.
--
Given enough personal experience, all stereotypes are shallow.
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.
This is just like that episode of Star Trek where Professor Moriarty succeeds in escaping from the holodeck!
Virtual PC can run Linux distros, you just have to try it. I've had Gentoo run and livecd's based on FreeBSD (PC-BSD and DesktopBSD) and OpenBSD (OliveBSD).
And there's also Qemu which is available for *nix and Windows. Together with the kqemu accelerator it runs Windows very fast on *nix and vice-versa.
(currently running Windows in Qemu on FreeBSD 6, Ubuntu 6.06 desktop in VMware server on Windows XP and Windows in VMware server on Ubuntu 6.06 desktop)
home
Screenshot of XP running on Xen.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
It's only a matter of time before the hypervisor/virtualization layer is a commodity - and with standardized interfaces, the vendors can focus on infrastructure management software.
VirtualCenter is imho way ahead of anything else available - and will be VMware's most important product going forward.
I understand Xen 3.0.2 can run unmodified windows guests if you have a processor with virtualization extensions (Intel Pentium D 9xx series, or AMD Athlon 64 X2 Windsor series). I am planning to try this out but I need a few months to shell out the $400+ to buy new cpu, mobo, video and DDR2 memory.
HTML is obsolete. It's time for a new, simpler and richer markup language.
I'd be interested in hearing about how well things work using Qemu with FreeBSD as a host OS.
But would be even more interesting is hearing about anyone's experience using the various Qemu compatible OS Types listed on the Qemu support page link, including, but not limited to:
ann kournikova upskirt
buy phentermine
fishing rod saltwater
teen titan porn
tranny shemale
Maybe the folks at Qemu should check out that redirect?
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.
"Can someone explain to ignorant old me what linux-on-linux virtualisation is for? What problem does it solve?"
It's for running linux on linux, it solves linux not running on linux.
Hape that helps.
I have bought a $6k box for work to run xen. The results were incredibly disappointing. The para-virtualization is lightning quick, but the HVM is crap.
GFX: The Graphics emulation is incredibly slow (on par with Qemu some of the time, other times slower). VNC display driver has serious mouse issues (this could be solved by using a touch screen emulation, but I don't believe there is one yet.
Sound: Not tested. it's a server after all.
Network: Only emulates PCnet32 and NE2000PCI NIC's, for some reason rightly or wrongly it enforces 10Mbps data rates, same as real cards. Not very useful for virtualizing a Windows server. This is pretty much the biggest killer.
HDD: Performance sucks. this isn't so much of an issue as you can just install an iSCSI initiator in the HVM and connect it directly to your SAN.
So while I *really* want to use Xen, it looks like I'm going to have to go back to the current way we're doing things (VMWare on Linux).
Oh, and I can't run VMWare on Xen outside an HVM, or inside one because of the above performance issues.
What could be better than a jet powered motorcycle? http://www.youtube.com/watch?v=u8l6GTHLSWE
You may want to run bind and apache on the same machine, but not have to worry about the security issues of one affecting the other, so you run two virtual machines, each with a seperate server (I know about chroots, but a vm is more secure).
s/web server/other service/g
But would be even more interesting is hearing about anyone's experience using the various Qemu compatible OS Types listed on the Qemu support page link [claunia.com], including, but not limited to:
ann kournikova upskirt
buy phentermine
fishing rod saltwater
teen titan porn
tranny shemale
I admire their dedication to maintaining cross platform code, but this is ridiculous.
Hand on... Teen Titan Porn? Okay, stop the internet, I want to get off.
OpenVZ is an OS-level virtualisation -- this is quite different technology from that of Xen and VMware. OpenVZ provides separate isolated containers within a *single* kernel image, while Xen makes possible to run *different* kernels on the same piece of hardware. More info about those differences is here; the only thing I want to add is VMware is moving into Xen direction.
-- Kir Kolyshkin, OpenVZ project leader.