I’ll expound on this as I go on.  For now this will be an overview with separate articles going into each part.  I’ll go into the process of how I created my OS/2 2.0 BBS, bbs.superglobalmegacorp.com .

VPS’s (Virtual Private Servers) are getting cheaper as the days go on, and it only makes more and more sense to take advantage of these great things!  Almost all of them are geared to running Linux, a few to Windows, and well anything outside of those two is damned near impossible to find (I’ve seen ONE NetBSD VPS service).

So if you want to say run MS-DOS, OS/2, Xenix, or any other crazed OS (why not?!) you are basically SOL as they say, except of course, if you utilize our old friend Qemu.

The first thing you’ll need is a VPS.  Now there are thousands of providers out there, I can recommend what I use (and I’ve got a few) but as always, pick a plan that you feel comfortable with.  To get started on something small a budget of under $10 USD a month is perfectly fine.  Shop around and you can certainly find cheaper in the month to month space, and if you are willing to pay up front, I’ve seen them average down to $2.50 USD a month.  Yes for less then a Big Mac, you can have your own ‘server’ in the sky (or part of the cloud nonsense if you are into that).  Hell you can even setup your own global infrastructure, with servers in Europe, Asia and North America for about $20 a month!

Anyways you can find an overload of reviews, and listings on sites like  webhostingtalk.com, and lowendbox.  Again I know it can be overwhelming but googling around you can eventually find what you are looking for.

Now what is important for running Qemu on a VPS? I’d have to say, memory is the #1 thing, bar none.  Now the joy of running older OS’s is that they didn’t need much back then so any new VPS ought to be ‘extravagant’ to them, but keep in mind Qemu needs a fair bit of memory itself!.  I generally worked it out to consume with a ‘bare’ CentOS or Debian install with an 8MB VM to consume around 60MB of memory.

Keep that in mind, that with your VM the OS will need memory, as long as disk space is also needed.  So it all depends on what OS you plan on running.  I’ve run MS-DOS, OS/2, Windows NT, and 386BSD all on the ‘cloud’.. And 8MB was fine for 386BSD but really the VM was overtaxed for anything outside of serving the VM… This for me was fine.  Again keep this in mind if you had hopes of serving web pages, hosting a blog (wordpress needs like 512MB of ram++!!!!!) or whatever.  Another thing is the x86 vs .x86_64 (32bit/64bit) question, and for VPS’s that need to keep small you will want to run 32bit code.  Esp if your VPS is configured under 2GB of ram, really there is no big ‘deal’ in loading 64bit stuff, epically since the 64bit versions consume more memory.

If in doubt setup a VM at home with the same constraints you are shopping to see if you can even do what you hope to do.  This is the big advantage of VM software as you can test all of this from home, without any major pain!

Another thing to keep in mind is that with your own VPS you will be the one required to keep it up to date!  Pick a distro that you are somewhat comfortable with.  Personally I went with Debian in my VPS’s as that is what I’m the most comfortable with.  Also I’d HIGHLY recommend NEVER EVER installing a compiler on the VPS.  If someone does get onto your system, handing them a compiler is like a loaded gun.  At least make it more…. involved for them.  Also setup a VM at home with the same OS, same cpu, same flavor *WITH* compiler, so that way you can check updates at home, to make sure things work, and of course compile things like Qemu for your environment without worrying about things that are either incredibly stale in packages, or just not there at all.  The same goes for things like firewalls.  Again pick something you are most comfortable with, and try to stick with that. The majority of OS’s available are Debian, various Debian forks (Unbutu?!) and CentOS, the RedHat ‘free’ clone.

With a VPS selected and created, and a VM at home loaded up with the same OS you will want to build Qemu.  Now keep in mind that since you’ll be running this on a server that will *NOT* have any local X11, and to minimize memory consumption & disk space by not loading .. X11, you will need to create a version of Qemu that is VNC display only.  It’s not that difficult.  It’s covered in the config process.

With a version of Qemu built, and uploaded to your VM (I use scp) you will then need to decide if you are going to encrypt your disk images (can you really, really trust your host?) or if you are fine with the way things are, and you are going to run in the open.  Naturally ‘fixed/flat’ disk images will be faster and not as CPU intensive, but of course they consume more disk space.  If you are going to ‘overcommit’ your VM or just don’t want to have the empty space right away, I’d highly recommend making a swap disk for the VM, that way you won’t blow out your disks with swapfile growth/shrinks and eventual fragmentation and moves.

If you did choose to encrypt your disks, you will need the program ‘screen’.  It’s been around for a long long while, and every Linux distro should have it available.  You will need to run screen, then launch Qemu from within screen, then it’ll prompt for the password for each disk drive.  Once Qemu is operational you can disconnect the screen session and it’ll remain operational.  Doing so in a script would require you to store the password locally, and defeats the whole point of encrypted storage.

Beyond storage, you’ll want to select some kind of method for external communications with the world.  For an OS/2 BBS I simply take TCP port 23 and forward it to the VM’s port 23.  SIO & vModem take care of all the logic from there.  If  you wanted to telnet into a *NIX box, again tcp port 23.  Maybe you want to run Windows NT 4.0 Terminal server, in that case the default TCP port is 3389.  While NT 4.0 is limited to Internet Explorer 6.0 and Firefox 1.5, it still can be a handy thing to have a multiuser version of NT (like a windows mainframe) out there somewhere for some things, although its usefulness is dwindling.  Maybe you want your own Exchange Server, or even SQL 7 instance, again older software performs better in tight disk/memory constraints.

Another thing to keep in mind is CPU consumption.  You will want a guest OS that can idle.  Otherwise you will consume 100% of the CPU 100% of the time, and they *WILL* notice this, and kick you out.  Be mindful of VPS services, and you have to share CPU resources.  Again watch your task manager or ‘ps’ locally and watch how things behave.  I know for the BBS stuff, you have to watch what doors you are interested in running as some of them happily gobble 100% of the CPU.  OS/2 friendly stuff is the way to go (IMHO) as CPU hogging was a big deal back then, and it’s best to ride on the back of how people solved this stuff a while ago.  Also for MS-DOS people, things like Dbase III applications it’d be a “bad idea” to put them into the cloud.  Although if you get one with a higher SLA that lets you run 100% then.. have at it!

If Qemu runs ‘normally’ you can even set it up into a batch file loop that calls Qemu over and over as needed between reboots.  You could even do some ‘house cleaning’ between reboots, say make a backup, email a notice etc… It’s all up to you, and what you are capable of batch script programming wise.

Also you will probably want your VPS to automatically launch your Qemu VM, and the best way I’ve found to do this is via the GNU screen program.  I just added the following to my /etc/rc.local file:

screen -S qemu -d -m /usr/local/os2bbs/run.sh
screen -S cpulimit -d -m /usr/local/bin/cpulimit -e qemu53 -l 8

This gives me two named instances, and will automatically limit my Qemu to only 8% of the host CPU that way I don’t get kicked for being a CPU hog.  8% of a 3Ghz CPU is more than enough for stuff that ran comfortably on a 16Mhz machine back in the day.

Then that would about wrap it up, you would now have a Linux VPS running your own OS, so you could serve up whatever application you want in the cloud.  The best part is, because Qemu is multiplatform, and will run on various OS’s and CPU combinations, you can jump ship very quickly to other platforms as you see fit, as all you need to do is rebuild your Qemu hosted binary, then copy your disk images & startup scripts and you are good to go!

Not to mention there is nothing to stop you from building the VM on Windows, to upload to Linux, then maybe move to SPARC Solaris!

Screw Java, Qemu is the ultimate VM!

Well this should have been ‘easy’ but let me assure you it was not.  However this may save someone LOTS of effort if they ever want to get TCP/IP running in a fossil like OS/2 2.0.

First of all OS/2 2.0 will not install in new versions of Qemu.  I had to go all the way back to Qemu 0.9.0!  Although there is a tonne of floppy images to shuffle, OS/2 2.0 will install somewhat straightforwardly.  Once OS/2 is installed, You will almost surely want the xr06100 service pack.  I found I was unable to run MS-DOS or WinOS/2 sessions at all without either crashing the system, or trapping the entire OS.  But after loading the service pack it works as expected.

Now Qemu supports all kinds of network cards, from the NE2000 ISA, a PCI version of the NE2000, the rtl8139, an AMD PcNET adapter, and a bunch of Intel adapters.  And the annoying thing is that the OS/2 driver I have for the AMD PcNET adapter does not work at all.  It can’t find the card no matter how much I tried.  Which is funny when Netware 3.12 of all things can see it…

I tried all kinds of NE2000 drivers set for 0x300 irq 3 or irq 9 (I changed hw/pc.c to reflect what it was set to) to either not loading, or it’d load and transmit packets, but NEVER receive any packets.

The rtl8039 (ne2k_pci) and rtl8139 would also either not find the card, crash on binding, or send packets and again receive nothing.  To say it was very annoying was an understatement.

So I almost gave up, I found some update for the TCP/IP, u64092 went through the needed fun with loaddskf, and finally got working diskettes, and … It still didn’t work.

So in a fit of rage, I removed the 0x300/9 ne2000 in the config, so the next one, the 0x320, IRQ 10 one is in order, and….. It worked!  It even works with the Microsoft NE2000 driver!

So I go ahead and modify Qemu 0.14.1 to force the ne2000 to 0x320/IRQ 10, and it works great on the latest version!  It’s a shame it doesn’t install… But hopefully you only need to do that once!

So there we go, saved by the NE2000 again.

For anyone crazy enough to reproduce this, here is my config.sys & protocol.ini … I’ve also installed EMX, but I don’t think that really matters…