📘 POST 2

Installing EVE-NG on ESXi: VM Sizing, Time Synchronization, and the Failures That Taught Me the Most

Introduction

Installing EVE-NG is deceptively simple.

Download ISO → create VM → boot → login → GUI loads.

At this point, many people think they’re done.

I thought so too — until things started breaking in ways that weren’t obvious, weren’t documented, and weren’t clearly connected.

This post covers what really matters after the ISO boots:

• Correct VM sizing
• Time synchronization
• Hidden dependencies
• Real failure scenarios and fixes

1. Designing the EVE-NG Virtual Machine (This Matters More Than You Think)

EVE-NG is not a “normal” VM. It is a hypervisor inside a hypervisor.

That means:

• CPU scheduling matters
• Memory pressure is unforgiving
• Disk and I/O latency show up as strange behavior

2. Recommended EVE-NG VM Sizing (Baseline)

Here is a realistic baseline for a serious lab:

Rule of thumb: If you want IOS-XRv or CSR1000v, 32 GB RAM is the real minimum.

3. Hardware Sizing Examples (Practical Scenarios)

🔹 Example 1: Enterprise Lab (IOL + Few CSR)

Goal: Campus + WAN lab Nodes:

• 6 × IOL L2
• 4 × IOL L3
• 2 × CSR1000v

RAM calculation:

• IOLs: ~4 GB total
• CSR: ~8 GB
• EVE overhead: ~6–8 GB

➡️ Total needed: ~20 GB ➡️ Recommended VM RAM: 32 GB (safe margin)

🔹 Example 2: ISP / MPLS Lab (XRv heavy)

Nodes:

• 4 × IOS-XRv (PE/P)
• 2 × CSR (CE)
• Few IOLs for access

RAM calculation:

• XRv: ~20–24 GB
• CSR: ~8 GB
• EVE overhead: ~8 GB

➡️ Total needed: ~36–40 GB ➡️ Recommended VM RAM: 48–64 GB

Lesson: XRv does not fail loudly when RAM is insufficient. It just… behaves badly.

4. CPU Oversubscription: What Works and What Doesn’t

CPU is far more forgiving than RAM.

What works:

• Oversubscribing vCPU
• Sharing cores across IOL nodes
• Bursty CPU usage

What doesn’t:

• Starving XRv during boot
• Running many XRv nodes on few physical cores

Rule: CPU oversubscription is fine. RAM oversubscription is not.

5. The Time Synchronization Problem (The Silent Killer)

This was the most confusing issue I faced.

Symptoms (Real Ones)

• apt update fails with: “Release file is not valid yet”
• Package installations fail randomly
• VPN installation refuses to work
• No obvious error pointing to time

Nothing looked broken.

6. Diagnosing Time Issues

First check:

timedatectl

If you see:

System clock synchronized: no

You are already in trouble — even if the GUI loads fine.

7. Why This Happens (Important Insight)

• Package repositories are time-signed
• Certificates depend on system time
• VPNs refuse to authenticate if time drifts
• Nested VMs often don’t sync time reliably

So one small issue breaks:

• APT
• TLS
• VPN
• Updates

All at once.

8. Real Failure Scenario: APT and VPN Both Broken

In my case:

• EVE-NG GUI worked
• Images partially worked
• VPN installation kept failing
• APT showed confusing errors

The root cause? ➡️ System time was ahead of real time.

This took far longer to diagnose than it should have.

9. The Reliable Fix: Chrony (Server-Grade NTP)

Instead of relying on default time sync, I switched to chrony.

Installation

apt install -y chrony

systemctl enable chrony

systemctl start chrony

Verify

chronyc tracking

Expected output includes:

Leap status : Normal

System time : very small offset

Then confirm:

timedatectl

System clock synchronized: yes

After this:

• APT worked immediately
• VPN installed cleanly
• Errors disappeared

Lesson: If time is wrong, nothing else is trustworthy.

10. Disk and Storage Considerations (Often Ignored)

Images grow quickly.

What starts as:

• 1 GB image

Becomes:

• 4–8 GB after operation
• More with snapshots

Recommendation

• Allocate 200+ GB disk
• Avoid thin provisioning if possible
• Monitor /opt/unetlab/addons

Running out of disk causes:

• Image corruption
• Silent node failures

11. Early Stability Lessons

Before even adding serious labs, I learned:

• EVE-NG is stable if the base OS is stable
• Time sync is not optional
• RAM planning avoids 90% of issues
• Many failures look unrelated but share a root cause

This changed how I approached the rest of the setup.

Closing Thoughts

This stage taught me something important:

Most lab problems are infrastructure problems, not networking problems.

Before touching routing protocols, I had to:

• Fix time
• Fix resources
• Fix stability

Only then did EVE-NG behave predictably.

🔜 Next in the Series

Post 3: Installing Network Images in EVE-NG — Precision, Permissions, and Why Images Don’t Appear

This is where most people get stuck — and where accuracy matters more than experience.