Q: does it run on Xen? A: Not yet but it will
on
OpenSolaris Code Released
·
· Score: 4, Informative
Some Sun guys are doing a port to Xen. This'll give you near-native performance for Solaris apps, along with the comprehensive device support provided by a Linux (or NetBSD) "domain 0" (host virtual machine).
I love how this comment got modded as funny because it sounds like an "adjusts tinfoil hat" type comment - the best bit is that this is actually serious. After all, it's not paranoia when they are out to get you:-)
Ah sorry - I can see the funny side, though. My experience of civil-servants has not been entirely encouraging (yesterday the tax office decided I was two people, today I'm only one):-) The scary thing is that the NSA are also civil servants...
IMO low-level classified information would be perfectly reasonable to keep on internet-reachable computer systems, as long as sensible security precautions are used.
In the US classification system, I'd hope that anything above Confidential would be air-gapped unless there was a good reason for it not to be (and appropriate precautions taken).
When I say "really sensitive" I mean classified information - the really juicy stuff will only be *accessible* to people who know how to handle it. Not your common or garden feds;-) - they surely won't even see it, let alone be allowed to stick it in vulnerable places.
Think about it: as you say, people break into *internet-connected* federal networks all the time. How much highly classified information has been recovered from those networks as a result of a busy hacker?
Sure - I'm not saying they don't use networks of computers.
I'm just suggesting they won't connect sensitive networks with classified data on them to the internet. With a decent sized internal network, it'd be perfectly feasible to have the only transfers between it and the outside world take place using CD-Rs - either for software installation, or for data transfer.
For most operations (e.g. working on secret weapons plans;-) their internal network would be enough to co-operate between team members, access specs for their hardware, run simulations on their supercomputers, etc. Needing to access the real internet would be the exception, rather than the rule.
Unless the Pentagon and NASA have VERY VERY silly systems, their *really* important computers are simply *not* accessible to hackers. I really can't believe that truly ensitive systems wouldn't just be air-gapped from the world.
Sure, it's possible to hack intelligence agencies but it I'd put money on it failing to get you the really juicy stuff!
> Did it ever occur to anyone that I might want to get an emulator/hypervisor to run Windows
Sure, the thought occurred and it's a really nice thing to have. It's just not what Xen is for.
I always tell people who want to run Windows in a virtual machine on vanilla x86 - and do so with high perfomance - just buy VMWare. If you really want a free VM system then try out http://www.qemu.org/. It's very impressive, just not as fast.
> No matter how you slice it Xen's "paravirtualization", if such a term even existed prior to Xen, only does half the job.
(aside: the term was used by the Denali VMM. It may have also been used by IBM for their hypervisors - it certainly has been used by them since)
It does a different job, that's all: the job is to run high performance full-featured virtual machines on vanilla x86 hardware. It's not for running Windows on Linux.
The team are aware that Windows support is important in the enterprise, which is why on machines with hw assist (which the MS hypervisor will require anyhow), Xen will do full virtualisation. AMD and Intel are writing the code for this themselves.
On machines without hw assist, you gotta buy VMWare or use QEmu. It's not ideal, it's just the practical route forward.
Minor correction: the MS hypervisor will require hardware support and won't work on vanilla x86 as Xen will. This is not so silly of MS: hardware support should be widely availably by 2007.
Ah, replying to myself again: MS will require hardware support for their hypervisor. With Xen and VMWare you don't need this. With Xen, you'll need it to run unmodified OSes but not ported OSes like Linux, BSD, etc.
An important thing to remember: * require an OS to be ported to the hypervisor interface doesn't imply you trust it to behave. Like a misbehaving process, an OS that doesn't play nice with the hypervisor / other OSes will get killed. * a paravirtualised hypervisor without binary rewriting can be smaller and thus (theoretically) easier to security audit
BUT: the MS and Xen approach of running device drivers in a virtual machine increases the trusted computing base to "host" Linux + Xen itself (or MS hypervisor + minimal Longhorn). In return you get huge flexibility and platform support benefits.
The XenSE subproject is looking at minimising the TCB by breaking stuff out into "driver domains" which are already supported. Intel's LaGrande (which isn't just for DRM!!!) security extensions will be leveraged to support this.
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.
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.
Seriously, though, using binary scanning and rewriting like VMWare is *very* complicated to implement. It's a very clever technique and a fantastic achievement of the VMWare guys that it works this well. However, it also incurs extra overhead that isn't needed if the OS is hypervisor-aware.
The benefits of paravirtualisation are twofold, as you say: * improves performance: all reasonably mature virtualisation systems are about the same for userspace compute-intensive code - it's IO and kernel-intensive code where this really gets big wins * makes the hypervisor simpler: this is a big plus for obvious reasons, the side effect being that (until HW support from Intel and AMD is available) you have to port things
Trying to compete with VMWare on a drop-in replacement basis wouldn't work: it's too hard. This approach makes it both feasible to implement a new hypervisor from scratch *and* lead the market in performance.
The burden isn't entirely on you to find a port of your OS - all that needs modifying is the kernel and the Xen distribution supplies that (For Linux 2.4, Linux 2.6, FreeBSD 5.3, NetBSD 2.0 and Plan 9). Userspace will work as-is (so amongst other things, you can trivially dual boot Xen / non Xen on the same install).
That said, things will be more convenient for deployment once Xen has: a) been merged into the 2.6 mainline (APKM says this will happen soonish) b) got mature support in distros (SuSE are starting to ship Xen in 9.3, RedHat will ship in FC4, Debian Experimental has packages). Convenience needs to improve wrt installation of fresh virtual machines, however.
Using Intel Vanderpool / AMD Pacifica CPUs, Xen will be able to run unmodified Windows. Until then, people who want to do that will want to buy VMWare;-)
Interesting, the MS hypervisor design allows guest OSes an API they can use to get better performance if they're hypervisor-aware - similar to Xen and IBM's POWER hypervisor.
This is pretty neat. The specs are supposed to be open, so it might be possible to get Linux to use them, or conversely, to get Xen to support them for running Longhorn...
Time will tell how this all pans out. The competition will result in VMM technology really accelerating, which will (in the end) give all sorts of benefits to end users.
Oh, and there are quite a few similarities with the MS hypervisor: * drivers run in a guest OS, not in the VMM itself * guests can be ported to the VMM the achieve better performance (yes, MS are doing it. They call it "enlightenments". Hmmm. Doesn't Zen have something to do with enlightenment?) * special VMM virtual devices for better performance
These characteristics are also shared by IBM's POWER hypervisor on pSeries.
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;-)
Windows on Xen will come along when Intel Vanderpool CPUs (later this year) and AMD Pacifica (next year) are available.
Code for using Vanderpool extensions is in the Xen tree right now, contributed mostly by Intel. It's not quite ready to run Windows yet (various 16 bit functionality still needs to be implemented) but it's getting there.
It's not out of date - Xen 1.0 supported an in-house Windows port but that will never be redistributed. With upcoming hardware hypervisor support from Intel and AMD it will nolonger be essential to port OSes, at which point Windows will run (with decent performance).
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.
This whole mess started when Zack Rusin blogged saying (basically) - * don't keep bugging us about when Konqueror will do what Safari does because it's not as simple as taking Apple's patches and applying them * don't keep saying how great it is that Apple are giving us these features
He explicitly said that it was fine for Apple to behave as they were. He just asked that people didn't keep giving Apple credit for doing things that actually needed to be done independently by the KHTML team.
The mess started when multiple news websites and bloggers misreported this as an anti-Apple flame and subsequently seemed to base their articles on each others, not the original post.
Agreed, it'd be a shame to lose them. That said, although the loss of Apple is a PR blow I doubt it counts much financially. Regarding selling the PC dept, I suspect it just suited their business model better. So they're still looking healthy for now:-)
Slashdot Mirror
Some Sun guys are doing a port to Xen. This'll give you near-native performance for Solaris apps, along with the comprehensive device support provided by a Linux (or NetBSD) "domain 0" (host virtual machine).
_ xen_summit (it seems to be down right now).
See http://blogs.sun.com/roller/page/tpm/20050510#the
Funny, I generally take it as a good point that other people can't use my keyboard! I also put the mouse on the floor and use it with my foot.
I love how this comment got modded as funny because it sounds like an "adjusts tinfoil hat" type comment - the best bit is that this is actually serious. After all, it's not paranoia when they are out to get you :-)
Ah sorry - I can see the funny side, though. My experience of civil-servants has not been entirely encouraging (yesterday the tax office decided I was two people, today I'm only one) :-) The scary thing is that the NSA are also civil servants...
IMO low-level classified information would be perfectly reasonable to keep on internet-reachable computer systems, as long as sensible security precautions are used.
In the US classification system, I'd hope that anything above Confidential would be air-gapped unless there was a good reason for it not to be (and appropriate precautions taken).
When I say "really sensitive" I mean classified information - the really juicy stuff will only be *accessible* to people who know how to handle it. Not your common or garden feds ;-) - they surely won't even see it, let alone be allowed to stick it in vulnerable places.
Think about it: as you say, people break into *internet-connected* federal networks all the time. How much highly classified information has been recovered from those networks as a result of a busy hacker?
Sure - I'm not saying they don't use networks of computers.
;-) their internal network would be enough to co-operate between team members, access specs for their hardware, run simulations on their supercomputers, etc. Needing to access the real internet would be the exception, rather than the rule.
I'm just suggesting they won't connect sensitive networks with classified data on them to the internet. With a decent sized internal network, it'd be perfectly feasible to have the only transfers between it and the outside world take place using CD-Rs - either for software installation, or for data transfer.
For most operations (e.g. working on secret weapons plans
Unless the Pentagon and NASA have VERY VERY silly systems, their *really* important computers are simply *not* accessible to hackers. I really can't believe that truly ensitive systems wouldn't just be air-gapped from the world.
Sure, it's possible to hack intelligence agencies but it I'd put money on it failing to get you the really juicy stuff!
Feel free to post more questions. I can't guarantee but I'll try and get round to answering.
Cheers,
Mark
> Did it ever occur to anyone that I might want to get an emulator/hypervisor to run Windows
Sure, the thought occurred and it's a really nice thing to have. It's just not what Xen is for.
I always tell people who want to run Windows in a virtual machine on vanilla x86 - and do so with high perfomance - just buy VMWare. If you really want a free VM system then try out http://www.qemu.org/. It's very impressive, just not as fast.
> No matter how you slice it Xen's "paravirtualization", if such a term even existed prior to Xen, only does half the job.
(aside: the term was used by the Denali VMM. It may have also been used by IBM for their hypervisors - it certainly has been used by them since)
It does a different job, that's all: the job is to run high performance full-featured virtual machines on vanilla x86 hardware. It's not for running Windows on Linux.
The team are aware that Windows support is important in the enterprise, which is why on machines with hw assist (which the MS hypervisor will require anyhow), Xen will do full virtualisation. AMD and Intel are writing the code for this themselves.
On machines without hw assist, you gotta buy VMWare or use QEmu. It's not ideal, it's just the practical route forward.
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.
Minor correction: the MS hypervisor will require hardware support and won't work on vanilla x86 as Xen will. This is not so silly of MS: hardware support should be widely availably by 2007.
Ah, replying to myself again: MS will require hardware support for their hypervisor. With Xen and VMWare you don't need this. With Xen, you'll need it to run unmodified OSes but not ported OSes like Linux, BSD, etc.
:-)
I just learnt this
Oh, I forgot your security question ;-)
An important thing to remember:
* require an OS to be ported to the hypervisor interface doesn't imply you trust it to behave. Like a misbehaving process, an OS that doesn't play nice with the hypervisor / other OSes will get killed.
* a paravirtualised hypervisor without binary rewriting can be smaller and thus (theoretically) easier to security audit
BUT:
the MS and Xen approach of running device drivers in a virtual machine increases the trusted computing base to "host" Linux + Xen itself (or MS hypervisor + minimal Longhorn). In return you get huge flexibility and platform support benefits.
The XenSE subproject is looking at minimising the TCB by breaking stuff out into "driver domains" which are already supported. Intel's LaGrande (which isn't just for DRM!!!) security extensions will be leveraged to support this.
HTH,
Mark
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
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
Sometimes copping out of things is good ;-)
Seriously, though, using binary scanning and rewriting like VMWare is *very* complicated to implement. It's a very clever technique and a fantastic achievement of the VMWare guys that it works this well. However, it also incurs extra overhead that isn't needed if the OS is hypervisor-aware.
The benefits of paravirtualisation are twofold, as you say:
* improves performance: all reasonably mature virtualisation systems are about the same for userspace compute-intensive code - it's IO and kernel-intensive code where this really gets big wins
* makes the hypervisor simpler: this is a big plus for obvious reasons, the side effect being that (until HW support from Intel and AMD is available) you have to port things
Trying to compete with VMWare on a drop-in replacement basis wouldn't work: it's too hard. This approach makes it both feasible to implement a new hypervisor from scratch *and* lead the market in performance.
The burden isn't entirely on you to find a port of your OS - all that needs modifying is the kernel and the Xen distribution supplies that (For Linux 2.4, Linux 2.6, FreeBSD 5.3, NetBSD 2.0 and Plan 9). Userspace will work as-is (so amongst other things, you can trivially dual boot Xen / non Xen on the same install).
That said, things will be more convenient for deployment once Xen has:
a) been merged into the 2.6 mainline (APKM says this will happen soonish)
b) got mature support in distros (SuSE are starting to ship Xen in 9.3, RedHat will ship in FC4, Debian Experimental has packages). Convenience needs to improve wrt installation of fresh virtual machines, however.
Using Intel Vanderpool / AMD Pacifica CPUs, Xen will be able to run unmodified Windows. Until then, people who want to do that will want to buy VMWare ;-)
Interesting, the MS hypervisor design allows guest OSes an API they can use to get better performance if they're hypervisor-aware - similar to Xen and IBM's POWER hypervisor.
This is pretty neat. The specs are supposed to be open, so it might be possible to get Linux to use them, or conversely, to get Xen to support them for running Longhorn...
Time will tell how this all pans out. The competition will result in VMM technology really accelerating, which will (in the end) give all sorts of benefits to end users.
Oh, and there are quite a few similarities with the MS hypervisor:
* drivers run in a guest OS, not in the VMM itself
* guests can be ported to the VMM the achieve better performance (yes, MS are doing it. They call it "enlightenments". Hmmm. Doesn't Zen have something to do with enlightenment?)
* special VMM virtual devices for better performance
These characteristics are also shared by IBM's POWER hypervisor on pSeries.
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
Windows on Xen will come along when Intel Vanderpool CPUs (later this year) and AMD Pacifica (next year) are available.
Code for using Vanderpool extensions is in the Xen tree right now, contributed mostly by Intel. It's not quite ready to run Windows yet (various 16 bit functionality still needs to be implemented) but it's getting there.
It's not out of date - Xen 1.0 supported an in-house Windows port but that will never be redistributed. With upcoming hardware hypervisor support from Intel and AMD it will nolonger be essential to port OSes, at which point Windows will run (with decent performance).
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.
This whole mess started when Zack Rusin blogged saying (basically) -
* don't keep bugging us about when Konqueror will do what Safari does because it's not as simple as taking Apple's patches and applying them
* don't keep saying how great it is that Apple are giving us these features
He explicitly said that it was fine for Apple to behave as they were. He just asked that people didn't keep giving Apple credit for doing things that actually needed to be done independently by the KHTML team.
The mess started when multiple news websites and bloggers misreported this as an anti-Apple flame and subsequently seemed to base their articles on each others, not the original post.
Agreed, it'd be a shame to lose them. That said, although the loss of Apple is a PR blow I doubt it counts much financially. Regarding selling the PC dept, I suspect it just suited their business model better. So they're still looking healthy for now :-)