Slashdot Mirror
Novell To Ship Xen in Next Version of Suse
daria42 writes "The next version of SuSE, to be shipped in mid-April, will ship with the Xen virtualization software, letting users run multiple versions of the operating system simultaneously, the company said on Thursday. The article says that Red Hat has also begun adding Xen support to Fedora."
It has only technical reasons, that windows is not supported. From the Xen FAQ ( http://www.cl.cam.ac.uk/Research/SRG/netos/xen/faq .html#a1.4):
Unfortunately we do not currently support Windows; the paravirtualized approach we use to get such high performance has not been usable directly for Windows to date. However recently announced hardware support from Intel and AMD will allow us to transparently support Windows XP & 2003 Server in the near future. We are working on this and intend to have support available by the time the new processors are available.
You could always give qemu a try...
http://fabrice.bellard.free.fr/qemu/
A very nice, reasonably fast, and open-source x86 emulator.
Runs Win98 nicely.
They have just released a kernel module (on a free-as-in-beer basis) which speeds up the emulation to 50% native (works with Win2k but not Win98 yet).
Parent post is pure, unadulterated bullshit.
You don't install Wine into a virtual machine any more than you install Office or HalfLife into a virtual machine.
You install an OPERATING SYSTEM into a virtual machine, then you install applications on that OS.
Wine is an application, no different than OpenOffice. It uses the services of the underlying operating system to do its job. The fact that its job is to provide the APIs of a foreign operating system is incidental.
So, all that running Xen would do is to allow you to have an install of Linux or *BSD solely to run Wine - which would provide no real benefit to running Wine.
The only way in which Xen would be of use in running Windows programs would be if Windows ran under Xen - which last time I checked it DOES NOT.
The poster of the parent post is just trolling for stupid moderators, and obviously has already found at least one.
www.eFax.com are spammers
Xen can be significantly faster due to the difference in how it works.
UML is a port of the kernel to a "POSIX architecture" so that it runs in userspace.
Xen is a port of the kernel to a quasi-x86 architecture (basically x86 with some non-virtualizable instructions removed). This means that most of the time Xen is running directly on the hardware.
Xen outperforms UML. At least on applications that heavily work the OS.
It's faster, but with current hardware it needs support from the guest OS. You basically need to build the guest kernel to run within Xen.
This is fairly straightforward for open-source OS's, but is why you can't currently run windows on top of Xen.
If I understand it correctly, the big problem is that the X86 architecture was designed without this sort of thing in mind, so it is difficult to get it to work well without making changes to the operating system. The new 64-bit architecture addresses this limitation.
I have. I have a single computer acting as my local home server (a p3-500 with 512mb ram). This machine acts as a linux desktop, development machine, it handles my mail and web stuff, and it acts as a shells-server sandbox for a friend who uses it to test his code on. Some of these things are mutually exclusive (I like to run debian stable for mail+web, while my development stuff is bleeding edge). Also, it is handy for said friend to have root access in order to be able to install needed packages. With a VM he can have a sandbox to freely play around in without having it affect my system in any way.
As a result, i have a base system for my desktop (currently running Ubuntu Hoary), and on top of that are 3 VM's: one for mail, one for web, one for shells. The filesystems are stored in containerfiles, so they are very easy to backup. Until a couple of months ago I used User Mode Linux for these VM's, but UML development doesn't seem to progress very much and performance wasn't optimal, to say the least. Because of this, I switched to Xen and I've been very happy with the results. Setting is very easy. Compared to UML, Xen is _much_ faster. I haven't noticed any overhead from Xen, both the host system and the individual VM's seem to operate at native or near native speed, while UML (even with skas etc) took a very noticable performance hit. Development seems very active, tracking the newest kernels. Also, the management tools are really nice. Setup of the network was much easier for me than with UML, every VM automatically creates ports for the console, and there's is additional web management that makes managing the VM's really friendly. All in all, if you have any interest in playing with this stuff, I would very much recommend Xen.
iTunes already works in Wine. There has been some significant development to get it working more smoothly lately, especially in Crossover Office, but also in the vanilla Wine tree. No idea about the other app you mentioned, I've never heard of it, but it's probably worth giving it a whirl in Wine.
Game! - Where the stick is mightier than the sword!
Xen is going to be a much better performer than UML. However, if you need maximum performance and are OK with running only one operating system (Linux), consider Linux VServer. It gives you most of the functionality of "virtualization" (even though it's not true virtualization since there is only _one_ kernel running on the machine) - a complete "virtual server" appearance with essentially no overhead.
There are numerous advantages to the VServer approach (a.k.a. as Zones on Solaris and Jails on FreeBSD, BTW), such as the ability to access the filesystem from host (very useful for backups), ability to view/control the virtual server processes from host, single VM and IO across all virtual servers thus providing much better optimization. The performance is stunning - you just don't feel "virtualized".
Linux VServer isn't backed by major universities and Microsoft Research and thus unfortunately does not get the publicity, even though it is one of the most revolutionary projects out there IMHO. I hope it becomes part of vanilla kernel some time soon.
1.4 Does Xen support Microsoft Windows?
Unfortunately we do not currently support Windows; the paravirtualized approach we use to get such high performance has not been usable directly for Windows to date. However recently announced hardware support from Intel and AMD will allow us to transparently support Windows XP & 2003 Server in the near future. We are working on this and intend to have support available by the time the new processors are available.
"You mortals are so obtuse." -Q
See one of my recent journal entries.
For my uses for my Internet server, Xen has proven an _order of magnitude_ better performing than UML, although there were some other changes that helped (going from file-backed filesystems to partitions for each Xen domain). But even without that, in practise, in most every day loads, the performance overhead of Xen compared to native is only around 2%, where the overhead of UML+skas3 is greater than 50%.
The Xen website has a performance comparison which has been independently verified. Xen has also been compared against IBM's mainframe virtualization.
Oolite: Elite-like game. For Mac, Linux and Windows
Windows on Linux is here already thanks to Qemu.
I wrote a simple guide to Running Windows inside Debian a while back which seems fairly popular.
The big difference with Zen is that it requires the operating systems it runs to be modified, whereas Qemu will run any native operating system, Linux, Windows, *BSD, Knoppix, etc without change.
That to me makes it more useful.
QEMU looks like a worthy replacement for VMWare, especially given the recent release of the accelerator module. Fabrice is hoping for corporate support of the project, and IMO he is as deserving as anyone.
Well, microsoft research originally sponsored xen development, and did port a version of XP.. However it's not available to the general public, not even to people who legitimately have copies of xp already.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It's complimentary to this. In terms of Grid computing the ability to run jobs in sandboxed containers that exist only for the life of the job and may be a bespoke version of an OS (different OS, different libraries, etc., etc) is exactly what is needed. Lots of work is going on in this area, and VMWare, User Mode Linux, and Solaris containers are all tools which allow this to be implemented.
Of course you could argue that you could just run Solaris x86 and then use containers to host an instance of another OS, and on that basis Xen is superfluous, but a (small) number of competing options is not necessarily a bad thing. (Lots of forks and reinventions of the wheel are bad things).
Wine isn't an implementation of this concept, although Wine running inside a virtual server would be an implementation that might allow Windows programs to run.
The issues with some of these approaches (notably VMWare and to a certain extent User Mode Linux) has been the performance hit that applications take when running inside the virtualised servers. If Xen addresses some of these issues then it is a welcome development for those of us working on Grid infrastructures.
What Xen doesn't do, though, is run on non-x86 machines. So if you have a power pc cluster running Linux, you can't use Xen, but only User Mode Linux.
This is multiple Linuxes running on a VMM: Virtual Machine Monitor. The Linuxes run side by side, none run inside each other.
The technique takes advantage of the multiple rings (0-3) on Intel. Normally Linux (and other kernels) run on ring 0, but with Xen the Xen VMM runs on ring 0 while Linux and other guest OSs run on ring 1, while user-mode programs continue to run on ring 3.
There's a separate root directory for each vserver, which means one can install whatever Linux distribution one wants in there, as long as the distribution doesn't depend on a special kernel (it shouldn't: near-metal operations will be done in the host kernel). Your argument is at fault here.
There's only one kernel instance running though, which is your point I believe. Xen seems to support non-linux OSes such as FreeBSD.
lots of distros are adding support for xen or at least have plans to. Xen support is supposed to be merged into the kernel in the near future as well. Also, big boys like IBM are starting to show lots of interest in Xen... my point is it's a significant trend where as a few months ago most people were still saying "wtf is xen? those aliens from HL2?"
Well, because it's fast for one thing.
Life is about tradeoffs. One of the biggest things you give away trying to create a virutal server is speed. Xen's advantage is that it is more efficient.
Suppose I want to run a name server and a database server, and I only have one physical box to do it on. In a sense, running them on the same machine introduces a kind of coupling. If BIND turns out to have a remote root vulnerability, my database is toast. I'd consider running under vmware, but the performance hit is big enough that I'd probably decide to live with the potential problem.
I can imagine in the future a distro in which a separate virtual machines is used when the user decides to browse the internet or read email, provided the overhead was small. When his browser machine is rooted by spyware, they can enjoy looking at his bookmarks, because that's all they're getting. If the user screws up and installs a trojan popup extension, he can throw the entire virtual machine away and get a new one off the shelf.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
> Well, why would you want power management on a virtual machine? the host machine should manage the power...
Never used Xen, have you? You have to run a Xen-patched kernel as the HOST system, and THAT is what doesn't
support power management. i.e. if you're running Xen, you cannot simultaneously use any power management features
of your hardware.
25% Funny, 25% Insightful, 25% Informative, 25% Troll
They're completely different technologies. Short summary: Xen is para-virtualisation, Zones are a kernel abstraction.
With Solaris zones there is a single kernel. The process structure has been extended with a zone ID, so the kernel knows which zone each process belongs to. Solaris boots normally and becomes the master. Then each slave zone boots inside the master. Zone filesystems are simply subdirectories of the real filesystem. Zones are extremely fast and efficient.
With Xen there are multiple kernels running in "domains". Xen boots first and then launches the kernels of each domain. The Xen VMM manages memory and CPU. Xen provides "virtual hardware" for network and disk but the driver is actually in domain 0. Each kernel has its own filesystem. Often those filesystem are provided by really big files residing on a real filesystem from domain 0, though you can also assign partitions or logical volumes to each domain.
One of the benefits of Xen's approach is that you can run different versions of the kernel and even completely different kernels (eg, BSD and Linux) side-by-side. With zones you are always running the same Solaris 10 kernel on all zones. However this means Xen isn't as efficient as zones due to wasted resources and hardware contention from multiple kernels. Xen requires extensive modifications to the boot sequence, modifications to the guest kernel, and changes in the way you maintain the server. Zones don't affect you until you need to use them, and when you go to use them you don't need to change the boot sequence or how you maintain the server. Because Xen sits on top of the hardware, you lose features like ACPI and APM until Xen has support for those features. Xen also makes debugging a kernel problem far more complicated.
I personally don't see the benefit of Xen over something like Plex86. Roughly speaking, Plex86 placed the VMM component of Xen inside the Linux kernel. So a standard Plex86/Linux kernel is both the Xen VMM and the domain 0 kernel. Though Xen and Plex86 don't share code; I'm just using those names to link the parallel concepts. This makes everything a lot simpler in Plex86; the host kernel has full hardware access and in most ways is completely normal. It's only guest kernels that need anything special. Xen has gone to a lot of trouble to keep the VMM separate from the kernel, but at the expense of adding considerable complexity.