Submitted by “Today, we’re making the first source code of our OpenSolaris on Xen project available to the OpenSolaris developer community. There are many bugs still in waiting, many puzzles to be solved, many things left to do. Because we don’t believe the developer community only wants finished projects to test. We believe that some developers want to participate during the development process, and now this project can open its doors to that kind of participation. We wanted to start the conversation with working code. So we have a snapshot of our development tree for OpenSolaris on Xen, synced up with Nevada build 31. That code snapshot should be able to boot and run on all the hardware that build 31 can today, plus it can boot as a diskless unprivileged domain on Xen 3.0.”
Disclaimer: I work on Xen for XenSource (and for my own interest)
It’s good to see Sun are making good progress on this. NetBSD and FreeBSD are also making progress towards supporting Xen 3.0 as both dom0 and domU in their future releases. We should soon see most of the major open source OSes include support for running on Xen.
Since Xen’s core domU interfaces are now frozen (but extensible for new development), once the Solaris / Xen3 port is finished, Solaris should be able to run on new Xen releases for the forseeable future.
One neat thing Solaris domUs enables is running Solaris virtual machines on hardware that wouldn’t usually be supported (by leveraging Linux driver support). Conversely, it can be used to run Linux software in virtual machines alongside Solaris with minimal cost.
and when we have dom0 support in Solaris it allows Linux beneift (indirectly) from Solaris features such as ZFS 🙂
Now if we could just have MacOS X as a Xen dom0 on an Intel Mac I’d be such a happy bunny!
Good point about ZFS! My primary project is a filesystem virtualisation layer called XenFS, which will enable you to pass through a filesystem from dom0 to a domU with good performance – so one day, with a Solaris XenFS server, you could re-export a ZFS filesystem to Linux. It’s analogous to the virtual block and network devices we already have but at a much higher level.
Combined with the driver domains functionality, you could eventually have a ZFS driver domain, Linux device driver domains, and any dom0 OS you wanted (for instance). It’s less like choosing an OS and more of composing together OS features you want. Of course, too many layers will reduce performance eventually but multicore chips will mitigate this somewhat.
It seems to me that it’s technically possible to have Xen-unaware OSes running as domain 0. However, this would be a pain to implement and I can’t see it being done any time soon. Your MacOS X fantasy is more likely to be achieved by running a Linux dom0 to provide disk / network services but giving a MacOS X domU direct access to the graphics / sound hardware. This is certainly feasible. It’d be helpful to see a Darwin/Xen port, rather than having to use full virtualisation.
Also, to complete the fantasy, you’d want to use an Intel Mac with Intel’s VT enabled, so that you could run unmodified OSes too 😉 [I’m not sure what hte status of VT on the mac is at the moment!]
The reason for wanting MacOS X Intel as dom0 is because Apple has stated that they will not support running of MacOS X on anything but Apple hardware. I believe they will do quite a lot to enforce this – sure people will hack around it but thats not my interest. Getting Darwin/Xen up is one thing but it is quite a step away from having MacOS X up. For one thing Darwin still depends on PC BIOS but MacOS X Intel boots from EFI (without PC BIOS legacy support).
True. But it still *is* running on Apple hardware, even if it’s not dom0. I don’t know how they enforce booting only on Apple hardware but there is virtualised access to the TPM under Xen, if necessary, so there may be some way of legitimately proving to the MacOS that it really is running on the right hardware, instead of just hacking it to work.
It’ll be interesting to see what Apple do with their Darwin EFI code: it used to be possible to recompile Darwin from the Open Source components and use that to boot MacOS X on a Mac. If you could do that on x86 it’d make this whole process much simpler.
Re. porting or not, fully virtualising is a pain, and you’d want to avoid that – particularly if you want pretty graphics from your Mac. We don’t have code to pass a PCI device to a non-Xen aware guest, although I think VT has some provisions for doing so in principle.
Its exactly because I do want the pretty graphics etc from MacOS X that I want it to be dom0 rather than domU. For Solaris, *BSD, *Linux running in domU’s my graphics needs aren’t much above a terminal window and an email client.
It would be nice if MacOS X could be dom0 but as you said unmodified dom0 is really hard and I can’t see the motivation from Apple to do this given the agreements with Microsoft on Virtual PC. But I can wish, its my birthday soon 🙂
Cheers.
People have already experimented with passing through graphics devices to non-dom0 OS images, so it could happen sooner than you think. These experimenters just gave one graphics card to dom0, one to the domU.
If you don’t want two graphics cards, it’s not the end of the world. dom0 currently controls all the hardware, takes over the screen, etc, but that doesn’t always have to be true. If a Linux dom0 can be made to run “headless” (i.e. just give up control of the screen), then a MacOS domU can boot on top of it and control the screen itself. By giving appropriate access to the platform hardware, I’d imagine MacOS could be persuaded to boot like this. And it seems legal (or within the intent of the license, anyhow) since you’re still running on the Mac.
So I think it’s quite possible to do something like you describe, but it’s likely to be a while before it happens. Windows users will have a similar wish though, so there’s quite possibly motivation from that direction. It’s just not such a focus for Xen – yet – as running on servers.
Happy birthday!