Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Microsoft Corp. and XenSource Inc. today announced they will cooperate on the development of technology to provide interoperability between Xen(TM)-enabled Linux and the new Microsoft(R) Windows(R) hypervisor technology-based Windows Server(R) virtualization. With the resulting technology, the next version of Windows Server, code-named "Longhorn," will provide customers with a flexible and powerful virtualization solution across their hardware infrastructure and operating system environments for cost-saving consolidation of Windows, Linux and Xen-enabled Linux distributions."
Posted Jul 18, 2006 20:48 UTC (Tue)
by ahoogerhuis (guest, #4041)
[Link] (1 responses)
-A :)
Posted Jul 19, 2006 5:18 UTC (Wed)
by drag (guest, #31333)
[Link]
I beleive they had a version of XP that would run on it and everything.
Of course I can't help but feel that this is a attempt to diminish Vmware's lead.
Then again I like it because of two reasons:
Posted Jul 18, 2006 21:26 UTC (Tue)
by einstein (subscriber, #2052)
[Link] (7 responses)
Posted Jul 19, 2006 13:35 UTC (Wed)
by mepr (guest, #4819)
[Link] (6 responses)
The caveat is that the article says MS will run under "XenEnterprise". I wonder, does this mean that it will not run under the GPL version of Xen?
In regards to being a response to VMWare competition, MS is basically being forced to compete with them because of the new virtualization technology being built into the new intel processors and in the next generation AMD processors. VMWare has already released product versions that use VT-E, and it is good enough that quite a number of large businesses are already most of their servers virtualized. They have to respond.
Mark
Posted Jul 19, 2006 19:23 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
The only way that it wouldn't work is if Microsoft designed it specificly not to by invocing some of that TPM based stuff and set it up so the kernel would refuse to run in a VM.
So it has to be something about driver standards or more then likely management applications. Like you need tools to help you invoke new environements, manage ram, migrate operating systems between machines and the like.
Posted Jul 20, 2006 7:58 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (4 responses)
I thought Xen was the one that needed a Xen-aware OS in order to run. VMWare provides a complete virtual box for a guest OS. Win4Lin provided a sandbox but ran a lot of Windows on "the bare metal". I thought Xen was like Win4Lin, but because NT-based stuff expects to control the bare metal it doesn't work with Win4Lin. So in order to use a Win4Lin approach, don't you need a Xen-aware guest OS?
Cheers,
Posted Jul 20, 2006 8:56 UTC (Thu)
by copsewood (subscriber, #199)
[Link] (3 responses)
Posted Jul 20, 2006 11:37 UTC (Thu)
by drag (guest, #31333)
[Link] (2 responses)
The whole point of Xen's 'paravirtualization' was that there was a certain class of x86 instructions that couldn't be virtualized. With Vmware the work around was complex software emulation of those instructions. With Xen you modified the kernel to assist in working around the problem.
So that with Vmware you had higher compatability, but lower speed. With Xen you had higher speed, but lower compatability.
With the newer chips they modified how the proccessor worked to make these things easier to abstract. Xen should be able to run any operating system with no software emulation and with no paravirtualization, although I think that operating systems will still benifit from being ported for other reasons.
As a side effect this made it possible for a whole new set of operating system exploits. Now with new hardware it is possible 'lift' the OS onto a hypervisor like Xen with complete transparency. (keep in mind that Xen loads first, that Linux runs on top of Xen and other systems run on top of Xen/Linux combo)
With these new VT/Pacifica stuff is now possible to get 100% compatability in a VM with only a 5% or so drop in performance. A admin isn't going to notice this.
So if you build hypervisor capability into a rootkit a attacker now can get UNDERNEATH then the kernel. Even through reboots it's possible to keep bootable cdroms 'lifted'. It opens you up for the perfect rootkit. There are already proof of concepts aviable. There was even a researcher who accidently infected himself with a rootkit and didn't even notice it.
But that's were TPM (trust platform modules) come in....
Back in the day when Vista was still Longhorn Microsoft initiated it's "Palladium" program. The idea that was you had a 'protected' environment in which programs could run outside user's control. This made it more secure, both ways. Badly behaved programs couldn't break out and infect your computer and users couldn't break in and reverse engineer DRM.
So how to acheive this Microsoft wanted to run a sort of mini-OS to run a virtualized environment.
But you can't virtualize x86 easily and get binary compatability, remember? So that instead of taking the Vmware route and implimenting expensive partial software emulation or of going Xen route and modifying how programs worked they decided to go the Microsoft route:
Have Intel and AMD change how their proccessors worked.
Life is good for the 36billion pound gorrilla, eh? So that took care of the first half; the VM environment. Intel and AMD scrambled to create VT and Pacifica and integrate it into their chips.
(CPU makers design chips at least 2 generations into the future. The newest stuff is just in design state.. the next generation is having it's production stuff being designed and tested, and the 2 generation old is what they are selling. Or something like that... Just remember that it takes a very long time to get new cpu desines out.)
The second half of the Palladium "final solution" was to impliment a way to prove that this protected environment was untampered with. Time to protect the VM from molestation.
So the solution to the 2nd problem was TPM. TPM on your motherboard stores checksum hashes to create a 'trusted path'. The motherboard/cpu would then refuse to run modified versions of this palladium protected environment.
For instance in Linux supported TPM since 2.6.12, I beleive. And there is a 'trusted grub' version. So the path of trust goes like this:
Bios initializes. Begins to boot up. The TPM takes over somehows.. It has in it's memory a checksum of your grub bootloader.
So that way you have a 'trusted' environment.
Well eventually Palladium died on the longhorn feature chopblock. Intel and AMD were looking for places to use it's new VT and Pacificia stuff in. It was going to be in their future cpus which they already tested and designed and were in the proccess of creating the production plants for...
And standing there was little ol' Xen Source with it's paravirtualization that could only work on 2 operating systems, but was very fast. (FreeBSD and Linux are the two)
So now Intel and AMD worked with Xen to make their hypervisor support the new features. Eventually as new hardware gets here Xen will be able to support operating systems without modifications. You need support in your motherboard and support in your CPU.
If your motherboard claims to support the 9xx series Pentium-D then more then likely it will support VT. I don't know about AMD though.
Also Vmware benifits from VT/Pacificia; this will allow for a much faster VM for them, also.
And TPM will be used to ensure that Linux and friends aren't running in a hostile VM. It's specificly designed to be very difficult to virtualize.
Of course Microsoft now realised that 'Hey virtualization is the next big thing from last year' and is going to have their own hypervisor due out sometime after 'Longhorn server' comes out. They're current Virtual Server product is laughable compared to the sort of enterprise stuff Vmware has and it's performance sucks compared to Xen/Linux. (which is probably why MS has stopped bothering trying to sell it and give away free now)
Of course it's Microsoft's 'Virtual Server' and it has a huge advantage simply because it is from Microsoft. Most of the administrators that use it are completely unaware of Vmware's products beyond their Workstation stuff and Xen/Linux might as well be from another planet.
Please note that lots of the stuff I said are probably misleading or just wrong. I am NO expert on the subject and am just relaying what I've read elsewere.
Posted Jul 20, 2006 13:07 UTC (Thu)
by thompsot (guest, #12368)
[Link] (1 responses)
Posted Jul 20, 2006 13:09 UTC (Thu)
by thompsot (guest, #12368)
[Link]
Posted Jul 19, 2006 8:34 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Jul 19, 2006 13:24 UTC (Wed)
by mepr (guest, #4819)
[Link]
Mark
Posted Jul 19, 2006 9:28 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
I hope this doesn't happen to XenSource (although, of course, if it does the code is free and the developers will go wherever suits them best, which won't be MS if they treat the devs evilly).
Posted Jul 19, 2006 10:28 UTC (Wed)
by Los__D (guest, #15263)
[Link]
(Just always keep ready to dodge a chair or two! ;))
Posted Jul 19, 2006 21:12 UTC (Wed)
by thomask (guest, #17985)
[Link]
(apologies for being completely off-topic)
Posted Jul 23, 2006 23:59 UTC (Sun)
by nlucas (guest, #33793)
[Link]
What the announcement says is that Xen *guest* OS's will work with the Microsoft hypervisor, not the the other way around. I would not be surprised if they have some agreement with VMWare for the same thing (or even if the VMWare try to have a common hypervisor API wasn't under the Microsoft directions, though that is going into conspiracy theories).
I believe that what they want is to have control on everything running on the machine (meaning they can enforce DRM - included on Vista), while at the same time "dogding" from acusations of not allowing the user to install what they want on the PC.
If someone says they don't allow users to install Linux or other OS on the same PC, they just say that isn't true, because they can run it under the hypervisor. And all in name of user "John Doe" security, because of the "bad" guys who write malware (and hypervisor based rootkits).
Now all they need for (even more) world domination is for BIOS manufacturers to include the Microsoft Hypervisor on the chip...
Not that I've read all the details, but doesn't this sound awfully close to "we need to buy something to fill a huge gap in our lineup"?Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Originally Microsoft supported Xen in it's early days. But dropped out.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
A. It'll make it easier to migrate away from Windows for more people that would like to do so.
B. Hopefully hardware manufacturers realise that with Xen around they can support both Windows and Linux servers by simply making Linux drivers and not bothering with the Windows stuff. :-P
um, running all my linux services as virtuals on a windoze peecee is probably the last thing I would *ever* want to do...Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
The article says that the idea is compatibility. Longhorn will run under xen, and xen hosts will run under longhorn. This actually sounds like an article that was written here a little while ago stating that the various linux-based vm groups were trying to standardize on a virtualization api. VMWare had proposed one, and other groups were variously thrilled or unhappy with it. Some other groups had proposed their own API. It is possible that microsoft is going to conform to the xen standard. In that case, this can be interpreted as a very shrewd move. Defacto standards are the source of a great many "standards". Teaming with MS probably wont hurt the API's chances.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Well Longhorn will run under Xen pretty much irregardless of weither Microsoft likes it or not. Same thing with XP, W2k, Win98, and pretty much any other x86 operating system.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Are you sure?Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Wol
I think this is right in connection with older Intel and AMD hardware, in the sense that guest OSs need to be ported to Xen. My understanding is that with the new Pacifica and Vanderpool virtualisation support in (some) Intel and AMD products it will (has?) become possible to run unmodified guest OSs under Xen. It will become possible to use an unmodified Linux as a Xen host OS when relevant patches can become part of the mainstream kernel.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Ya. With newer hardware it will be possible to run unmodified systems on Xen.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
The grub bootloader is tested to make sure that it's unmolested. If it's fine then it boots.
Trusted grub maintains it's own set of checksums for the kernel and initrd. It tests the kernel and boots up.
The kernel and initrd holds checksums of important system files and checks those a it boots up... etc etc etc all through the boot proccess more and more stuff is tested and verified. All of this is with assistance with the TPM and your CPU. If a 'trusted' binary has been modified in anyway then it will not be executed.
Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Of course Microsoft now realised that 'Hey virtualization is the next big thing from last year'
LOL
Of course it's Microsoft's 'Virtual Server' and it has a huge advantage simply because it is from Microsoft. Most of the administrators that use it are completely unaware of Vmware's products beyond their Workstation stuff and Xen/Linux might as well be from another planet.
I'm experiencing this EXACT thing where I work... If I pitch the advantages of VMware, I'm told that the MS virtual server is free and supported already, plus the Windows admins already implemented it. If I pitch the advantages of Xen, everyone silently stares at me as if trying to figure out what strange language I'm speaking, then someone shrugs and changes the subject.
Coming from a multi-architecture and platform background (RISC/x86/MIPS - NetWare/Windows/Linux/Windows) and working in a single architecture and platform environment (x86 - Windows) is a strange, "upside-down totem pole" experience to be sure.
Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
OOps... I meant, "Netware/Windows/Linux/Unix". The horror...
Interesting - is this a case of "if you can't beat them, join them"? Or Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
is Microsoft switching to trying to promote Linux and Windows as
complimentary, not alternatives?
This is standard behavior. When a particular technology is threatening enough to the business model, they have been known to interop pretty well, then shove off when they can. For example, novell.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
It's notable how many Microsoft 'partners' shortly get bought by them.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
Now, I'm not at all sure about this, but I've heard/read somewhere, that MS should be a very nice place to work.Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization
I sometimes wonder whether the high volumes of (TM)'s and (R)'s in Microsoft's press releases, packaging and general output is simply a way of saying "we got the best damn lawyers in the land - you really don't wanna mess with us, buddy"...bravado?
I believe most missed the real point (although some were around it).Microsoft and XenSource to Develop Interoperability for Windows Server Virtualization