So my uh ‘friend’ that got into trouble when he found out that his ‘dedicated’ machine turned out to be a VM which he couldn’t launch nested KVM VM’s, and instead found that User Mode Linux (UML), would allow them to run their touchy ancient Linux application in a psudo VM/Container. Well they finally bit the bullet and decided to move to something better.
And by better, it was cheaper. And why was it cheaper? Because it is even a more restricted VM.
So naturally the panic call was made, because TUN/TAP networking was not permitted in this new VM. So what to do.
Well, keeping in mind how Qemu gets around this problem, it binds in a copy of SLiRP. And it turns out that UML can actually call SLiRP directly! So cool we have an ‘out’. First things first, we need SLiRP on the host machine. I’m old, so that means I build it from source.That means I’m downloading slirp-1.0.16.tar.gz, along with the 1.0.17 patch. I’m not sure if I need to go into how to extract source, patch, running configure and compiling.
One thing of note is that you really really really want to set the “FULL_BOLT” option either in the Makefile, or in config.h
With SLiRP built, I just copy it into /usr/local/bin .. I’m sure there is packages and stuff out there, but heh I’m old.
OK next up I make a small script to call SLiRP, in this case, I’m going to redirect port 80 directly into the VM. And for a test port 2323 which then goes into port 23 (why not ssh? .. sigh don’t go there).
So my script looks like this:
/usr/local/bin/slirp “redir 80 80” “redir 23 2323”
Pretty simple right? I’m using a script as there will be more than one VM, so relying on .slirprc isn’t a solution for me.
./linux-2.6.24-rc7 ubd0=junk.ubda eth0=slirp,,/virtual/sl.sh
And away we go!
Inside the VM we can configure it with the usual SLiRP config:
ifconfig eth0 10.0.2.15 255.255.255.0
route add default gw 10.0.2.2
And now we can access the internal http server!
Add in some magic to /etc/resolv.conf such as:
and it’ll automatically use whatever the host is configured to do.