This may seem kind of odd, but could be quite useful.

Setting up MT test envionments under VMWare is useful, but limited due to VMWare's limited networking capabilities, and it's inability to give (most) hardware access to VMs. Under Xen, VMs can directly access hardware, so even wireless setups could be "semi-simulated".

It would also be nice to have a decent virtual router, for all those virtual servers. :-)

--Eric

You do know that PCI Passthrough for Xen 3 has been removed right?

While it would be *nice* for a Dev network a port would introduce issues of bugs showing up in XEN and not in the real router and reverse.

Lets just keep it how it is, a PC router and nothing more

You do know that PCI Passthrough for Xen 3 has been removed right?

While it would be *nice* for a Dev network a port would introduce issues of bugs showing up in XEN and not in the real router and reverse.

Lets just keep it how it is, a PC router and nothing more

From what I understand, it has not been removed, but is disabled due to some problems, and will return at some point. I would guess that it will be available again, long before any sort of MT port could occur.

I think it would be *very nice* for a dev network, significantly less so for a production network (although not _completely_ useless). As for it exposing Xen and/or MT bugs, how is that a bad thing?

I agree that MT should remain a PC router (and not become a server, etc...). But, I don't agree that the PC should necessarily remain a physical box.

I suppose it's a semi-moot point anyway, since processors that can run a fake ring-0 are available from Intel now, and I suspect MT should run fine as is on such a system (I don't know if anyone has tried yet, though). Still, it would be nice to be able to run it on my existing hardware.

--Eric

I would like to see this simply for 1) redundancy and 2) scalability.
1) Migrating instances of RouterOS between physical boxes when you have to take one down for maintance as well as having one crash without affecting the other
2) Support SMP and >1GB RAM without having to add it to RouterOS (BTW if SMP is being added - I saw this mentioned but not confirmed - will we see the 1GB RAM limit removed?)
It would also allow the use of unsuported hardware such as hardware RAID cards without needing to add the drivers to support them in RouterOS.
I am looking at deploying RouterOS on a Sun x4100 so support for multiple cores/CPUs for SMP and the LSI hardware SAS RAID controller would both be a big bonus. If not I can use the IDE port and a 3ghz Opteron but the box would be so much better if I could use all of its features

We've been thinking about this feature as well.
I agree with freethought on its redundancy.

Imagine: One physical PC, loaded with network cards, running several instances of MikroTik.

You could combine several different function routers into one PC, and/or use one instance as a primary router and another as a secondary backup to the primary.

As I mentioned before a key reason for us is supporting the hardware RAID card in the Sun x4100 servers which we want to deploy at the core of our network. If Xen were supported then we can load RouterOS onto another OS running as dom0 which supports the LSI MegaRAID (Linux, *BSD or Solaris when it gets dom0 support) and then run a couple of instances of RouterOS with VRRP to counter and software crashes. It is also a quick and dirty way to bypass the SMP and 1GB RAM limits which with the shift of focus from clockspeed to multicore CPUs is essential (1GB RAM is very limiting in SMP).
Alternativly I would like to see RouterOS support these features dirrectly as the LSI MegaRAID Linux drivers are open source and Linux has good SMP support and good memory managment (I can understand why the original decission was taken - to provide robust support for a key subset of the massive range of x86 hardware - but the x86[-64] server market is now a diferent place as is the router market).

I'd like to use an Xen version of MTOS for 2 reasons.

1. Use MT as a software firewall / networking front-end for a real server. A VM of MT could do traffic shaping/vpn/firewalling/capturing for the server much easier and nicer than the server's OS. The low memory and CPU requirements for MT in this role would be real easy on the hardware. MT as a software firewall is a potential whole new market.

2. Testing/playing with networking as others have mentioned.

anyone played with xen 3.1 and MT yet? it looks like you should be able to assign the atheros (or other) resources to a domU and do want we want ... will be testing soon and see if I can followup on that.

I haven't had the time, but I think there are still problems. I don't think ROS will run as a standard DomU, since the kernel wouldn't have been compiled for Xen.

It should run as an unmodified DomU, if you have VX/Pacifica, but at the moment I don't think PCI address spaces can be mapped correctly without IOMMU support.