Xen as Host for Reactos?
Moderator: Moderator Team
Xen as Host for Reactos?
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?
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?
Xen as Host for Reactos.
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.dnyberg wrote: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?
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
Re: Xen as Host for Reactos?
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!)
Last edited by milon on Thu Jun 20, 2013 2:15 pm, edited 1 time in total.
Re: Xen as Host for Reactos?
Did you want to say "That's its whole purpose, and IIRC, it's build on Xen."?milon wrote: That's it's whole purpose, and IIRC, it's built on Xen.
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-
- Posts: 31
- Joined: Wed Mar 18, 2009 7:53 am
Re: Xen as Host for Reactos?
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.
Xen as Host for Reactos.
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).
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-
- Posts: 123
- Joined: Wed Aug 04, 2010 7:34 pm
Re: Xen as Host for Reactos?
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
Regards,
Sven
Free Pascal compiler developer
Xen as Host for Reactos.
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 wrote: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
-uses Ubuntu+GNOME 3 GNU/Linux
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-likes Free (as in freedom) and Open Source Detergents
-favors open source of Windows 10 under GPL2
-
- Posts: 123
- Joined: Wed Aug 04, 2010 7:34 pm
Re: Xen as Host for Reactos.
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.erkinalp wrote: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.
Regards,
Sven
Free Pascal compiler developer
-
- Posts: 31
- Joined: Wed Mar 18, 2009 7:53 am
Re: Xen as Host for Reactos.
Indeed.PascalDragon wrote: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.erkinalp wrote: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.
Regards,
Sven
Who is online
Users browsing this forum: Semrush [Bot] and 15 guests