Work Underway To Return Xen Support To Fedora 13 93
Julie188 writes "Details on this are admittedly sketchy, but both Red Hat and Xen.org have gone on record promising that some kind of support for the Xen hypervisor is forthcoming for Fedora users. As we know, on Monday, Fedora 13 was released, chock full of features to appeal to business users. One of the ballyhooed improvements to 13 is virtualization — meaning KVM and only KVM — for Red Hat. Xen was dropped from Fedora a few releases ago and it hasn't come back in 13, except that 13 still supports Xen guests. Meanwhile, 'work is underway in Xen.org to add platform support to Fedora 13 post-release,' promises Xen.org's Ian Pratt."
KVM catches Xen (Score:5, Informative)
As more new servers are deployed for virtualization, Xen superiority over KVM slowly, but surely disappears. First of all, all new tech has virtualization acceleration support in CPUs. Now, for example, using KVM in combination with paravirtualized network and storage drivers (which are packaged and used in Ubuntu as default), Ubuntu Server 10.04 LTS has the same speed and performance as guest as using Xen. Also huge improvements into libvirt stack and virt-manager have played role here - yes, I know, Xen also can use libvirt, but still - as it is more and more easier to deploy virtual machines, be it development or server environment. I have worked with Xen exclusively in the past for some three years, and most problems have been kernel patching issues and in fact, HVM support (because you still have to emulate some devices with quemu, which leaks like crazy, I guess that's reason why KVM now uses paravirtualized devices for net/storage). I don't have time to compile code for production servers, so if KVM is in kernel, and it is supported by kernel team and distribution, I will go for it. I was reserved And I guess lot of newcommers in virtualization will too.
In nutshell, Xen devs shoot in the foot here. Have they agreed to be included in main kernel three and be more welcome with patches, it would be more interesting competition here.
Re:KVM catches Xen (Score:5, Informative)
We finally switched to KVM and suddenly life got a lot easier.
(Going slightly off topic here)For a while we used libvirt and the associated tools, then we discovered Ganeti [google.com], a project at Google which has made cluster management a breeze. Libvirt has a "network" driver, but really isn't designed to manage redundant virtualization clusters. Ganeti, on the other hand, is designed specifically for managing clusters, and takes care of all the dirty work like setting up and managing LVM and DRBD. You can build out a new virtual machine, complete with an operating system in just one command, or even do it over the HTTP API. You can use Ganeti with KVM or Xen, but until/unless Xen is in mainline I won't be touching it.
Re: (Score:2, Informative)
After a little more research I became a little disappointed by the current state of virtualisation tools. They'
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Not every OS shuns Xen as a Dom0 like Linux seems to. I run Open Solaris this is what it took to get running:
pfexec pkg install xvm-gui
pfexec svcadm enable milestone/xvm
pfexec reboot
That's it. I wanted to use Linux. I read every single manual I could. There seemed to be 10 different ways to do the same thing and the documentation was never quite there. I could just never get it working the way I wanted to.
With virsh and virt-manager setting up another OS is cake. I'm running Debian64 as DomU and Windows7 un
Re: (Score:2)
That's it. I wanted to use Linux. I read every single manual I could. There seemed to be 10 different ways to do the same thing and the documentation was never quite there.
Well that's pretty much Linux <anything> in a nutshell. ;)
Re: (Score:1)
KVM is also compatible (Score:5, Interesting)
There is no doubt that KVM is the future. It is built into the kernel -- no dom0 patches required. RedHat is heavily investing in it. Note the sponsored oVirt project that integrates libvirt and FreeIPA to manage a network of virtual machine servers using kerberos and ldap as the security framework.
Re: (Score:2)
Last time I looked, KVM was orders of magnitudes slower than everything else. Has that changed now? I want something that at least beats Xen.
Re: (Score:3, Interesting)
Someday KVM may catch Xen (Score:1, Informative)
I've been using virtualization on non-x86 hardward for over 10 years. The ideas are not new to me.
I've used VMware, Xen, KVM, QEMU, VirtualBox, LMU, Jails, on Linux-based and BSD-based installs.
I started testing KVM in our lab about 6 months ago to be ready for the releases that have all come out recently. I've not been impressed. Performance sucks when compared to Xen and that is putting it nicely. Xen is lighter than VMware and VirtualBox. I don't really care about the controlling tools provided the CLI c
Re: (Score:1)
Is ESX so much faster than VirtualBox ? In my experience VirtualBox beats VMWare in quite a few areas (though, sadly, not in networking). And the most recent version, 3.2, with fully asynchronous I/O widened the gap further.
It's almost to the point that having virtualbox run a VM in a file on ext2 beats VMWare running the same VM with it's "partition filesystem" in normal setups.
Re: (Score:3, Informative)
Is ESX so much faster than VirtualBox?
Yes, it is. At least it was in all of our internal testing, and every published benchmark I've ever seen.
In my experience VirtualBox beats VMWare in quite a few areas (though, sadly, not in networking). And the most recent version, 3.2, with fully asynchronous I/O widened the gap further. It's almost to the point that having virtualbox run a VM in a file on ext2 beats VMWare running the same VM with it's "partition filesystem" in normal setups.
Are you comparing VirtualBox with VMware Server or VMware Desktop? VMware ESX/vShpere are completely different products. VirtualBox may in fact out-run the lower-end, OS-hosted VMware Server and VMware Desktop. But in general, it won't come close to anything from the VMware ESX/vShpere product line (which is a hypervisor that runs on bare metal).
Re: (Score:1)
Actually ESX is a hypervisor that runs on an old redhat distro last time I checked. Given the featureset of the newer VMWare's it would amaze me if half of them (specifically the "new" hardware support) isn't just the result of a linux kernel upgrade.
Have you found a lot of benchmarks online ? I've never seen more than a few, and I would require relatively recent versions of the hypervisor (vSphere 4 vs VirtualBox 3.1 or 3.2 preferably) to be compared to find such benchmarks relevant.
But I'd appreciate a fe
Re:Someday KVM may catch Xen (Score:4, Informative)
Actually ESX is a hypervisor that runs on an old redhat distro last time I checked. Given the featureset of the newer VMWare's it would amaze me if half of them (specifically the "new" hardware support) isn't just the result of a linux kernel upgrade.
No, the VMware ESX hypervisor runs on bare metal. The management console for ESX is based on an old RedHat, but that just talks with the Hypervisor via an API. In fact, the ESXi version doesn't even have the management console, and you use the VMware client to manage the hypervisor.
But I'd appreciate a few links with recent benchmarks if you have them.
I'll see what I can dig up, but comparing VirtualBox to ESX isn't frequently done because they're so different. I recall that I saw benchamrks comparing VirtualBox to VMware desktop, and then benchmarks comparing ESX to VMware Desktop, and did the transitive analysis.
Our internal tests threw out VirtualBox (and VMware Server) as options after very simlpe IOmeter benchmarks. They were both dog-slow compared with ESX.
Re: (Score:1)
Our internal tests threw out VirtualBox (and VMware Server) as options after very simlpe IOmeter benchmarks. They were both dog-slow compared with ESX.
Under which versions was this evaluation made ? Vsphere 3 or 4 ? VirtualBox 2 ? 3 ?
Re: (Score:2)
Re: (Score:2)
ESXi version doesn't even have the management console
At server (or via ILO or DRAC connection) Hit Alt+F1, type unsupported (don't worry if you see nothing on screen just keep typing), login as root user with password and there is your console.
- Eric
Re: (Score:2)
Do you work for VMWARE?
No, I don't. We went down the VMware ESX route several years ago and have been very happy. The product has very few warts and limitations, and is rock-solid stable. Our ESX hosts stay up for months at a time.
Now, VMware's pricing leaves a lot to be desired, but when we looked into the projected operational costs of basing our virtualization project on anything else (Xen, Hyper-V, KVM), the excellent management tools and support from VMware made it the least-cost and least-risk option. We run about 70 VMs on
Re: (Score:1)
You are working for VMWare.
VMWare's support redefines "non-responsive", and their products come out with bugs that makes you wonder if they've ever run them even once themselves [zdnet.com]. Their pricing is so ridiculous you can say without blushing "I'd rather have a mercedes". And it's yearly, so you can easily have a quite well-paid full-time engineer on staff instead of VMWare enterprise.
And this is just one example of a bug. If you look at the lists of bugs that prevented windows booting, caused extreme slowdowns
Re: (Score:2)
VMware's support has been quite good for us, but then again, we paid for platinum. We actually haven't needed them too much, only for some VLAN tagging issues.
As for the licensing server bug... meh. It didn't hurt us, because we don't run on the bleeding edge version-wise. All developers screw up on occasion. We waited for the patch before upgrading to 2.5u2 plus patch at the same time, testing it in our QA cluster first. Virtualization stacks are still software that has to be managed and tested properly in
Re: (Score:3, Insightful)
In nutshell, Xen devs shoot in the foot here. Have they agreed to be included in main kernel three and be more welcome with patches, it would be more interesting competition here.
Why, yes, they have agreed to include their patches in the main kernel tree, but not all of them have the consent of the upstream kernel developers. The response of the Xen developers has been a significant refactoring of their code. Try reading the readily available documentation on the progress of merging Xen kernel patches upstream [xensource.com].
Re: (Score:3, Funny)
Cool story bro (Score:2, Offtopic)
Protip: The word "protip" is not hyphenated.
Re: (Score:1, Offtopic)
Re: (Score:2)
Well, I've never read GamePro, and never heard "Protip" used in my region, so AFAIK it's not a word.
Protip: What you give a hooker if she's REALLY good.
Re: (Score:2, Funny)
Protip: Apparently, anyone can embiggen the English language, cromulently, whenever one wishes....
cheers,
Re: (Score:2)
By the same token, you can't just invent a word and say well, there - it's been "commonly used" so now its a word.
Just because one gaming mag uses it for it's l33tspeak doesn't make it "popular" or widespread, at least not from where I'm sitting.
I tire of people trotting out the "common usage" defense daily here, in defense of what is usually local slang. In order for your cult to be a religion, you gotta have followers!
Yes, it's true we don't have a Central Authority for Proper English, but more than a se
Re: (Score:2)
your right, its two whole words, each independent of each other, yet acting in harmony out of unity of purpose.
Re: (Score:2)
You can hyphenate whatever you want. Putting "pro" (short for professional) and "tip" together happen to create the same definition as the word "protip" (which isn't actually a word).
Xen needs to improve (Score:5, Insightful)
An exciting technology that I hoped to use, but just not up to the mark.
Re: (Score:2)
Is this the right place to add more anecdotal "insight"? :p
We're using it at work in dozens if not hundreds of hardware and software combinations, and it's not exciting at all, it just works. We use only its free management tools and rely only on its freely available documentation.
HTH, HAND.
Re: (Score:2, Informative)
Where it belongs... (Score:5, Insightful)
Fedora, not RHEL, is really where Xen belongs anyway. It's exactly the sort of mix of neat ideas, dirty hacks, and blatant wheel re-invention that could only have come from academia, and it was only ever made enterprise-grade by throwing heaps of money at it, and even then only for carefully tested configurations. Yes, it's pretty much single-handedly responsible for commoditizing virtualization, but the combination of the design and the lack of cooperation with the kernel community made it a nightmare to support. Xen is responsible for the existence of KVM because it showed such immense promise, and then delivered extreme frustration and pain.
Since Xen decided long ago it was going to be the center of its own universe, it's really in a great position to do cool experimental things that the kernel community would be more cautious about and the enterprise market wouldn't touch with a 10' pole without seeing a strong proof of concept first. That kind of innovation is a stated goal of the Fedora project.
The only technical advantage Xen enjoys right now is a lack of dependency on hardware virtualization features. Since it's impossible to buy a new machine that you can call a server with a straight face that lacks hardware virtualization, this is meaningless in the enterprise world, but Fedora (like other community distros) has a much broader scope, so there's still a real chance there for necessity to give birth to more invention, much like it did in the early days of Xen when x86 hardware virtualization was still a whisper in the halls at Intel and AMD.
Of course, Xensource/Citrix has already driven away most of the community that would have done this kind of pre-product development, so I'm not holding my breath, but it would be nice to see something more to come of all that work (and years of my own life) beyond simply supporting existing users.
Re: (Score:1)
The only technical advantage Xen enjoys right now is a lack of dependency on hardware virtualization features. Since it's impossible to buy a new machine that you can call a server with a straight face that lacks hardware virtualization, this is meaningless in the enterprise world, but Fedora (like other community distros) has a much broader scope, so there's still a real chance there for necessity to give birth to more invention, much like it did in the early days of Xen when x86 hardware virtualization was still a whisper in the halls at Intel and AMD.
I do agree with the post in general, but I wouldn't belittle the fact that XEN doesn't need hardware support. I have already been affected by the dropping of xen from distributions. I do work in academia, so I have to work with older, but completely functional machines.
We've tried to set up our own interal eucalyptus cloud, but ran into trouble when it wanted to use KVM by default (can't recall which installation this was). Also for other basic virtual machines, we'd need HW support, which we don't have in
Re: (Score:2)
"Also for other basic virtual machines, we'd need HW support"
Why? Just use vmware or similar.
Re: (Score:1)
Why? Just use vmware or similar.
Well we'd still need some kind of performance. Of course qemu / vmware would work, but the performance difference vs xen is pretty huge.
Re: (Score:1)
Re: (Score:2)
I don't mean to belittle the significance of Xen's paravirtualization approach, but rather to point out that it's much more suitable for environments like the ones that tend to use Fedora than the ones that tend to use RHEL. Xen tried to be a commercial product way before it was technically ready for it, simply because there was so much market demand for commodity virtualization. Maybe it's ready now, but I wouldn't know, because I gave up on it as soon as KVM reached feature parity, because it didn't req
Re: (Score:1, Interesting)
f you think hardware visualization is fast, you guys need to revisit what hardware virtualization is and how KVM, Xen, Hyper-V implement it.
Please do not jump to conclusions without knowing the concepts and implementation.
Paravirtualization is faster and a much better approach. Do some benchmarks yourself and you will know. Have some of your VMs run in HVM mode, run benchmarks. Then deactivate HVM and use paravirtualized kernel for the VMs and run the benchmarks again.... you will get pretty conclusive res
Re: (Score:2)
For one generation of CPUs, you're right, hardware virtualization was slower. Since then we've gotten hardware nested paging that eliminates the TLB penalty and virtio device drivers that give us paravirtualization in confined I/O devices without having to coordinate the entire memory space between guest and host.
KVM decided to be stable first, THEN fast, and it succeeded. Xen decided to be fast first, THEN stable. The results are a clear lesson in the ills of premature optimization.
Re: (Score:1, Offtopic)
... a nightmare to support ...
... extreme frustration and pain ...
... market wouldn't touch with a 10' pole ...
You sound like you have an axe to grind.
Re: (Score:2)
Yes, I have an axe to grind. I worked in support for Red Hat back when RHEL 5 was released, before the switch to KVM. There were rumors going around engineering about switching to KVM as early as RHEL 5.1, because as unready as KVM was at the time, Xen was a disaster. We shed enough blood to get Xen usable until KVM had good paravirt I/O, so that got deferred for a few updats. Prior to leaving Red Hat Support, I'd get bug reports from customers, and track down patches in xen-unstable that were summarize
Re: (Score:2)
product that just wasn't absolutely rock solid.
I no longer work there, but last I heard those financial services customers were much more interested in KVM than they ever were in Xen.
This doesn't really make much sense, as it goes against the conventional wisdom of software development - newly written or younger software by default scores worse on the stability front compared to old software, even if old software was known to be buggy - exactly because of the simple fact that someone somewhere already dealt with many of its quirks, and hopefully put it in order, whereas there is inherently less proof that anyone ever did that with novelty software. There are exceptions, obviously, but I
Re: (Score:2)
Of course, Xensource/Citrix has already driven away most of the community that would have done this kind of pre-product development, so I'm not holding my breath
I'm curious (genuinely curious, not being snarky)...I've had a bad experience with Xen too, but I haven't kept up with what Xensource/Citrix have been doing. Why do you say they've driven away the community?
Re: (Score:2)
In fairness to Citrix, I think the situation has improved somewhat since the acquisition, as evidenced by the fact that it's even possible for Fedora to be considering this move now. That said, I think it's a day late and a dollar short. Xensource alienated the Linux community prior to that acquisition and Citrix has done little to repair that damage. In my opinion as someone who was forced to support Xen for Red Hat prior to their acquisition of Qumranet, the Xen community has grown primarily because ex
Can someone explain the point of hypervisors? (Score:3, Interesting)
Seems to me they mostly get used to run multiple OS's that each run a single main app. Last time I looked modern OS's are quite capable of running multiple apps at the same time so unless you really need to run different OS's on the same machine (er why?) then what exactly is the point?
Re: (Score:2)
I'll cut you some slack: 1,2,3 and 5 are certainly valid points for why virtualization/hypervisors. 4 is completely non-sense. Virtual hosting or aliased IP's is far more manageable than one VM per site. The only exception might be if you need customer isolation, but even that can be accomplished without virtualization.
My main value out of hypervisors is the detachment from hardware dependencies. If I can upgrade server hardware without affecting my "servers", by effectively just reallocating or migrating a
Re:Can someone explain the point of hypervisors? (Score:5, Insightful)
In general, the point of virtualization in a server room is flexibility. VMs are easy to move around, you do not have to be tied to a single operating system (I hear the most common use of KVM is to run Exchange on system with a Linux hyperviser) on a single physical machine, which is particularly useful for sharing hardware resources when you have to deal with software that only runs on a specific OS. VMs also make it easy to checkpoint a system; KVM has "copy on write" disk images, for example, which track changes from a base image, which could be a COW image itself.
IBM did a lot of research on virtualization use, and I believe they had discovered uses for using VMs within VMs up to four layers deep (I am not really sure what they were doing).
Re: (Score:2)
I believe they had discovered uses for using VMs within VMs up to four layers deep
Space heater?
Re: (Score:2)
Seems to me they mostly get used to run multiple OS's that each run a single main app. Last time I looked modern OS's are quite capable of running multiple apps at the same time..then what exactly is the point?
It can make management of large numbers of machines easier. If you've got half a dozen applications on a machine, owned by different groups, it can be a nuisance to manage upgrade cycles. Some groups may buy their own little servers to get around the problem: with virtualization, you can let the development folk can run their server, *and* host it in the data centre.
Another useful thing is splitting off the hardware support issues from the application support ones. Need to roll out a critical BIOS update ac
Re:Can someone explain the point of hypervisors? (Score:4, Insightful)
You have two choices. You can use actual desktop computers -- power-hungry, subject to failure at that number, and generally expensive to maintain at that scale. Or you can use VMs - a fairly small number of physical servers. Your desktop component can be a simple thin client device -- cheap, power efficient, much lower likelihood of failure, and - when they do fail - much simpler to manage as it takes a few minutes to replace the physical device. Your user never knows the difference, as he still connects to the same VM. If someone screws up a VM, you just rebuild it - an automated process that takes a few seconds. Compared to a PC which can require someone to physically be present at the machine; and at the very least will take 10-20 minutes to copy down the hard drive image over a network.
Now let's say you're expanding - another 2000 users. With desktop PCs you have to order PCs -- hopefully no major changes in hardware since you last ordered, because then your client apps need to be re-certified. Then you have physically image the hard drives to the standard image; then deploy and set up the hardware at each workstation.
On the other hand, if you were using VMs you would add 20-40 servers to the cluster and bring the VMs online. The configuration is completely automated, with a human being required only to press "go". You still have to purchase the thin client devices, but even considering the new servers you bought, the cost is *far* less than buying 2000 PCs. Too, it doesn't matter if the specs change on the thin client devices, because their sole purpose is to connect to the VM. The ongoing cost remains much lower, and setup consists of plugging it in and flashing the ROM. (Though at that size, there's a fair chance you can work out a deal with the manufacturer to do it for you.)
As far as personal/desktop use - good for testing apps on different OSs, and playing with new OSs. Also good from a security perspective (run your web browsers in a VM, and questionable software. Roll it back daily or whenever you think there's been a compromise.) Also good if you're running Linux but have a couple of needed apps that don't work on WINE.
Re: (Score:2)
Virtualization is ESX server.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Seems to me they mostly get used to run multiple OS's that each run a single main app. Last time I looked modern OS's are quite capable of running multiple apps at the same time so unless you really need to run different OS's on the same machine (er why?) then what exactly is the point?
Isolating a single application to a single server is the ideal situation. It dramatically simplifies change management, troubleshooting and dealing with special requirements.
All modern OSes are, indeed, quite capable of r
Errr... what? (Score:2)
We were emphatically told by sev
Re: (Score:2)
RHEL6 supports running as Xen guest (Score:1)
Re: (Score:2)
I can tell you know that it really doesn't matter what you choose. It will eventually be replaced by something shinier and more popular/modern. Such is the way of computers and especially in the open source world. IMHO, KVM became popular because a bunch of people who weren't really using Xen decided that they liked it better and didn't give consideration to the real issues at hand. And now that they've started using KVM for real work, they are running into those issues and regret the whole thing. I've ha
Re: (Score:2)
Do you have servers that are handling thousands/millions of transactions per day? Or are you just running a departmental webserver with just a few users?
Since we're using RHEL AS, which starts at $1500 per year, it's not a departmental webserver.
When we started testing KVM in the initial RHEL 5 release, KVM setup was needlessly difficult -- both Xen and KVM were installed, a Xen kernel was selected by default, and dom0 was setup and started automatically. You can imagine my confusion as a new KVM user.
Now it's just the opposite, as of 5.5 it appears that KVM is the simpler choice. It also seems to be much faster -- although there was a tweak to our networ
Re: (Score:2)
It's mainly Xen who is trying to get Xen supported in Fedora 13, more than the contrary. If the Xen guys manage to get Xen merged in the kernel Fedora probably won't have problems enabling it or offering alternative packages to use it. But KVM is still the focus.
RHEL5 fully supports Xen (Score:1)
Re: (Score:2)
Unless, you know, you can see further than 4 years down the line.
Re: (Score:2)
We want to use a single virtualization platform for all our servers which means a migration from ESXi.
I'm curious as to the advantages of moving away from ESXi - I'm in a much smaller environment than what yours sounds like, but I've been happy with ESXi for all the guests I've run on it (Windows & various Linux distros). Before spending real money on it, though, I'm looking at other options. To me the ESXi hypervisor idea seems great - next to nothing running on the box means less to go wrong etc. The VSphere stuff seems to give all the bells & whistles I would need, and the price isn't excessive f
Re: (Score:2)
Re: (Score:2)
Thanks for that - I hadn't thought of the 4 cores issue. I have been a little frustrated with the difficulty of moving images around, though. Maybe I'll dig out an old server & do some playing with alternatives, I have a buddy who loves Xen but I haven't done anything with it or KVM.
Re: (Score:2)
We want to use a single virtualization platform for all our servers which means a migration from ESXi.
You're crazy to be moving away from ESXi, then. Especially to RHEL, where the builtin management capabilities around virtualisation are pathetic, to say the least.
We were emphatically told by several people at Red Hat (2 salespeople, our dedicated support engineer, and 2 other support staff) that Xen was the wrong direction and that only KVM would be supported in the future AND that existing support fo
Citrix alternatives? (Score:1)
Re: (Score:1)
Re: (Score:1)
Xen support in Fedora 13 (Score:1)
I stopped caring about Xen when... (Score:1)
I saw a live virtual machine migration across processor families and types [youtube.com]. Wish they would release that tech soon rather than work on getting Xen support back.
Re: (Score:1)
Beh (Score:2)
Does this version of glibc.x86_64 make my butt look big?
Good (Score:2)
Maybe this will force the Xen people to write maintainable code so we don't have to keep using 2.6.18 and backport everything.
Re: (Score:1)
It's here, now (Score:2)
Use the myoung dom0 repo. I've been running a Fedora 12 Dom0 for a few months now.
I so want to like KVM, but it's still fragile. I'll continue to help file and test KVM bugs so it's better than Xen at some point.