Xen as Host for Reactos?

[dnyberg]

I've been doing research toward my next uberpc, and have come to the tentative conclusion that a virtual machine hypervisor that could run multiple 32 bit XP's is about as close to ideal as possible: familiar UI, easy rollback if a guest os gets virused, mature software (process-aware) firewalls, 4 gb per app (just spawn one vm for a browser, one for a torrent client, etc), reduced suspicion of back doors people think are in vista-and-beyond, etc.

Ideally, it'd be even better to do that with reactos, once it's mature enough for the task, and it seems to be moving in that direction. (yay!) I tend to forget then remember reactos every few months, check in on it, see progress, repeat.

It occurs to me a worthy approach would be to adopt xen as the "official" hypervisor, as I read a lot of things here and there about limitations of virtualbox, qemu, even the commercial hypervisors. If I understand correctly what I'm reading eg here (http://wiki.xen.org/wiki/XenWindowsGplPv), the Xen folk have already done the work that would let us run xp, (and thus maybe reactos) with stable paravirtualized non-hardware-dependent block storage and network drivers. That would jump forward users' chances of running apps stably, and relieve some pressure on the devs in the driver area. Doing *that* would let them concentrate more on the kernel stuff if they wanted to, and also make it easier to say "It'll be done right, not Tuesday, since you already have something stable to use right now".

I'm not suggesting abandonment of Reactos On The Metal (ROM) in favor of Reactos Under Xen (RUX), but rather dual iso releases whenever a new build is rolled out. I'm not a windows developer, but it doesn't *seem* as if once those drivers were rolled into the reactos main trunk, it'd be much extra work to generate both flavors of iso, would it?

What do y'all think?

[erkinalp]

It occurs to me a worthy approach would be to adopt xen as the "official" hypervisor, as I read a lot of things here and there about limitations of virtualbox, qemu, even the commercial hypervisors. If I understand correctly what I'm reading eg here (http://wiki.xen.org/wiki/XenWindowsGplPv), the Xen folk have already done the work that would let us run xp, (and thus maybe reactos) with stable paravirtualized non-hardware-dependent block storage and network drivers. That would jump forward users' chances of running apps stably, and relieve some pressure on the devs in the driver area. Doing *that* would let them concentrate more on the kernel stuff if they wanted to, and also make it easier to say "It'll be done right, not Tuesday, since you already have something stable to use right now".I'm not suggesting abandonment of Reactos On The Metal (ROM) in favor of Reactos Under Xen (RUX), but rather dual iso releases whenever a new build is rolled out. I'm not a windows developer, but it doesn't *seem* as if once those drivers were rolled into the reactos main trunk, it'd be much extra work to generate both flavors of iso, would it?
What do y'all think?

Using a paravirtualizer such as XEN Hypervisor needs kernel modification. ReactOS kernel can freely be modified because it is free and open source software to make a paravirtualising Domain Zero(ROSDOMZERO.EXE) and Unprivileged Domain(ROSDOMONE.EXE). Despite their names, they will be actually NT-compatible OS kernels with paravirtualising support.

[milon]

If you're going that route, I suggest looking into Qubes if you haven't yet. That's its whole purpose, and IIRC, it's built on Xen. And they say it supports Windows-based VM's. You may be able to install ROS inside it as a guest OS. (If you try it, let us know how it goes!)

[erkinalp]

That's it's whole purpose, and IIRC, it's built on Xen.

Did you want to say "That's its whole purpose, and IIRC, it's build on Xen."?

[jihao1234567]

If I realized correctly, this document: http://qubes-os.org/trac/wiki/UserFaq#C ... ithoutVT-x indicates that in Qubes OS, the Windows-based AppVMs are based on hardware virtualization technology ( e.g. Intel's VT-x, AMD's AMD-V, etc. ) but not paravirtualization, so the Windows kernel could be used without modification - that means of course, the Xen could act as the Host for ReactOS, however you should has a PC which owns VT-x and VT-d.

[erkinalp]

Hardware Virtualisation restricts Xen to host-to-host-architecture virtualisation. Whereas using paravirtualisation, also using means of emulation, host-to-different-architecture virtualisation is also possible.(QEMU may be used for interarchitectural translation).

[PascalDragon]

You need to get your terms right. Paravirtualisation has nothing to do with emulation of a different ISA, but with adding new instructions to the same ISA which allows a improved communication between the guest and the host and thus results in better performance. Though paravirtualisation could be used on cross-ISA systems like QEMU it is usually not done, because ISA-emulation is costly anyway and the guest OS needs to be compiled with those new instructions.

Regards,
Sven

[erkinalp]

You need to get your terms right. Paravirtualisation has nothing to do with emulation of a different ISA, but with adding new instructions to the same ISA which allows a improved communication between the guest and the host and thus results in better performance. Though paravirtualisation could be used on cross-ISA systems like QEMU it is usually not done, because ISA-emulation is costly anyway and the guest OS needs to be compiled with those new instructions.

Regards,
Sven

Qubes uses QEMU-KVM and VNC protocol to present Unprivileged Domain's userland. By default four Xen userland domains are defined, each having specific settings for its purpose, plus Dom0 and Network Domain(Yes, a seperate VM concerns for networking). It is based based on Fedora. While supporting Windows based apps in R2, best performance is achieved through native Linux applications.

[PascalDragon]

Qubes uses QEMU-KVM and VNC protocol to present Unprivileged Domain's userland. By default four Xen userland domains are defined, each having specific settings for its purpose, plus Dom0 and Network Domain(Yes, a seperate VM concerns for networking). It is based based on Fedora. While supporting Windows based apps in R2, best performance is achieved through native Linux applications.

And what does that have to do with paravirtualisation? Right... nothing. Especially that QEMU-KVM is only suitable for systems of the same ISA. It does not improve performance of e.g. ARM systems on a e.g. x86 KVM-enabled host.

Regards,
Sven

[jihao1234567]

Qubes uses QEMU-KVM and VNC protocol to present Unprivileged Domain's userland. By default four Xen userland domains are defined, each having specific settings for its purpose, plus Dom0 and Network Domain(Yes, a seperate VM concerns for networking). It is based based on Fedora. While supporting Windows based apps in R2, best performance is achieved through native Linux applications.

And what does that have to do with paravirtualisation? Right... nothing. Especially that QEMU-KVM is only suitable for systems of the same ISA. It does not improve performance of e.g. ARM systems on a e.g. x86 KVM-enabled host.

Regards,
Sven

Indeed.