At the last USENIX VMware and XenSource finally agreed to work on a joint project for hypervisor standardization, coordinated by Rusty Russell, Linux kernel hacker working for IBM Linux Technology Center, and called paravirt-ops. But VMware doesn’t want to give up its own standardization implementation, VMI, and
today released by surprise a working version of its Player able to run para-virtualized Linux distributions over a VMI compliant engine.
VMware Player Now Runs Para-Virtualized Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
While reading through this short article I came across this line:
“At this point any other hypervisor deveveloped with[…]”
What in the world is “DeVEVEloped?” Spell-check anyone?
—–
In any case I am glad that VMware is taking steps in this direction as it opens a lot of ground. Good to see opensource and profit business finding common ground.
from the [kinda crappy] article it seems that vmware have released a preview of vmware player that can play xen virtual machines.
and they seem to have admitted that the paravirtualised method used by xen is faster than vmware’s hypervisor?
Hi, I work on Xen, but I’ll try not to be too biased 😉
VMware has their own paravirtualised interface, distinct from the Xen one. Both have some technical advantages over the other. The Player preview supports VMware’s interface – VMI. The kernel would be a special Linux/VMI kernel port. It does look like VMware want to offer paravirtualisation for increased performance where possible, but the player image is just a first step – AFAIK their major products don’t support VMI (yet – they obviously have in house code for this).
The paravirt-ops work that’s intended to go into the Linux kernel will provide a way for Linux to support both VMI, and the Xen interface.
Eventually it should be possible to run the same kernel on native hardware, or under full virtualisation, or under paravirtualisation on VMware (or another VMI-compliant hypervisor) or Xen (or another Xen interface compliant hypervisor).
Well, maybe you can elaborate on this topic for me a little more. I’m having trouble understanding this whole paravirtualization stuff, as well.
I’m familiar with the concept of running multiple OS’s on the same hardware at the same time. I get that. I use VMWare (to play with) and Microsoft’s VPC (mainly for taking classes at work). Some of the these terms like “paravirtualization”, “hypervisor” and “VMI” are confusing me, though.
The following excerpt from the article make very little sense to me, maybe you can explain:
“But while paravirt-ops specifications are in the work, VMware today released by surprise a working version of its Player able to run para-virtualized Linux distributions over a VMI compliant engine.”
[. . .]
“At this point any other hypervisor deveveloped with VMI specifications would be already able to run same Linux distributions without further intervention.”
Oh. BTW, what I would like to be able to do is to run Windows in virtual environment on top of a Linux host. I can do this with VMWare. Linux on top of Linux or Linux on top of Windows doesn’t mean much to me. So, I haven’t used xen, as I understand that running Windows on Linux is not possible, yet. Any eta on that?
Thanks.
I’ll speculate, but maybe it talks about using full virtualisation during installation and first runs, while later user can compile/update kernel with VMI patches and run with in paravirtualised mode?
Or just this guy figured it wrong from VMWare announcement.
One thing you need to know is that “paravirtualization” is different from the regular “virtualization” featured in existing versions of VMware and Virtual PC. The difference is that paravirtualization attempts to give guest operating systems equal access to the actual hardware, whereas traditional virtualization meant adding a layer of “fake” software-implemented hardware. The ability to share hardware capabilities instead of running everything in emulation was a breakthrough first achieved by Xen, and results in MUCH faster performance (near native, which just isn’t the case for the older solutions from MS and VMware). However, at first only Linux was supported as a host OS, because achieving paravirtualization requires a modified kernel, and while that’s easy to do on Linux it’s impossible with Windows because it’s closed-source.
Now, although Windows XP currently can’t be run on Linux via Xen, Microsoft has been working so that the next version of Windows will be able to, either initially or via a subsequent update. Likewise, MS is developing its own paravirtualization software (it calls it “hypervisor” technology) which will allow any Linux distro that supports Xen to also be able to run with Xen-like speeds on Windows. In order to achieve this inter-operability, MS made a deal to work with the Xen team.
The question is, where does this leave VMWare? VMware realized that its old solution would become irrelevant in the face of the faster performance that paravirtualization allows, so it too developed its own paravirtualization technology, which is supposed to eventually support Mac OS in addition to Linux and Windows. However, Xen’s software was already well-integrated with Linux and they had already gotten their virtual machine interface approved as a standard. VMware also submitted their interface (called VMI) as a standard but got turned down, so they got really upset, and the result is that now Xen and VMware are working together to create a standard interface that will allow either technology to be implemented with an equal amount of ease on Linux. Although this may seem superfluous when Xen had already created a good enough standard, it’s ultimately good that VMware is getting an equal opportunity, because it will spur competition and allow end-user companies to choose whichever solution works best with the OSes they have in mind.
So, now you hopefully have a better idea of what “paravirtualization” is and what the new sofware from Xen, VMware and MS will bring to the table.
P.S. Looking at the other response from Mark Williamson, it appears that the use of the term “paravirtualization” is not an accurate blanket term, since it only applies to older x86 chips, whereas “full virtualization” is possible with the newer chips (resulting in even better performance). So, I guess “hypervisor” is after all the best general term to use. Also, as he notes, it is actually possible to run Windows XP on Xen/Linux, but only if you have a very recent CPU from AMD or Intel.
(Please feel free to correct any errors or elaborate on any points that I may have missed.)
Edited 2006-09-18 10:42
This was very helpful and articulate.
I’m about to fall asleep here. So, my apologies if this is not coherent. But, let me see if I have this straight . . .
Regular virtualization like VPC and VMWare have been producing for years require no special hardware or kernel mod (I’m sure of that). Paravirtualization, as the term has been used recently, requires kernel modifications (like Xen and Parallels). Hypervisor requires kernel modifications and special hardware (who is making this). Does this sound about right?
And, where then would qemu fit into these?
If you want to run Windows on Linux, I suggest using Qemu with the qemu accelerator.
I’ve been using Qemu on FreeBSD for maybe a year now, and it works like a charm.
I’ll check it out. Actually, I looked at it a couple of years ago or so.
How does Qemu fit into this whole paravirtualization thing?
I believe Qemu is more of an emulator, with virtualization of the cpu being fairly recent (with the accelerator) and I doubt it does any paravirtualization.
> Well, maybe you can elaborate on this topic for me
> a little more. I’m having trouble understanding
> this whole paravirtualization stuff, as well.
Sure. There’s a lot of non-standardised terminolgy, which doesn’t help.
> I’m familiar with the concept of running multiple
> OS’s on the same hardware at the same time. I get
> that. I use VMWare (to play with) and Microsoft’s
> VPC (mainly for taking classes at work). Some of
> the these terms
> like “paravirtualization”, “hypervisor” and “VMI”
> are confusing me, though.
OK.
Virtual machine monitor (VMM) – the thing that provides the interface virtual machines run on top of
Full virtualization = the VMM provides an interface that looks just like real physical hardware, allowing it to run any OS that was written for that hardware
Paravirtualisation = the VMM provides a different interface to any real hardware (although it’s often similar). This interface is idealised, so that the VMM doesn’t have to be as complex, and to avoid features of the hardware that are hard / inefficient to emulate
Hypervisor = a VMM which runs on the bare metal, without a host operating system (e.g. Xen, VMware ESX), as opposed to a hosted VMM like VMware player, kQEmu, etc
> “But while paravirt-ops specifications are in the
> work, VMware today released by surprise a working
> version of its Player able to run para-virtualized
> Linux distributions over a VMI compliant engine.”
> [. . .]
> “At this point any other hypervisor deveveloped
> with VMI specifications would be already able to
> run same Linux distributions without further
> intervention.”
The hypervisor interface is like a system call interface. It is used by the virtual machines to talk explictly to the hypervisor (e.g. “I want to update this memory mapping”). VMware’s interface for achieving this communication is called VMI (Virtual Machine Interface, I think).
And VMI guest can run on any VMI virtual machine monitor and use the VMI to communicate. This enables the guest / VMM to use explicit calls to communicate (to a greater or lesser extent, depending on implementation) rather than trapping operations and emulating them.
Currently, only VMware support VMI (as far as I know). They apparently do have code that makes Xen support VMI too, meaning that VMI guests could run paravirtualised on both Xen and VMware. I don’t think the patches got updated for the latest Xen release. Presumably the paravirt-ops thing may supercede the effort.
Paravirt-ops is a bit of pipe-fitting between core Linux, and operations that *might* want to be paravirtualised. At boot time, Linux can select from a variety of implementations for these opertaions. E.g.:
* VMI (for running on VMware and other VMI compatible interfaces)
* Xen (using the Xen hypercall interface)
* The longhorn hypervisor (using the Xen hypercall interface)
* Native hardware (using “native” implementations of functinoality the hypervisor would provide)
* Full virtulations (using the “native” execution support and relying on emulation of the platform hardware in the hypervisor).
> Oh. BTW, what I would like to be able to do is to
> run Windows in virtual environment on top of a
> Linux host. I can do this with VMWare. Linux on top
> of Linux or Linux on top of Windows doesn’t mean
> much to me. So, I haven’t used xen, as I understand
> that running Windows on Linux is not possible, yet.
> Any eta on that?
You can do it if you have virtualisation-aware hardware – Intel calls it VT-x, AMD calls it SVM. Both manufacturers make chips which support this, but most of the installed base has not moved to them yet.
Support for full virtualisation in Xen is still quite new and there are plenty of rough edges that need smoothing off before it’ll be as nice as the paravirtualised guest support.
There’s also a plan to make Windows work on older hardware without the virtualisation extensions, but that’s a way off.
Thank you for going into to so much detail. That helps.
backdoc
Like Smitty said, Qemu is primarily an emulator, being able to emulate other cpu’s than the one it’s running on. In the case of emulating x86 on x86 the qemu accelerator turns it into virtualization.
The module has been around for a while, accelerating the user processes on the guest, but recently it has also been able to accelerate kernel processes making the guest run at near native speed.
It doesn’t do para, as it doesn’t modify the guest to make it aware it’s running in a VM.
Qemu uses emulation (actually, it Just In Time compiles the code in the virtual machine to run on the host – which allows it to transparently run code for other CPU architectures, with reasonable performance) or full virtualisation (with the kQemu or qvm86 modules).
There was a sort-of paravirtualised mode at one point – requiring the guest OS to be modified for increased performance – but I think Fabrice decided that was not the way he wanted to go, and I’m not sure if it’s still available.
Qemu is used within Xen to supply emulation of devices, chipset, etc.