Building an EVE-NG Lab on Proxmox: From ‘Sluggish’ to ‘Smooth’ with Nested Virtualization – ITFROMZERO

Table of Contents

The 40.0 CPU Load Shock and the Homelab Optimization Problem

Last night, I stayed up late troubleshooting a tough case: a Cisco vIOS router on EVE-NG that would freeze solid five minutes after booting. The EVE-NG web interface also started responding sluggishly. Checking top on Proxmox, I was horrified to see the CPU load spike to 40.0 even though only 3 lab nodes were running.

The real issue wasn’t RAM or Disk. It was because I forgot to optimize Nested Virtualization (virtualization within virtualization). In a homelab environment with over 12 VMs running, shoving in a resource-hungry “beast” like EVE-NG without fine-tuning the resource allocation is a recipe for a system crash.

Why Proxmox + EVE-NG instead of other options?

Before typing commands, let’s look at the actual deployment options to understand why this combo is the “perfect match” for today’s network engineers.

1. Running Bare-metal (Installing directly on the server)

Pros: Absolute performance, no latency from intermediate layers.
Cons: Too wasteful. Using a 128GB RAM server just to run EVE-NG is a crime against your electricity bill. You also can’t take snapshots or perform quick backups of the entire OS.

2. VMware Workstation or ESXi

Pros: Familiar interface, easy to get started.
Cons: Since Broadcom acquired VMware, licensing issues and support for older hardware have become very hit-or-miss. ESXi is notoriously picky about consumer-grade network interface cards (NICs).

3. Proxmox VE (KVM)

Pros: Completely free, open-source, and has a very smooth Web UI management. Specifically, the backup feature to PBS (Proxmox Backup Server) can save a whole week’s work in just minutes.
Cons: Nested Virtualization is not enabled by default and requires manual intervention.

My choice: Proxmox VE. It allows me to run EVE-NG alongside Windows Server, Linux, and Docker to simulate a complete enterprise system.

Step 1: Enable Nested Virtualization on the Proxmox Host

This is the biggest bottleneck. Without this feature, EVE-NG runs in emulation mode instead of using hardware acceleration. Cisco or Juniper nodes will run at a snail’s pace, consuming 5-10 times more CPU than normal.

First, check the current status via the Proxmox shell:

# For Intel CPUs
cat /sys/module/kvm_intel/parameters/nested

# For AMD CPUs
cat /sys/module/kvm_amd/parameters/nested

If the result is N or 0, execute the following commands to unlock the power:

# For Intel
echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf

# For AMD
echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf

# Reboot the server for the configuration to take effect
reboot

After rebooting, the cat command should return Y or 1. Now, the virtualization layer is ready for the next level.

Step 2: VM Configuration – Don’t use the Default CPU

The most common mistake is leaving the CPU Type at Default (kvm64). This setting hides the optimization instruction sets of the actual CPU, preventing the VM from utilizing full performance.

CPU Type: Must select host. This helps the VM fully recognize flags like VMX/SVM and AES-NI, making VPN encryption tasks in your lab up to 30% faster.
Memory: You should set a fixed RAM amount instead of using Ballooning. In large labs, constant RAM resizing causes lag (jitter) in simulated traffic flows.
Network: Use VirtIO (balanced) to achieve the highest internal bandwidth between nodes.
SCSI Controller: Select VirtIO SCSI Single to optimize I/O queues for the hard drive.

Step 3: Check and Optimize Disk I/O in EVE-NG

After installation, SSH into EVE-NG and run the KVM check command:

/opt/unetlab/wrappers/unl_wrapper -a check

If the KVM Acceleration line shows exists, you are 90% successful. The remaining 10% lies in disk read/write speed.

EVE-NG generates a lot of logs. If you’re using an SSD, enable the Discard feature in the fstab file so Proxmox can release old data blocks, preventing the drive from slowing down over time:

# Edit the fstab file
nano /etc/fstab
# Add 'discard' to the root mount line:
UUID=xxx-xxx / ext4 defaults,discard 0 1

Real-world Experience: The CPU Pinning Trick

While running labs with heavy nodes like Palo Alto or Checkpoint firewalls, I noticed slight micro-stuttering. This is usually caused by other VMs on Proxmox competing for CPU cores with EVE-NG.

If you have a high-core-count CPU (like a Xeon E5 or Ryzen 9), you should try CPU Pinning. Dedicate a specific range of cores to EVE-NG to ensure that OSPF or BGP processes aren’t interrupted while you’re watching a movie on a Plex VM on the same server.

Edit the VM configuration file at /etc/pve/qemu-server/[VMID].conf and add the line:

cpuset: 0-7

Final Thoughts from the Lab

Building a network lab isn’t just about installing software. Understanding the underlying virtualization layer saves you hours of pointless debugging. With Proxmox, you can snapshot everything before performing complex labs. If the system is still slow, check the Swap. Never let your lab run on Swap, as disk speeds will never catch up to RAM speeds.