Suse on TurboVision

Early VMware Betas on a Pentium II: When Windows NT Ran Inside SuSE

Fri, 03 Apr 2009 00:00:00 +0000

Some technical memories do not fade because they were elegant. They stay because they felt impossible at the time.

For me, one of those moments happened on a trusty Intel Pentium II at 350 MHz: early VMware beta builds on SuSE Linux, with Windows NT running inside a window. Today this sounds normal enough that younger admins shrug. Back then it felt like seeing tomorrow leak through a crack in the wall.

This is not a benchmark article. This is a field note from the era when virtualization moved from “weird demo trick” to “serious operational tool,” one late-night experiment at a time.

Before virtualization felt practical

In the 90s and very early 2000s, common service strategy for small teams was straightforward:

one service, one box, if possible
maybe two services per box if you trusted your luck
“testing” often meant touching production carefully and hoping rollback was simple

Hardware was expensive relative to team budgets, and machine diversity created endless compatibility work. If you needed a Windows-specific utility and your core ops stack was Linux, you either kept a separate Windows machine around or you dual-booted and lost rhythm every time.

Dual-boot is not just inconvenience. It is context-switch tax on engineering.

The first time NT booted inside Linux

The first successful NT boot inside that SuSE host is still vivid:

CPU fan louder than it should be
CRT humming
disk LED flickering in hard, irregular bursts
my own disbelief sitting somewhere between curiosity and panic

I remember thinking, “This should not work this smoothly on this hardware.”

Was it fast? Not by modern standards. Was it usable? Surprisingly yes for admin tasks, compatibility checks, and software validation that previously required physical machine juggling.

The emotional impact mattered. You could feel a new operations model arriving:

isolate legacy dependencies
test risky changes safely
snapshot-like rollback mindset
consolidate lightly loaded services

A new infrastructure model suddenly had a shape.

Why this mattered to Linux-first geeks

For Linux operators in that 1995-2010 transition, virtualization solved very specific pain:

keep Linux as host control plane
run Windows-only dependencies without dedicating separate hardware
reduce “special snowflake server” count
rehearse migrations without touching production first

This was not ideology. It was practical engineering under budget pressure.

The machine constraints made us better operators

Running early virtualization on a Pentium II/350 forced discipline:

memory was finite enough to hurt
disk throughput was visibly limited
poor guest tuning punished host responsiveness immediately

You learned resource budgeting viscerally:

host must remain healthy first
guest allocation must reflect actual workload
disk layout and swap behavior decide stability
“just add RAM” is not always available

These constraints built habits that still pay off on modern hosts.

Early host setup principles that worked

On these older Linux hosts, stability came from a few rules:

keep host services minimal
reserve memory for host operations explicitly
use predictable storage paths for VM images
separate experimental guests from critical data volumes
monitor load and I/O wait, not just CPU percentage

A conceptual host prep checklist looked like:

[ ] host kernel and modules known-stable for your VMware beta build
[ ] enough free RAM after host baseline services start
[ ] dedicated VM image directory with free-space headroom
[ ] swap configured, but not treated as performance strategy
[ ] console access path tested before heavy experimentation

None of this is glamorous. All of it prevents lockups and bad nights.

The NT guest use cases that justified the effort

In our environment, Windows NT guests were not vanity installs. They handled concrete compatibility needs:

testing line-of-business tools that had no Linux equivalent
validating file/print behavior before mixed-network cutovers
running legacy admin utilities during migration projects
reproducing customer-side issues in a controlled sandbox

This meant less dependence on rare physical machines and fewer risky “test in production” moments.

Performance truth: no miracles, but enough value

Let us be honest about the period hardware:

boot times were not instant
disk-heavy operations could stall
GUI smoothness depended on careful expectation management

Yet the value proposition still won because the alternative was worse:

more hardware to maintain
slower testing loops
higher migration risk

In operations, “fast enough with isolation” often beats “native speed with fragile process.”

Snapshot mindset before snapshots were routine

Even with primitive feature sets, virtualization changes how we think about change risk:

make copy/backup before risky config change
test patch path in guest clone first when feasible
treat guest image as recoverable artifact, not sacred snowflake

This was the beginning of infrastructure reproducibility culture for many small teams.

You can draw a straight line from these habits to modern immutable infrastructure ideas.

Incident story: the host freeze that taught priority order

One weekend we overcommitted memory to a guest while also running heavy host-side file operations. Result:

host responsiveness collapsed
guest became unusable
remote admin path lagged dangerously

We recovered without data loss, but it changed policy immediately:

host reserve memory threshold documented and enforced
guest profile templates by workload class
heavy guest jobs scheduled off peak
emergency console procedure printed and tested

Virtualization did not remove operations discipline. It demanded better discipline.

Why early VMware felt like “cool as hell”

The phrase is accurate. Seeing NT inside SuSE on that Pentium II was cool as hell.

But the deeper excitement was not novelty. It was leverage:

one host, multiple controlled contexts
faster validation cycles
safer migration experiments
better utilization of constrained hardware

It felt like getting extra machines without buying extra machines.

For small teams, that is strategic.

From experiment to policy

By the late 2000s, what began as experimentation became policy in many shops:

new service proposals evaluated for virtual deployment first
legacy service retention handled via contained guest strategy
test/staging environments built as guest clones where possible
consolidation planned with explicit failure-domain limits

The “limit” part matters. Over-consolidation creates giant blast radii. We learned to balance efficiency and fault isolation deliberately.

Linux host craftsmanship still mattered

Virtualization did not excuse sloppy host administration. It amplified host importance.

Host failures now impacted multiple services, so we tightened:

patch discipline with maintenance windows
storage reliability checks and backups
monitoring for host + guest layers
documented restart ordering

A clean host made virtualization feel magical. A messy host made virtualization feel cursed.

The migration connection

Virtualization became a bridge tool in service migrations:

run legacy app in guest while rewriting surrounding systems
test domain/auth changes against realistic guest snapshots
stage cutovers with rollback confidence

This reduced pressure for immediate rewrites and gave teams time to modernize interfaces safely.

In that sense, virtualization and migration strategy are the same conversation.

Economic impact for small teams

In budget-constrained environments, early virtualization offered:

hardware consolidation
lower power/space overhead
faster provisioning for test scenarios
reduced dependency on old physical hardware

It was not “free.” It was cheaper than the alternative while improving flexibility.

That is a rare combination.

Lessons that remain true in 2009

Writing this in 2009, with virtualization now far less exotic, the lessons from that Pentium II era remain useful:

constrain resource overcommit with explicit policy
protect host health before guest convenience
treat VM images as operational artifacts
document recovery paths for host and guests
use virtualization to reduce migration risk, not to hide poor architecture

The tools got better. The principles did not change.

A practical starter checklist

If you are adopting virtualization in a small Linux shop now:

define host resource reserve policy
classify guest workloads by criticality
put VM storage on monitored, backed-up volumes
script basic guest lifecycle tasks
test host failure and guest recovery path quarterly
keep one plain-text architecture map updated

Do this and virtualization becomes boringly useful, which is exactly what operations should aim for.

A note on nostalgia versus engineering value

It is easy to romanticize that era, but the useful takeaway is not nostalgia. The useful takeaway is method: use constraints to sharpen design, use isolation to reduce risk, and use repeatable host hygiene to make experimental technology production-safe.

If virtualization teaches nothing else, it teaches this: clever demos are optional, operational clarity is mandatory.

Closing memory

I still remember that Pentium II tower: beige case, 350 MHz label, fan noise, and the first moment NT desktop appeared inside a Linux window.

It looked like a trick.
It became a method.

And for many of us who lived through the 90s-to-internet transition, that method made the next decade possible.

Making ISDN Dial-On-Demand Work with SuSE and ipfwadm

Sun, 14 Feb 1999 00:00:00 +0000

Now the box is not only booting, it is doing useful work.

I still have the DSL hardware connected, but the modem LED is still blinking and not stable. So this means: the real life is still ISDN. But because of the T-Online/DSL package I can already use ISDN for internet without this old fear of counting every minute too hard. That makes it much more realistic to really use the Linux router every day and not only as some weekend test setup.

The main thing I wanted was dial on demand. I do not want the machine online all the time if nobody uses it. Also I do not want manual dial each time. The right thing is: local machine sends packet, router notices it, line goes up, internet works. Later, when no traffic is there anymore, the line goes down again.

In theory this sounds very logical. In practice it takes me enough evenings.

ipppd and the general direction

The important parts for me are isdn4linux and ipppd. isdn4linux does the low-level ISDN side and ipppd does the PPP part. After reading enough HOWTO text and trying enough wrong settings I end up with a setup that is at least understandable.

The main config is not beautiful, but it is mine:

# /etc/ppp/options.ippp0
asyncmap 0
noauth
crtscts
modem
lock
proxyarp
defaultroute
noipdefault
usepeerdns
persist
idle 300
holdoff 5
maxfail 3

The important line for me here is idle 300. Five minutes. That means if there is no traffic for five minutes, the line goes down again. This feels practical. Long enough that browsing is not annoying. Short enough that the box is not just hanging online forever.

The actual dial and hangup I bind to isdnctrl:

`1`	`/usr/sbin/ipppd file /etc/ppp/options.ippp0 connect '/usr/sbin/isdnctrl dial ippp0' disconnect '/usr/sbin/isdnctrl hangup ippp0' ippp0`

When it works the result is nice. First request is a bit slow. The line comes up. Then surfing feels normal enough for that time. Mail works. IRC works. FTP works if it behaves.

The first-click effect

One thing is always there and I think everybody who does this knows it: the first click is special.

If the line is down and a browser tries to fetch a page, sometimes the first request times out before the line is really ready. Then the user clicks reload and now it works because the link is already up. So I keep telling people in the flat: if the page does not come on first try, just click again, the router is maybe still dialing.

This sounds stupid, but after a week everybody knows it and then it is just normal life.

Kernel 2.0 means ipfwadm. I already heard about ipchains and I would like to try it, but on this box I am still on SuSE 5.3 with the 2.0 kernel, so for now it is ipfwadm. The syntax is not exactly poetry, but it works.

I use masquerading so the local machines can share the one connection. Internal side is private addresses, router has the public side via ISDN, and packets get masked on the way out.

Minimal direction looks like this:

1
2
3

echo 1 > /proc/sys/net/ipv4/ip_forward
ipfwadm -F -p deny
ipfwadm -F -a m -S 192.168.42.0/24 -D 0.0.0.0/0

That is not the full ruleset, only the basic idea. I keep the real script in /etc/rc.d/ and comment it because otherwise I forget the arguments in one week.

I like that with Linux 2.0 one can still see the whole moving pieces without too much abstraction. On the other hand, things like FTP quickly show where the limits are.

FTP and the small pain of old protocols

Passive FTP is mostly okay. Active FTP is not so nice. With ipfwadm and this generation there is no good helper for it. So active FTP can fail in stupid ways and then you start thinking maybe you broke the router, but in fact the protocol is just doing protocol things.

After some evenings I decide the simple rule is this: use passive FTP when possible and do not lose time with trying to make old protocol design look smart.

That is maybe the first moment where running a router teaches me something bigger than command syntax. Many network problems are not Linux problems. They are protocol problems, software expectations problems, or user expectation problems.

T-Online and general line feeling

The provider side is okay most of the time. Sometimes the line drops for no reason I can see. Sometimes authentication fails once and works on the next try. I keep notes because otherwise every error starts to feel mystical.

I think this is one important habit I get from this box: write down what happened. Time, symptom, what I changed, what worked. Without this, three evenings of problem solving become one big confused memory.

The machine itself

The Cyrix Cx133 is doing fine. I already moved it to 16 MB and this helps a lot. 8 MB was really not much. Right now the box is still in the lean stage. No big extra services. Just enough to route and share the line.

The Teles card still needs respect. If something goes weird, I first check cable and card state before I start blaming PPP. This saves me time.

What already feels good

Even now, before DSL is really there, the setup already feels worth it.

one box for the internet edge
shared connection for local machines
line comes up only when needed
config files which I can read and change
no dependency on one desktop machine being on

This is already much more “real systems” feeling than just installing Linux on a PC for trying around.

I still want more from the box. I want DNS cache. I want maybe a proxy. I want some cleaner way to wake the line from outside. Right now if I am not at home and the line is down, then it is down. That is the next problem I want to solve.

Also the DSL modem is still blinking. It is almost becoming decoration.

My First Linux Router: SuSE 5.3, Teles ISDN and the Blinking DSL Modem

Sat, 03 Oct 1998 00:00:00 +0000

I wanted to start with Linux already earlier, but I did not. One reason was VFAT. I had too much DOS and Windows stuff on the disk and I did not want to make a big break just for trying Linux. Now SuSE 5.3 comes with kernel 2.0.35 and VFAT support is there in a way that feels usable for me, so now I finally do it.

Also I have enough curiosity to break my evenings with this, and enough little money to make bad hardware decisions and then keep them running because there is no budget for the nice version.

The machine for the router is a Cyrix Cx133. Not a fancy box. Right now it has 8 MB RAM and a 1.2 GB IDE disk. The case looks like every beige case looks. For a router it is enough. It boots. It stays on. It has one job. If I find cheap RAM later I will put it in, but first I want the basic thing working.

For ISDN I do not buy AVM because I simply cannot. Everybody says AVM is the good stuff and the drivers are nice and all is more easy. Fine. I buy a cheap Teles 16.3 PnP card. It is not the card of dreams, but it is my card and I can pay it. So the project now is not “what is best”, it is “what can be made to work with Teles and a bit stubbornness”.

At the same time there is already the whole T-DSL story from Telekom. This is maybe the funny part: I already subscribe to the DSL package together with T-Online, but the line is not switched yet. They give us the hardware. The DSL modem is there. The splitter is there. Everything is there. I can look at the modem and I can connect it and the LED is blinking and blinking and blinking. But there is no real DSL sync yet. It is like the future is already on the desk, only the exchange in the street does not care.

The good thing in this package is: I can already use ISDN with the same flatrate model through T-Online until DSL is finally active. That changes everything. If I had to pay every minute like in the older ISDN situation, I would maybe not do such experiments so relaxed. But with this package I can prepare the whole router now, use it now, put the DSL hardware already in place, and then just wait until someday the blinking LED becomes stable.

This is maybe a bit absurd, but also very german somehow: contract ready, hardware ready, paperwork ready, technology almost ready, and then the actual line activation takes forever.

Why I want a real router box

I do not want one Windows machine doing the internet and all other machines depending on that. I also do not want manual dial each time. I want a separate machine which is just there and does the gateway work. If it works good, nobody sees it. If it breaks, everybody sees it. This is exactly the kind of thing I like.

Also I want to learn Linux not only as desktop. Desktop is nice, but for me the interesting thing is always when one machine does a service for other machines. Then it gets serious. Then configuration is not decoration anymore.

The first setup is simple:

Cyrix Cx133 as the router
Teles 16.3 for ISDN
one NE2000 compatible network card for local LAN
SuSE 5.3
T-Online account
DSL hardware already connected, but DSL itself still sleeping somewhere in Telekom land

The LAN side is eth0. The ISDN side I will configure through the i4l tools once the login part is really clean.

Installing SuSE 5.3

SuSE installation feels big for a student machine because there are so many packages and YaST wants to help everywhere. But I must say, for this use case it is really practical. I do not want to compile every tiny thing right now. I want the machine up and then I want to start reading config files.

The nice thing is that SuSE 5.3 already has what I need for this direction:

kernel 2.0.35
VFAT support, finally good enough for me to jump in
isdn4linux pieces
YaST for basic setup
normal network tools and PPP stuff

The first days are not so elegant. I reinstall once because I partition stupidly. Then I configure the network wrong and wonder why nothing routes. Then I realize that reading the docs before midnight is much more productive than changing random options after midnight.

Still, the feeling is strong: this is possible. The machine is not powerful. The card is not luxury. But Linux is not laughing about the hardware. It takes the hardware seriously and tries to use it.

The Teles card and the small pain around it

The Teles 16.3 works, but not like a nice toy. It works like something you need to deserve first.

PnP is not really my friend here. Auto-detection is sometimes correct and sometimes not. I get into the usual dance with IRQ and I/O settings, and because the NE2000 clone is also not exactly a model citizen, I must be careful there are no collisions. When it finally stabilizes, I write down the values because I know I will forget them if I do not.

The card sits on S0 bus with a passive NT. That setup is physically very small. Short cable is important. At first I use a longer cable because it is just the cable I have on the desk. Then I get strange effects. D-channel sync comes, then some weird instability. I shorten the cable and suddenly the whole thing becomes much less dramatic. From this I learn again the old rule: with communication stuff, physical layer problems are always more stupid than the software problems.

When the ISDN side starts to work the feeling is really good. No modem noise. No analog nonsense. Digital and clean. I know 64 kbit/s is not much in the abstract, but compared to normal modem life it feels fast enough that one can do real things.

The strange situation with the DSL modem

The modem is already on the desk and it is maybe the best symbol for this whole phase. I already have the new thing. I can touch it. I can cable it. I can power it. But it is not mine yet in the practical sense, because the line in the exchange is not enabled.

So what happens is: I install the splitter, I connect the modem, I look at the LED, and it blinks. Every day it blinks. It is almost funny. It is like the house has a small promise lamp.

Because we already have the package, I can connect with ISDN under the same general tariff model and prepare everything. This is really useful. It means the whole router is not a waiting project. It is a live project from day one. The DSL modem is there as a future device, but the machine is already useful now through ISDN.

This also changes my mood when building it. I am not making a theoretical future router. I am making a real working box. If Telekom ever finishes the outside part, then maybe the uplink can change without rebuilding the whole idea from zero.

What I have running now

At this moment I keep it simple. I am still mostly happy that Linux is on the box and the basic line can come up. The stack is not fancy yet. It is more like this:

SuSE 5.3
isdn4linux
T-Online login
local Ethernet
a lot of notes on paper

I already know I want these things later:

dial on demand
IP masquerading for the LAN
maybe DNS cache
maybe Squid if memory allows it
and if DSL finally comes, then PPPoE and the same box continues

I do not know yet which part will be the most annoying. Right now I guess the Teles card. Maybe later I will say PPP is worse. Maybe both.

For now I am just happy that Linux finally starts for me with a version where VFAT is not a blocker anymore, the cheap ISDN hardware is usable, and the blinking DSL modem already stands on the desk like a small challenge.

Maybe next I write more when the dial-on-demand part is not so ugly anymore.