The truth about KVM and Xen
When I saw this article in my inbox, I knew I shouldn't bother reading it. I really couldn't help myself though. I'm weak for gossip and my flight was delayed so boredom got the best of me.
I can't blame the tech media for the wild reporting though. The situation surrounding KVM, Xen, and Linux virtualization is pretty confused right now. I'll attempt to do my best to clear things up. I'll make an extra disclaimer though that this is purely my own opinions and does not represent any official position of my employer.
I'm think we can finally admit that we, the Linux community, made a very big mistake with Xen. Xen should have never been included in a Linux distribution. There, I've said it. We've all been thinking it, have whispered it in closed rooms, and have done our bests to avoid it.
I say this, not because Xen isn't useful technology and certainly not because people shouldn't use it. Xen is a very useful project and can really make a huge impact in an enterprise environment. Quite simply, Xen is not, and will never be, a part of Linux. Therefore, including it in a Linux distribution has only led to massive user confusion about the relationship between Linux and Xen.
Xen is a hypervisor that is based on the Nemesis microkernel. Linux distributions ship Xen today and by default install a Linux guest (known as domain-0) and do their best to hide the fact that Xen is not a part of Linux. They've done a good job, most users won't even notice that they are running an entirely different Operating System. The whole situation is somewhat absurd though. It's like if the distributions shipped a NetBSD kernel automatically and switched to using it when you wanted to run a LAMP stack. We don't ship a plethora of purpose-built kernels in a distribution. We ship one kernel and make sure that it works well for all users. That's what makes a Linux distribution Linux. When you take away the Linux kernel, it's not Linux any more.
There is no shortage of purpose-built kernels out there. NetBSD is a purpose-built kernel for networking workloads. QNX is a purpose-built kernel for embedded environments. VxWorks is a purpose-built kernel for real-time environments. Being purpose-built doesn't imply superiority and Linux currently is very competitive in all of these areas.
When the distros first shipped Xen, it was done mostly out of desperation. Virtualization was, and still is, the "hot" thing. Linux did not provide any native hypervisor capability. Most Linux developers didn't even really know that much about virtualization. Xen was a pretty easy to use purpose-built kernel that had a pretty good community. So we made the hasty decision to ship Xen instead of investing in making Linux a proper hypervisor.
This decision has come back to haunt us now in the form of massive confusion. When people talk about Xen not being merged into Linux, I don't think they realize that Xen will *never* be merged into Linux. Xen will always be a separate, purpose-built kernel. There are patches to Linux that enable it to run well as a guest under Xen. These patches are likely to be merged in the future, but Xen will never been a part of the Linux kernel.
As a Linux developer, it's hard for me to be that interested in Xen--for the same reasons I have no interest in NetBSD, QNX, or VxWorks. The same is true for the vast majority of Linux developers. When you think about it, it is really quite silly. We advocate Linux for everything from embedded systems, to systems requiring real-time performances, to high-end mainframes. I trust Linux to run on my dvd player, my laptop, and to run on the servers that manage my 401k. Is virtualization so much harder than every other problem in the industry that Linux is somehow incompatible of doing it well on its own? Of course not. Virtualization is actually quite simple compared to things like real-time.
This does not mean that Xen is dead or that we should have never encouraged people to use it in the first place. At the time, it was the best solution available. At this moment in time, it's still unclear whether Linux as hypervisor is better than Xen in every scenario. I won't say that all users should switch en-masse from Xen to Linux for their virtualization needs. All of the projects I've referenced here are viable projects that have large user bases.
I'm a Linux developer though, and just as others Linux hackers who are trying to make Linux run well in everything from mainframes to dvd players, I will continue to work to make Linux work well as a hypervisor. The Linux community will work toward making Linux the best hypervisor out there. The Linux distros will stop shipping a purpose-built kernel for virtualization and instead rely on Linux for it.
Looking at the rest of the industry, I'm surprised that other kernels haven't gone in the direction of Linux in terms of adding hypervisor support directly to the kernel.
Why is Windows not good enough to act a hypervisor such that Microsoft had to write a new kernel from scratch (Hyper-V)?
Why is Solaris not good enough to act as a hypervisor requiring Sun to ship Xen in xVM? Solaris is good enough to run enterprise workloads but not good enough to run a Windows VM? Really? Maybe :-)
Forget about all of the "true hypervisor" FUD you may read. The real question to ask yourself is what is so wrong with these other kernels that they aren't capable of running virtual machines well and instead have to rely on a relatively young and untested microkernel to do their heavy lifting?
Update: modified some of the text for clarity. Flight delayed more so another round of editing :-)
posted by Anthony Liguori at 3:16 PM
41 Comments:
Actually you are wrong in Xen never being merged into the kernel.
Some guys from Redhat got Xen dom0 working under pv_ops (paravirt_ops) and are working on getting that upstream.
http://berrange.com/personal/diary/2007/11/plan-for-xen-kernels-in-fedora-9
dom0 is not Xen. That's the distinction I'm trying to make. Xen is a 30k line microkernel that will never be merged into Linux.
dom0 is just a very special guest that runs underneath of Xen.
Oh, well in that case you are completely right. Everyone knows kvm is the way forward anyways. It makes the most sense in that it doesn't reinvent the wheel and uses linux's strengths to it's own advantage.
You are a bit biased seeing as you post on kvm-devel all the time though ;-)
Blunt and honest - I like it. How long do you think it will take for RHEL/SLES to go full KVM and not Xen?
FYI, there's a typo in first sentence of third paragraph (should be "I think")
Solaris runs a perfectly good hypervisor: it's called VirtualBox. Oh, that runs on everything else too.
VirtualBox is not a hypervisor, as KVM is not. The "-visor" part, from "supervisor" on non-virtualized mainframes, means "the lowest layer on top of the metal." VirtualBox is a service that runs above an operating system, so it's not a hypervisor.. Period. End of discussion. "Type 2 hypervisor" is like "military intelligence" and "Fox News - Fair and Balanced" -- an oxymoron.
If you are a religionist who believes you're shipping the Holy Linux, and the Great God Linus and company write the code at the center of the universe, then you're right -- if virtualization is just another application to run under Linux, and Windows guests are a convenience sub-option of that feature, you assess an appropriate role for KVM.
But most businesses, as opposed to convenience end-user desktops, allocate entire boxes to virtualization. Their primary goal is to deliver virtualization, not specifically Linux. The Windows and Linux they run are both sub-options of virtualization. For that majority real-world scenario, a small kernel that does nothing but virtualization SHOULD be at the center of the universe, unencumbered by a general-purpose scheduler that has to know how to schedule resources for EMACS and Oracle.
So: if "Linux distros" are not the best place to offer a lowest-level virtualization technology, they're also by definition not the best tool to build a virtualization infrastructure. If virtualization is Job One, you need a real hypervisor, not one Linux service among thousands.
mdolan: the distros will probably move to a true linux solution once it's clear that we're competitive with Xen.
John: VirtualBox is a good model, I'd love to see Solaris adopt it for future versions of xVM. I'd love to see work on common interfaces between VirtualBox and KVM so that common userspaces could be developed.
anonymous1: VirtualBox and KVM are type I VMMs. They have kernel modules that modify the underlying kernel to be a traditional hypervisor. A type II VMM does not require OS modification.
anonymous2: I disagree. I have a great deal of faith in Linux. If I'm running my entire datacenter on one machine, I *want* Linux to be that base. I certainly don't want a microkernel from a university (that borrows a huge amount of code from Linux, btw), to play that role.
Anthony, Sun are using both VirtualBox and Xen as two complementary technologies (along with ldoms on the SPARC side). Indeed, VirtualBox has
been (partially) rebranded as xVM VirtualBox.
And yes, it'd be great to see what things can be shared between all the qemu-using v12n tech, and kvm and vbox in particular.
Aaa, nice topic to blog about. Made a few things more clearly. Keep up the news about KVM!
I'm glad your flight was delayed and you were *stupid* enough to read the KVM vs Xen article, as your contribution has been very valuable in clarifying was Xen isn't (I'm sure lots of folks think dom0 is Xen running on Linux rather than Linux on Xen). A very worthwhile contribution to understanding Virtualization.
Thanks
Very interesting!
Helps me to understand what the error messages mean when I try to boot the Ubuntu Dom0 kernel. :-)
Are there any major differences when running XEN or KVM from the point of view of the user.
I am mainly thinking of having multiple full screen sessions and switching between them.
Does this use virtual terminals ?
Do you have to have full blown X and Gnome running before you can access your VMs graphically?
Can anyone direct me to some HOWTO which might answer these questions?
Many thanks.
"Why is Solaris not good enough to act as a hypervisor requiring Sun to ship Xen in xVM? Solaris is good enough to run enterprise workloads but not good enough to run a Windows VM? Really? Maybe :-)"
I'm a little confused here, I wonder if you could help me...
according to this, Sun xVM Server would ship the Nemesis-based Xen kernel with a Solaris OS on dom0, right?
and according to Sun's information (http://www.openxvm.org/projects.html), Sun xVM Server allows guest OSs to make use of solaris' Dynamic Self-Healing, ZFS, and other technologies...
these technologies should be on the base kernel, right? ... then what would it be... did they port those things to the Nemesis-based kernel or did they actually changed the Nemesis with a Solaris kernel?... or can the be used with the dom0 kernel?
Phobos: in xVM, Solaris is acting as domain-0 but AFAIK, the Xen hypervisor is pretty close to what is upstream in Xen.
Presumably, they are talking about those features being available in domain-0 but you'll have to ask some folks from Sun. You're asking the right questions though!
I see, thanks for your answer!
Let's see if I can find that out on their forums hehe
anonymous2 said : ..."For that majority real-world scenario, a small kernel that does nothing but virtualization SHOULD be at the center of the universe," ..."if Linux distros are not the best place to offer a lowest-level virtualization technology, they're also by definition not the best tool to build a virtualization infrastructure."
As anonymous4 I think that KVM module can probably be integrated in a small footprint GNU/linux, like these embedded on devices, with uclibc, busybox and other small environment librairies. Then I think that it will be able to "allocate entire boxes to virtualization" like other bare metal hypervisors.
about KVM being the way forward - from a sysadm's point of view all the work that goes into KVM is a total waste.
for high-end scenarios there's like a dozen features that do work with xen and dont work with kvm.
KVM is maybe nice for dev purposes, the same thing is what still slows Xen - the devs are content with a little "VMWare" for their pc to run toy systems.
I want 800 servers running 15 vms each and this in proper HA config, and I dont think switching to KM will be the right road for this. too many immature / unexperienced devs work on KVM, who don't even understand the simplest issues of clean design, i.e. people who really think that it were an advantage to see a virtual box in "ps / top".
Yeah, thats great if you keep forgetting xm commands and if you never ran over 30 systems.
This is the way KVM is going, and given the choice of using KVM, even in it's state 3 years from now or paying $5k for VMWare ESX per node i'll rather get my boss to pay for ESX than banging my head all day.
To me it seems some, not all, of the KVM crew never fully understood Xen, now set out to rewrite something that could be called "Xen1.x with HVM and userland to be built by the user" and
stuff like this "Oh, well in that case you are completely right. Everyone knows kvm is the way forward anyways. It makes the most sense in that it doesn't reinvent the wheel and uses linux's strengths to it's own advantage." seems they'd even love to change history towards it.
Let me clarify a bit: where is shype, multiple (even if all bad) schedules, vnetd, 3rd party softswitches, the whole xmlrpc management stuff, where is a small linux kernel to run from flash, where is the first single system image clusters for it? where's ANYONE caring to do stability testing for KVM? Has anyone even thought about grid-sized KVM install? Where is a dedicated layer for storage?
If some users mispercept Xen being an App running on linux, well, thats a pity. But to change technology just to have a safe base of "linux everywhere" is weird and will only make sense if someone comes up with a HIGHLY robust kernel for KVM. and seeing how the linux community deals with their carrier grade folks i can safely assume this will never happen, until the whole focus for KVM changes. I think that won't happen either. KVM is a simply "me too" projects covering the most simple Xen features. I would be really greatful if the KVM stopped spreading FUD about Xen until they actually have it at a state where it is able to replace Xen not just for a developers desktop or a school file server.
Some of the stuff I referred to doesnt even work properly in Xen, but at least it exists and was put in by people that understood what it's meant for.
darkfader: I'm going to ignore most of what you wrote as it is obviously flamebait. In particular, your claims that KVM developers don't understand Xen, do a little research there and you'll likely surprise yourself.
I'm intrigued by one comment though:
shype, multiple (even if all bad) schedules, vnetd, 3rd party softswitches, the whole xmlrpc management stuff, where is a small linux kernel to run from flash, where is the first single system image clusters for it
For KVM, SELinux would be the sHype equivalent. Right now, to build a high assurance environment for Xen, you have to write both sHype policies and SELinux policies for domain-0. The prospectives of just having to write a single SELinux policy for KVM actually has a lot of people in the security community very excited. KVM makes far less assumptions about privilege too FWIW.
I don't know why you consider multiple schedulers a virtue. Linux has gone through it's fair share of schedulers. At this point, there's been a lot of talk in the Xen community of dropping the alternative schedulers because everyone's pretty happy with the credit scheduler. Of course, in the absence of gang-scheduling, which neither Xen nor Linux does right now, I'd put my money on CFS over credit.
VDE solves the same problem as vnetd (which throughout history typically didn't build at any given time). I have no idea what a 3rd party softswitch is but keep in mind, all Xen network traffic goes through domain-0 and uses Linux for routing. Chances are anything out there for Xen today would Just Work with KVM.
I would not consider xmlrpc much of a virtue in Xen. I'm very happy to admit that that was a mistake (I did the conversion in Xen from S-Expr over HTTP to XML-RPC). Trying to build network management as part of the basic architecture is a layering violation and has made more people unhappy than it has made happy. At any rate, libvirt serves as the management infrastructure for KVM and FWIW, most people seem to be using it for Xen too. The good thing about libvirt is that you get to choice whether to use it or not.
Any one who wants to can build a small Linux kernel for embedding KVM. There are companies that are doing this today (like Cisco). And I'm not sure what you mean by single system image. Xen doesn't support SSI but perhaps you're mistakenly use the term to mean something else. Perhaps what oVirt does (which is based on KVM, btw)?
I have to disagree with the author. A true light-weight hypervisor is needed because the task a hypervisor needs to do are quite different than what a general pupose OS like Linux needs to do.
You need a small and robust microkernel which is designed with one goal i.e. virtualization. The scheduling algorithm needed for a hypervisor based scheduler that schedules virtual CPU are very different from a task scheduler. As an example virtual CPU needs to service interrupts and a delay in servicing interrupts can cause serious IO performance degradation. A general purpose OS's task scheduler doesn't need to worry about these things since interrupts are always serviced fast.
There are many other details which makes XEN or Hyper-V the hypervisors of the future. Otherwise why do you think Microsoft discarded virtual PC/virtual Server to build a brand new product?
All that said, KVM (or Virtual PC/Server) has its place which is client scenarios as it is easy to support sleep/hibernate etc and KVM . A hypervisor like XEN is more difficult to implement if you are looking for client scenarios such as laptop since you want features like sleep/hibernate etc. Also for client use you want to make sure the performance of your main copy of OS is not affected so a hosted virtualization solution like KVM or Virtual PC suits there.
I feel, as other poster said, that you are most probably biased because of your close association with Linux or KVM.
The scheduling algorithm needed for a hypervisor based scheduler that schedules virtual CPU are very different from a task scheduler. As an example virtual CPU needs to service interrupts and a delay in servicing interrupts can cause serious IO performance degradation. A general purpose OS's task scheduler doesn't need to worry about these things since interrupts are always serviced fast.
What in the world does this even mean? The scheduler has nothing to do with interrupt injection. Interrupts happen immediately--that's why it's an interrupt, it interrupts the current task.
When it comes to IO performance, a model like KVM (or ESX for that matter) where the device drivers are essentially in the hypervisor is far superior because you can service IO immediately within the hypervisor instead of having to switch to another domain (waiting for that domain to be scheduled in).
I was talking about virtual interrupt injection. I don't know how KVM injects interrupts but usually HVM provides support for virtual interrupt injection but the interrupt is only taken when the virtual CPU is scheduled. Also while the virtual CPU is running the ISR, it is preferred that it is not descheduled.
These are the type of things a hypervisor scheduler is designed to take care of where as a general purpose OS scheduler isn't.
Once the IOMMU support is added to KVM (btw IOMMU support is already available in XEN) it becomes even more important because guest OS services hardware interrupts as well.
Xen doesn't have any special support for not descheduling a guest while an interrupt routine is running. It actually doesn't matter b/c an interrupt routine only disables interrupts for that particular VCPU so pre-empting isn't going to cause the same sort of issues that pre-empting while holding a spin-lock would.
Unlike Xen, KVM's device emulation runs in the same time slice as the guest so when a KVM device attempts to inject a virtual interrupt, it is immediately injected (there is no need to wait for the scheduler to run).
When you say that it is not like a spinlock problem, I understand that. But what I was saying is that IO performance (particularly network IO) is very sensitive to latencies. Unless the scheduler knows and can schedule VCPU quickly but probably for shorter timeslices it degrades performance.
Ofcourse then there are other aspects like you don't cause too much context switching etc. But as you can see these scheduling decisions seems pretty different than a general purpose scheduler, no?
To me, architecturally XEN's model seems better because it has clear separation of roles but that is probably a personal preference thing.
You're actually arguing for KVM and you don't even know it :-)
All IO in Xen is done through domain-0. Let's consider networking. A packet arrives and the hardware causes an interrupt. This goes to the Xen hypervisor. Xen then forwards the hypervisor to domain-0 (having to let it be scheduled mind you). Domain-0 then handles the interrupt for the network device driver and makes anyone sleeping on incoming network packets runnable.
This will cause either blkback or qemu to be scheduled depending on PV or HVM. The backend driver will handle the IO and then generate a virtual interrupt for the appropriate guest via an event channel notification. Now we have to wait for this domain to be scheduled so it can check it's event channel bitmap and then inject the real interrupt into the guest.
Compare this to KVM. The hardware interrupt goes directly to the Linux kernel and the networking device driver. This causes anyone waiting on network packets to be marked runnable. In this case, that's QEMU. QEMU wakes up, handles the packet, and then injects a virtual interrupt into the guest.
A key difference between Xen and KVM is that since IO is handled on behalf of the guest (instead of a different domain), no scheduling has to happen to complete the IO operation.
This makes the latency in KVM *significantly* lower than in Xen. For HVM in particular, we're talking about differences of an order of magnitude. KVM is one of the main reasons XenSource is now working on stub domain for HVM. It turns out the current Xen model is very bad when it comes to IO latency.
Let me put my thoughts in it. My KVM understanding is limited so correct me if I am wrong somethere. If a guest is running with HVM support then when a hardware interrupt comes in, you get a vmexit. Based on the exit reason the control will be transferred to the dom0 virtual CPU in case of XEN and physical CPU in case of KVM by exiting out of VMX/SVM mode. This has almost the same overhead for both KVM and XEN but now once user mode process in KVM injects an interrupt in the guest it is linux's scheduler who will have to figure out that it is an important event and it should run the virtual CPU immediate.
Yes there are some advantages of having drivers inside the hypervisor like ESX but there are many downsides with increased attack surface. This model doesn't easily scale well once you have device VMs since it is not tuned for that model where as XEN's model is already tuned for that (since dom0 is a device VM in itself).
By the way, you shouldn't compare KVM model with ESX as ESX is a hypervisor + kernel specially designed for just virtualization where as KVM is a hosted virtualization solution more like Microsoft's virtual PC or VMWare server.
Not quite. When an interrupt arrives in Xen, and a guest is running, a vmexit will occur. The exit reason will be, 'an interrupt has occurred', and state will be transferred to the hypervisor running on the same CPU as the guest was running.
The hypervisor now has to decide whether domain-0 should get that interrupt. If so, it has to schedule domain-0 and inject the interrupt into domain-0.
In KVM, the interrupt goes to Linux immediately.
NetBSD purpose built for networking?
Who gave you that idea? It's a Unix->BSD derivative and while it had one of best first TCP/IP stacks that was always a addon and still feels like it (e.g. separate mbuf memory management)
I doubt also QNX was built for embedded originally. Better examples for that would be ECOS or ucos.
And while Xen is in some central parts non Linuxy it still has enough copied Linux code that calling it a Linux fork is appropiate. Unfortunately it's more Linux 2.4 code than the often much better 2.6 code base.
In general I agree with your points that Xen was a mistake and KVM is the better model. Or rather the Xen design might have made sense with the i386 section limit trick where you really need a small hypervisor, but on anything 64bit which is the future it is just a mistake. Besides Xen is growing at such a rate that it's far from small anymore now by itself anyways
(just count the number of hypercalls and sub hypercalls now) And with the fully trusted Dom0 the TCB is also always gigantic even with Xen.
And the best proof of Xen not being part of mainstream Linux is that the Xensource releases are still stuck at 2.6.18.
What worries me somewhat is that KVM doesn't have real release engineering though. Actually finding a kernel module+user land combination that really works well can be quite difficult. That makes KVM unfortunately still a challenge to actually use for production
Anthonoy Liguori: Sorry, you are wrong, but VirtualBox is indeed a Type 2 VMM. It doesn't modify anything in the kernel, but only compiles its own networking module for the kernel to load. you can read more about VirtualBox and being a Type 2 VMM here: "http://www.eweek.com/c/a/Virtualization/Sun-VirtualBox-a-Solid-Alternative-to-VMware-Parallels/"
The full of this article is crap. From begining to end, it doesn't make sense.
When I read Quite simply, Xen is not, and will never be, a part of Linux., well, first, there IS already domU support in the linux kernel, and dom0 is being added as of writing. Insisting saying I don't think they realize that Xen will *never* be merged into Linux is stupid, you said it before, and it's not because you say something wrong twice that it's more truth...
These patches are likely to be merged in the future, but Xen will never been a part of the Linux kernel. is crap. As if it was different for KVM??? Do you think that the userland tools for KVM will one day be included in the kernel sources ? No way, simply because this is not the place to put them.
Is virtualization so much harder than every other problem in the industry that Linux is somehow incompatible of doing it well on its own? is also stupid. THERE IS NO EQUIVALENT OF XEN right now, and KVM is, and will never be an equivalent. KVM intend to do FULL virtualization, while Xen wants to MODIFY the kernel so it runs better virtualized. These are 2 completely different approach that the author of this blog forgot to mention, and that makes it impossible to use KVM in a production environment.
At this moment in time, it's still unclear whether Linux as hypervisor is better than Xen in every scenario. well, it's pretty clear that if the KVM developers are continuing in the direction of non-PV kernels, it will NEVER be ready for production...
Stop writing crap just because you feel it's a shame that Xen held by a bunch of people not from the kernel team. It wont make KVM any better... Also, all what you said in your blog entry proves one thing: you didn't understand what is a distribution or an hypervisor, and the use people have of it.
You can see the kernel module in the VBox source tree which certainly proves it's a "bare metal" hypervisor. See here although the Linux glue is elsewhere in the tree.
FWIW, KVM all "modifies" the guest kernel to improve performance of guests. There are paravirtual IO drivers available for both Linux and Windows and Linux guests are capable of a number of paravirtualizations through paravirt_ops.
But I don't necessarily see how paravirtualization has anything to do with production quality.
Just because something ISN'T the Linux kernel doesn't mean distros shouldn't or won't include it.
Distros include tools like EMACS, but they're not the Linux kernel. If there are people who want to run Linux within a true hypervisor, there will be some people offering a distribution that will work for this purpose.
There's nothing wrong with having a Linux distribution choose to virtualize Linux under a purpose-built kernel, when virtualization software is chosen to be installed.
Anthony: Sometimes Type II VMs DO require OS modification. For example, VMware Server is a Type 2 VMM.
The Linux version of VMware Server requires kernel modules and OS modification to work, but that doesn't make it a hypervisor.
KVM is not a type I Virtual Machine Monitor. What sets true Hypervisors apart from hosted options like Linux KVM, is that a Hypervisor is by definition not a general-purpose OS.
Hypervisors do not run programs, they run only virtual machines.
What makes KVM not a hypervisor is the fact the kernel does normal duty as well (you can run programs directly on the 'host' OS).
i don't know much about either Xen or KVM, (which is why i am reading this) but having played with SUN "Sparc 4v" architecture i really like their method of "Virtualising" hardware i.e a Hypervisor in the Service Processor to create LDOM's. (no need for full OS to provide VE) i know it is hardware dependent (which x86/x86_64) can be limited, but is there a similar type of virtualsation avaialble on Linux, i.e primarily to have an advantage if a panic or reboot happens in any ldom, it doesn't affect the other. is this the case with any of the Linux virtualisation techniques
so is there a really lightweight distro around now that focuses purely on this kernel-based hypervisor, supporting userspace apps/GUI, & removes anything not needed?
I had a quick look at the main KVM site and it looks as though there's support to add it to some of the main distros, but I want something much more cut-down....
cheers,
jed
virt n00b
This post has been removed by the author.
Anthony/anyone?
Any advice regarding my prior post would be very much appreciated.
all the best,
jed
Anthony? Anyone else?
Any advice greatly appreciated.
Cheers
so is there a really lightweight distro around now that focuses purely on this kernel-based hypervisor, supporting userspace apps/GUI, & removes anything not needed?
I had a quick look at the main KVM site and it looks as though there's support to add it to some of the main distros, but I want something much more cut-down....
cheers,
jed
virt n00b
nice to read all the posts here.
I use virtualization since several years to run different systems from Linux to *BSDs as part of my business. I like Linux and use it since 1993, but the most importants for me are: performance, availability and flexibility on high load servers.
Since around one year i follow KVM and tried it several times, but until today it seems not to be an alternative for me on servers. On my desktops KVM is still used.
May be im wrong and/or this will change in the future, but really less important is that i use a "plain linux" - most of our servers are still running mixed linuxes and *BSDs (as you said, there are different OS for different application areas). The Xen hypervisor is available with linux or *BSDs - from my view it is just a tool which does his job as it should.
But i agree that the current politics of linux distributions which are installing xen or KVM hosts/guests by default is a bad idea. If a user explicitely wants to use virtualization he ill install that byself.
Unhfortunately the current discussions about KVM, XEN & Co. seems still to hot which makes nearly impossible to make a serious decision for or against KVM at the time.
Cheers,
Niels.
---
Syndicat IT&Internet
It's redhat's baby, they should have a specialised distro for it.
Like all the different flavours ubuntu brings out...
They should bring out a kvm-focused one.
so is there a really lightweight distro around now that focuses purely on this kernel-based hypervisor, supporting userspace apps/GUI, & removes anything not needed?
Check out Proxmox VE. It support both KVM og OpenVZ. It's easy to install and everything is managed by a web interface.
http://pve.proxmox.com/wiki/Main_Page
never really looked into openvz, thanks for the suggestion!
Post a Comment
<< Home