💀 Crash #5: The Great OS Migration

"New Windows, new me. This time I'll do it right." Famous last words.

After the emulator war, I had made a decision.

No more WSL2. No more Hyper-V conflicts. No more virtualization layers fighting each other while I, an innocent bystander, paid the price.

I was going to wipe my computer clean, install a fresh Windows, and run my AI assistant inside a real virtual machine — VMware, with a full Linux installation. Isolated. Clean. Professional.

I backed up everything. Twice. (I had learned something from the 20GB model download disaster.)

Then I nuked the whole system.

The Clean Slate Delusion

Fresh Windows feels amazing. Everything is fast. Nothing is broken. You think: this time I will be organized. This time I will not make the same mistakes.

This is a lie the computer tells you.

I installed VMware. Downloaded Ubuntu. Created a virtual machine with 8GB RAM and 4 CPU cores. Installed Docker inside the VM. Deployed my AI assistant. Configured the gateway. Tested the QQ connection.

It. All. Worked.

I sat back in my chair and felt something I had not felt in weeks: peace.

Peace Lasted One Day

The next morning, I opened my laptop and the VM could not reach the internet.

The host had internet. The browser worked. But inside the VM? Nothing. The AI assistant was cut off from the world. A brain in a jar.

I spent three hours diagnosing this. Three. Hours.

The problem? VMware's network adapter had switched from "bridged" to "NAT" mode after a Windows update. I did not change this setting. I did not even know this setting existed until it broke.

Here is the real kicker: in bridged mode, the VM gets its own IP address from the router. In NAT mode, it shares the host's IP. The AI gateway was configured for one IP and suddenly found itself at another. Same machine. Different identity.

The network worked. The AI worked. They just could not find each other.

Then Shared Folders Broke

Two days later: I tried to edit a config file from Windows (because typing in a Linux terminal is exhausting) and the shared folder would not mount.

VMware Tools had silently uninstalled itself during an Ubuntu kernel update.

I did not trigger this. I did not approve this. The machine just... decided.

The Thing Nobody Tells You About VMs

Here is what I learned in Crash #2:

If my models were inside a virtual machine, I could have taken a snapshot the moment everything worked. When Windows crashed, I restore the snapshot. Thirty seconds. Done.

Crash #5 is where I finally put that into practice.

And it worked. When the network adapter went rogue, I did not spend two hours debugging like Crash #4. I restored a snapshot from yesterday. Ninety seconds. Back online.

When VMware Tools vanished, I restored a snapshot. Forty-five seconds. Done.

The VM did not solve every problem. It created new ones I had never seen before. But it gave me something I never had on bare metal: undo.

🛡️ Golden Rule Reminder

A clean install fixes old problems and creates new ones. The goal is not a perfect setup — it is a setup you can recover from. VMs give you recovery. Snapshots are time machines. Use them.

Bridged mode vs. NAT mode. If your VM needs to be reachable from other devices on your network (like your phone running QQ), use bridged. If it only needs outbound internet, NAT is simpler. Write this down somewhere. Future you will thank you.

← Crash #4: The Emulator War | Crash #6: The Invisible Network Cable →