GNS3 Linux Networking Uncategorized

GNS3, Ubuntu, and the Fine Art of Fixing Your Own Mistakes

teodulfo.espero

April 30, 2026

Excerpt

I was following a Linux networking course and just wanted to run Ubuntu in GNS3. Instead, I spent the evening fixing permissions, ports, storage, virtualization, and my own bad assumptions.

Post

I was following a Linux course for networks by David Bombal.

The plan was simple:

  • add Ubuntu
  • start it
  • open console
  • learn something

You know… a lab.

Instead, I ended up learning and debugging the damn stack.

I Wanted to Do It the “Right Way”

I wanted to run everything on Ubuntu because it made sense.

Linux on Linux. Clean. Logical.

And I chose virt-manager because it’s “better”:

  • native KVM
  • closer to real infrastructure
  • fewer abstraction layers

Which is true.

It’s also why nothing behaved the way the course said it would.

I Could Have Chosen Peace

Let’s be honest.

I could’ve:

  • used VMware
  • used VirtualBox
  • or just used Windows and finished the lab in 15 minutes

Everything would have worked:

  • import appliance
  • click start
  • open console

Done.

No friction.

But also?

👉 No understanding.

The Appliance That Never Was

First step:

👉 Install Ubuntu Desktop Guest

Result:

  • missing files
  • checksum errors

Apparently, it expects a very specific .vmdk file—one that GNS3 gestures toward but never quite provides.

So right away:
👉 the lab and reality diverged

The Part the Course Skips: The GNS3 VM

Before Ubuntu even mattered, I had to deal with the GNS3 VM.

The remote server. The backend. The thing everything depends on.

It wouldn’t connect

  • GUI couldn’t reach it
  • wrong port
  • wrong service
  • wrong expectations

Then this:

Permission denied: /opt/gns3

Fix:

sudo mkdir -p /opt/gns3
sudo chown -R gns3:gns3 /opt/gns3

Then I realized:

  • GUI expects port 3080
  • VM was running on 80

So now I’m editing configs and restarting services just to get the lab environment working.

At this point, GNS3 stopped being software.

👉 It became infrastructure.

“Connected”… to Absolutely Nothing

Eventually I saw:

Trying 192.168.122.16...
Connected...

And then nothing.

Because I wasn’t talking to Ubuntu.

I was talking to the GNS3 backend.

Which is like calling support and getting a dial tone that never ends.

That’s when it clicked:

👉 I didn’t have a broken Ubuntu node
👉 I had no Ubuntu node at all

Then Came the Classic: Disk Full

Right on schedule:

No space left on device

Inside the VM:

/dev/vda2  100%

What did I do?

I created a 30GB Ubuntu disk inside a 20GB GNS3 VM.

Because of course I did.

So:

  • disk creation failed
  • files got corrupted
  • everything downstream broke

The Domino Effect

After that:

hda disk image ... is not accessible

Of course it isn’t.

It never got created properly.

Fixing it meant:

  • deleting the broken image
  • freeing space
  • rebuilding everything

The Moment I Just Leaned Into It

At some point, I realized:

I was already in the deep end.

I could’ve stopped.
Switched to VMware.
Followed the course exactly.

Instead, I thought:

👉 “Screw it. Let’s keep fixing it.”

And that changed everything.

Because once you commit to fixing it:

  • you stop looking for shortcuts
  • you start understanding systems

The Blank Screen That Wasn’t a Bug

Rebuilt everything.

Started the VM.

Nothing.

Again.

This time the issue:

telnet

Which gives you exactly what you deserve:

👉 nothing useful

Switching to:

VNC

fixed it instantly.

And Then, Naturally…

No such file or directory: 'vncviewer'

Of course.

Installed it:

sudo apt install tigervnc-viewer

And finally:

👉 Ubuntu appeared

What Actually Worked

After all that, the solution was simple:

  • QEMU VM (manual template)
  • 2–4GB RAM
  • 20–30GB disk
  • VNC console
  • Ubuntu ISO

Boot. Install. Done.

The long road to the obvious.

I Wish It Were More Agnostic

I wish there was something more agnostic.

Something where:

  • the same steps worked everywhere
  • the environment didn’t matter

But that’s not real.

In the real world:

  • environments differ
  • assumptions break
  • abstractions leak

And when they do?

👉 it’s your problem to fix

What I Actually Learned

Not just how to run Ubuntu.

But:

  • how GNS3 actually works
  • how the backend and nodes are separate
  • how storage limits break systems
  • how services fail
  • how virtualization behaves under pressure

The Trade-Off

Ubuntu + virt-manager is better.

But better does not mean easier.

Better means:

  • more visibility
  • more control
  • more responsibility

Where I Landed

Now I have:

  • a working GNS3 remote server
  • a real Ubuntu VM
  • a functioning lab

And more importantly:

👉 I understand every layer involved

Final Thought

I didn’t set out to debug the entire stack.

I just wanted Ubuntu running in GNS3.

But once I was in the deep end, I stayed there.

Because that’s the job.

Stuff breaks.

And when it does?

👉 you fix it

Tags: