In August, XenSource will release Xen 3.0, software for running multiple operating systems on a single server. The Register’s Ashlee Vance writes about big companies helping to make Xen a strong competitor with VMWare. New Xen features coming August and soon include better SMP support; x86 64-bit, Itanic, Power, and Intel VT CPU support; and Solaris and Windows support.
Xen growing up
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
it says july on the xen site, not august
c’mon, at least don’t use the Register/Inquirers nicknames for things…
/me can see “Apple go to Chipzilla” articles soon if this continues.
Hey guys. I work on Xen, so I’m biased
– therefore feel free to call me on any statements you want justification for.
The article doesn’t describe Xen’s SMP support very clearly, so to summarise:
* Xen itself has been SMP aware from the very start – version 3.0 adds the ability for the virtual machines to also be SMP (rather than spreading multiple uniprocessor guests across the available CPUs)
* Xen can still timeslice CPUs between multiple VMs, so you don’t *have* to statically assign sets of CPUs to domains (like in the example in the article)
* Virtual CPU hotplug is planned so that you can dynamically add and remove virtual CPUs to domains, according to needs.
Unisys have patched Xen to run on 32 way x86 boxes – those patches were relatively small and have been making their way into the mainline Xen codebase.
sound’s so good to be true
keep up the good work. I am looking forward to see the stable version (or patches?) for FreeBSD real soon.
Will it run on PowerPC chips as well so I could run powerpc Linux on my Mac?
Is it just me, or does “Xen” appear just a little too often as a name for some computer package? Is there a reason for this, besides sounding similar to Zen?
I remember reading about how Xen worked and it seemed very x86 specific back then. How is it possible all of a sudden that there are ports to other architectures? Is Xen a whole new architecture (like JVM maybe) or is it build on top of x86 arch?
So I’d need a new CPU for Windows support? Guess going with VMWare still is cheaper for me then… Damnit.
Xen uses a technique called “paravirtualisation” – this involves modifying the guest OS slightly to run on an architecture *similar to* the host machine but omitting the parts that are hard to virtualise. This technique is particularly important on x86 because it has so many features that are complex and inefficient to virtualise.
Since the original port, the project has gained *loads* of manpower from other groups. A port to x86_64 is under way – x86_64 differs from standard x86 sufficiently that a different approach is required. Intel have been contributing lots of help in this port.
Ports to PowerPC (IBM are helping with this) and IA-64 (HP are helping with this, SGI appear to be interested) are also under way.
In each case, Xen is adapted to define a paravirtualised interface that’s suitable *for that host archictecture*. The interface is (necessarily) different on each architecture and so requires a different guest OS port (there is some code reuse, however), unlike higher level virtual machines (eg JVM) where the same code runs anywhere.
(nb. The PowerPC port provides the standard PowerPC hypervisor interface, as used by guests on IBM vHype / pSeries, so it’ll run existing kernels as guests just fine)
Yes, unfortunately.
You *Could* still run Windows under QEmu (http://www.qemu.org) but without the accelerator module that’d be pretty slow. Nobody has (yet) ported the accelerator module to run under Linux on Xen.
Right now Xen is quite server focused – the cost of a new processor is probably less than some of VMWare’s server products
However, for people who:
a) want to run relatively fast Windows virtual machines, right now
b) have reasons for not upgrading CPUs
It definitely makes sense to stick with VMWare for now.
Yes, it’ll run on PPC 970 chips, to start with. However, Apple disable the hypervisor extensions in their G5 chips, so porting Xen to run on Apple PPC chips will require additional effort. There was a plan to make this happen (although that was being talked about before the Apple -> Intel move – I haven’t checked with those developers to see if that’s – affected the plan).
The current release date is August – the Xen homepage is out of date in this respect.
Patches for FreeBSD 5.3 (and NetBSD 2.0, Plan9, Linux 2.4 and 2.6) are included with the Xen distribution so you can build a Xen-aware FreeBSD guest yourself. Only Linux and NetBSD-current are capable of running as domain 0 (the “host” OS) – the others must run as guests.
NetBSD have supported Xen in their mainline for a long time and they use Xen on their infrastructure machines. FreeBSD is going to merge Xen at some point. Linux 2.6 will merge Xen support into their mainline at some point soonish.
Regarding distro support, there was a Google Summer of Code bounty for making the FreeBSD installer run under Xen OK – I don’t know if anyone took it up. SuSE 9.3 and FC4 both prepackaged include RPMs of Xen.
I seem to remember that once x86 CPU’s with some special new feature hit the shops, one will be laso able to run unmodified version of windows. When these CPUs will be available/Xen will support this feature?
Would Longhorn be supported?
If I recall correctly, Loghorn is supposed to have “paravirtualisation” built into it too. I’m guessing that both Longhorn uses the same type of Pacifica/Vanderpool technology to do it’s thing. If that’s the case, then the only way I see Xen (under Linux) running Longhorn is if Pacifica/Vanderpool supported nested “paravirtualisation”.
I hope that’s not the case.
The Intel “VT” chips will be available later this year and (I believe) are plug compatible with current chips, so you can just do a drop-in upgrade. The desktop chips will be the first to support it – Xeons will get it later.
AMD “Pacifica” chips will be available some time next year.
Supporting unmodified Windows under Xen is harder than supporting unmodified Linux, so it might take a bit longer to get it working – it is planned as an important feature, however.
> Would Longhorn be supported?
Yes, eventually.
> If I recall correctly, Loghorn is supposed to have
> “paravirtualisation” built into it too. I’m guessing
> that both Longhorn uses the same type of
> Pacifica/Vanderpool technology to do it’s thing.
Where Xen uses paravirtualisation to provide high performance virtualisation on x86 without hardware support, Longhorn’s proposed hypervisor will require this hardware support in any case (paravirtualisation is just an optimisation). It’s not such a limitation though – when Longhorn hypervisor appears, such hardware should be common.
> If
> that’s the case, then the only way I see Xen (under
> Linux) running Longhorn is if Pacifica/Vanderpool
> supported nested “paravirtualisation”.
It’s not clear what form the Longhorn hypervisor will take. I imagine it’ll be preferable to run separate Longhorn instances in Xen domains, rather than nesting hypervisors (although I imagine support for the latter could be implemented, I doubt it’ll be a priority unless it’s essential for users).
An interesting hack would be to support Longhorn’s hypercall / device APIs in Xen to take advantage of the optimisations it offers on the MS hypervisor – this is particularly interesting for optimising MMU operations.
Thanks for the info, then I’ll guess I’ll wait with the upgrade from my AXP 1700+ (does everything what I want…except beeing able to use without problems few win apps that won’t run under wine) until Pacifica will show up (as I understand from googling, it will be included at launch in the whole line of AMD CPUs, is that correct?)
I’m not sure how AMD are planning to release Pacifica other than that it’s definitely a “next year” thing. They’re going to contribute support code to Xen at some point, presumably before then.
One thing that’s worth noting is that you won’t want to run graphics intensive apps under Xen yet: in particular 3D apps are a problem because there is not a “virtual 3D card” (yet). This’ll probably get looked at eventually but it’s not a high priority.
In the meantime, you should play with QEmu – it’s really quite impressive. It’ll run some versions of Windows fine, although there are still some “quirks” AFAIK.
Ah, so as I understand Xen makes the real video hardware “invisible” to OSes? What about 2D & video acceleration, is it disabled also, like 3D? (of which I don’t care much – I have old matrox G400). What about soundcards?
Right now, Xen doesn’t give virtual display or sound devices (*unless* you’re running on an Intel VT box, which you can’t buy yet). The best way to get these features is to use standard network-based remote display and sound: X, VNC, (Free)NX, remote ESoundD, remote artsd, etc. This isn’t too bad performance-wise because the intra-machine network is rather fast.
In the future, a virtual framebuffer will probably be added to do 2D graphics – eventually, we might see a virtual 3D accelerated graphics device but that’s some way off.
Other possible solutions for graphics:
a) full screen graphics control by virtual machines, using some “hot key” combinations to switch between them.
b) give each virtual machine control of a different graphics card and have multiple monitors (this is the closest to working right now – there are a few brave users trying to figure out what’s required here)
I’m actually working on a virtual sound device for fun at the moment, but it’ll be a while before it’s done. It *might* make it into Xen 3.0.
Note that dom0, the “host” can access sound and video, so the “network based” solutions I describe can be run completely within one machine.
Is anyone working on ACPI or FreeBSD host support? I’d love to be able to use this on my laptop…
ACPI support is in the unstable tree right now. Xen has been rearchitected so that the “domain 0” (“host”) virtual machine will initialise ACPI and then tell Xen about it: this means the ACPI code in Linux can be leveraged, rather than having to maintain an ACPI driver in Xen.
I don’t know of anyone adding host support for FreeBSD but NetBSD-current can run as host. That code should probably be leveraged in a FreeBSD host implementation. I imagine it may happen eventually.
Thanks Mark, the time you’ve spent giving answers is greatly appreciated.