Slashdot Mirror
Microsoft Plans Hypervisor for Longhorn
ninjee writes "Microsoft reiterated plans to launch its own Windows-based 'hypervisor' software for running multiple operating systems. Bob Muglia, senior vice president in the Windows Server Division, said on Tuesday that the software will be 'built directly in Windows and will allow companies to virtualize multiple operating systems.' "
From TFA:
Microsoft's rival in this area is shaping up to be Xen [...] Xen doesn't yet support Windows, however
AFAIK Xen actually does support Windows, and it's not exactly a rival because it was originally sponsored by Microsoft Research - here is a relevant link
Having said this, I'm still convinced that full virtualization is the wrong approach and the separation technologies such as Linux VServer, FreeBSD jails or Solaris Containers will ultimately kill hypervizors.
I'd suggest Xen is less competition to this new initiative and more a learning opportunity for all involved parties to determine ways to integrate virtualized operating systems.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
I belive Apple has stated that MacOS (on Intel) will not be allowed to run on any hardware other than their own. I suppose this will be achieved by a combination of hardware differences (theres much more to a computer than the CPU) and by software licensing (and enforcement).
First, it's not "Shut Do.."
Oh really?
Sigur RÃs: I didn't know that Heaven had a rock band.
VMWare creates a virtual machine for your OS to run in.
e rformance.html) describes this better than I could.
Advantage: provided it's simulation is good, everything that runs on the real hardware runs in the virtual machine
Disadvantage: that compatability comes at a significant runtime cost, which makes VMWare mainly used only for testing purposes, not for running multiple OSes for general work.
Hypervisors (like Xen) and what MS is claiming (I will believe this when we see it given the list of things they've dropped) use a technique called paravirtualisation to vastly reduce the speed problems. However, this requires support from the host OS. The Xen performance page (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/p
Beware the psychokinetic mimes!
Xen will support full virtualisation on machines with appropriate hardware support (Intel Vanderpool or AMD Pacifica). Paravirtualisation will likely still give better overall performance, than full virtualisation but the difference will be smaller than it is today.
I'm attached to the Xen project, so I have an obvious bias ;-)
;-)
Nevertheless:
* I'd consider Xen a true hypervisor because it runs on the "bare metal" and multiplexes multiple "supervisor" kernels on top of itself.
* It was *not* designed as a full virtualising hypervisor, however.
* Paravirtualising gives better performance than full virtualisation on x86 - however full virtualisation is still nice for running things like Windows.
* Full virtualisation will be available on Intel Vanderpool / AMD Pacifica machines. Before those are ubiquitous, if you want to run virtualised Windows with maximal performance, yes, you should run VMWare
"vmware does not emulate the cpu"
This is not strictly true. It runs most of the instruction set natively, but emulates those portions of it that must run in supervisor mode.
Unfortunately this is complicated by the fact that some of the x86 instructions cannot be easily detected at runtime. This is one of the ways Xen simplifies things, by basically removing those tricky instructions from the instruction set and executing them only in the hypervisor.
I wish that were true.
The current EU-Microsoft case is about Media Player and open interfaces, and merely requires Media Player to be optional. The Longhorn 'security' system is at a much lower layer than any media player and the interface *is* going to be open. The Longhorn DRM system will not be affected at all.
I've seen one or two interesting DRM-related rulings in individual countries, but I'm not aware of any that would rohibit Microsoft from deploying DRM-capable Longhorn as planned.
Particularly note that Microsoft does and will deny that the Longhorn 'security system' is DRM. They state that it is a generic 'security system' that just so happens to be useful if some other software contains DRM and chooses to make use of the Longhorn 'security system' as part of its DRM.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
That's basically what Xen and the MS hypervisor do (and the IBM POWER hypervisor on pSeries - that actually *is* in the firmware too).
Both Xen and the MS Hypervisor (why can't they give it a name I can use!??!?!?!) are to be a "thin" layer (Xen will likely be smaller, IMO, as it won't support full virtualisation without hardware support. They'll both be very lowlevel, anyhow) that just multiplexes low level resources: CPU, memory, interrupts...
However, that doesn't give you the complete virtualisation system: there is also a distinguished virtual machine that runs device drivers for your hardware. MS are talking about using a cut-down Longhorn. With Xen it's Linux or NetBSD. The advantage of this approach is that you instantly get support for basically all devices that OS supports.
Xen is able to run device drivers in their own virtual machines and can restart them (whilst they're in use) for purposes of upgrade, bugfixing, etc. This will be leveraged in the future, to disaggregate the "domain 0" master OS even further in order to reduce the Trusted Computing Base. This should have benefits for security and availability.
HTH,
Mark
http://download.microsoft.com/download/9/8/f/98f3f e47-dfc3-4e74-92a3-088782200fe7/TWAR05013_WinHEC05 .ppt
I'm a Xen dude but I'll try not to be biased ;-)
:-)
Xen: paravirtualisation - modify the architecture dependent code of an OS so that it's hypervisor-aware
Pros:
* near-native performance
* simpler hypervisor
Cons:
* need to be able to port OSes (i.e. can't run Windows)
- NB this will be solved on Intel Vanderpool / AMD Pacifica CPUs
* need to run a non-standard kernel
- NB Xen support is integrated into the NetBSD mainline already and will be in the Linux mainline soon(ish). At that point, the Xen-aware kernel will be standard
VMWare (and MS Hypervisor, assuming it supports full virtualisation): full virtualisation - fake out an x86 machine in its entirety
Pros:
* Run Windows
* No kernel patching needed
Cons:
* Peformance penalty for kernel-intensive and IO intensive workloads
- NB VMWare mitigates this somewhat using custom VMWare-aware drivers to improve IO performance
- NB The MS Hypervisor provides these virtual drivers AND explicit APIs like Xen, so ported OSes can avoid these penalties
* Hypervisor is more complex
- NB nothing you can do about this if you want to support unmodified OSes on vanilla x86(_64)
The Xen and MS Hypervisors both have better hardware support than VMWare ESX because they run standard drivers in a virtual machine, rather than supporting them in the hypervisor itself. Note that VMWare GSX and Workstation don't have this problem because they run inside a host OS.
HTH,
Mark
Try it on VMWare GSX or ESX server, not their workstation product. That's what GSX/ESX are built for.
Microsoft had had builds of Windows for the following platforms since the first NT beta:
-Alpha
-PPC
-MIPS
-x86
IA64 support started a *very* long time ago, and x86-64 basically took the shortest time (you only basically need to recompile using a good optimizer, and change some code to take advantage of some new features... the big problem is changing the ASM code in the kernel/hal, but there isn't much of that.
MIPS/Alpha/PPC support was officially cut during the Win2K beta, but Microsoft has been keeping private copies mostly because Cutler liked it that way, and also because it ensures what you're doing is still portable. In fact, the first version of NT that was booted and tested was not the i386 port, since MS wanted to make sure that the system was portable enough so that it would work on the least-targetted platform first (and boy it did).
MS does not however have a G5 build of Windows, since there are too many Big Endian issues and it isn't worth it for them anymore.
I just found out (http://download.microsoft.com/download/9/8/f/98f3 fe47-dfc3-4e74-92a3-088782200fe7/TWAR05013_WinHEC0 5.ppt) that the Windows hypervisor will require hardware support (Vanderpool or Pacifica).
Xen will also use this hardware support to fully virtualise but won't require it for ported OSes.
This makes the picture rather different to how I expected it to be.
WinFS wasn't cut from Longhorn, it was separated from it. Microsoft is making WinFS a seperate entity which will slip into Windows XP and Windows 2003 installations as well as Longhorn. As such, Longhorn doesn't need to wait for WinFS.
.NET/XML-based API for integrating custom data which is not file-system based. Microsoft has demonstrated Longhorn without WinFS, this is already in it.
That said, WinFS is likely not what you think it is. All of the metadata searching is indeed built into Longhorn, including virtual folders (folders which run queries, Mac OSX and BeOS have 'em) plus "stacks" which automatically group documents dynamically. The feature is fully implemented and is absolutely fast. What does WinFS add? A new database, which the old one will be migrated into, and a