Troubleshooting NX-OS blank session in UNetLab

Some you have said that you get a blank console session when connecting to an NX-OS node in UNetLab. In this post, we will look at some basic steps for troubleshooting NX-OS in UNL. Please note, though, I cannot replicate the issue and have tried with both Nexus 7 and 5. This is where the more information that people who have the issue can offer, the easier it will be to fix!

For the setup instructions, please see this post on setting up NX-OS Titanium. While many have said they have had issues, they have not given many details on how they are setting things up, nor on their system. So, we will go through this one-by-one. Hopefully, if you are having this issue (where you get a blank console session when connecting), we may be able to find the problem together.

Is your server fast enough?

You need to have a server fast enough to run NX-OS. So, if you are having this issue, are you:

A: Running a separate/dedicated ESXi or barebones server ?
B: Running UNetLab within a hypervisor (VMWare Fusion/Player) within your main machine?

If B:

Have you given enough resources to the VM? If you have an 8GB machine, running VMWare Player, with UNetLab running within it, running an NX-OS host (or two), then you will see a huge impact!

If you have an 8GB machine, running VMWare Player, with UNetLab running within it, running an NX-OS host (or two), then you will see a huge impact! Each NX-OS host should have four GB or memory. UNetLab itself uses memory; your computer requires memory. You will need at least 16GB to run UNetLab on a desktop PC at a decent speed.

What CPU are you running? Remember, not all CPUs are created equally. So, if you are having this issue, and need help, let us know what CPU you have.

I am running UNetLab on a dedicated ESXi box, and have given it 40GB memory, and 12 CPUs:

Troubleshooting NX-OS

That’s the host section taken care of, what about the node itself?

Troubleshooting NX-OS Memory issues

Titanium needs a decent amount of memory to run. 4GB to be exact. If UNetLab only has 4GB, it will struggle. If the UNetLab VM only has one CPU given to it in VMWare, it will struggle.

Make sure the UNetLab VM has enough resources to run the node:

NX-OS Memory UNetLab

As you can see, we are running the NX-OS with 1 CPU, 4096MB of memory (4GB), 4 Ethernet ports and we are using telnet for the console connection.

This works perfectly fine. I can add a node, like this, and start it up, and add a v5 image start it up and connect to the consoles of both hosts. Within 4 minutes:

Up and running with Nexus NX-OS in 4-minutes

It runs perfectly well! But what if it does not work for you?

Troubleshooting NX-OS in UNetLab

So, what happens if it is not running for you?

Firstly, if your machine is not powerful enough to run a node that requires 4GB memory in UNetLab, then you need to address this first. I am running a Dell T5500 (dual Hexa-core), which works great, and I picked up on eBay. It runs ESXi with no issues. If you are running UNetLab within VMWare on a PC (or MAC), make sure that the VM has enough memory allocated to it, and there are enough CPU cores to share with UNetLab.

Check the logs!

If your machine is powerful enough, try looking at the logs in UNetLab. Select Logs from the menu on the main screen:UNetLab-logs

We have a number of logs to look through. Some may be empty, some may have data in them:


The logs file we are most interested in, is the unl_wrapper.txt log file:


Here is the interesting bit:

Oct 30 10:10:30 INFO: starting /opt/unetlab/wrappers/qemu_wrapper -T 0 -D 1 -t "NXOS" 
-F /opt/qemu/bin/qemu-system-x86_64 -d 0 -- 
-device e1000,netdev=net0,mac=50:00:00:01:00:00 -netdev tap,id=net0,ifname=vunl0_1_0,script=no 
-device e1000,netdev=net1,mac=50:00:00:01:00:01 -netdev tap,id=net1,ifname=vunl0_1_1,script=no 
-device e1000,netdev=net2,mac=50:00:00:01:00:02 -netdev tap,id=net2,ifname=vunl0_1_2,script=no 
-device e1000,netdev=net3,mac=50:00:00:01:00:03 -netdev tap,id=net3,ifname=vunl0_1_3,script=no 
-smp 1 -m 4096 -name NXOS -uuid 8ebe0b37-064e-4c6e-adb7-0228d774f5ae 
-drive file=virtioa.qcow2,if=virtio,bus=0,unit=0,cache=none 
-machine type=pc-1.0,accel=kvm -serial mon:stdio -nographic -nodefconfig -nodefaults 
-rtc base=utc > /opt/unetlab/tmp/0/ab5014b8-1af6-47b7-b70a-fc05ab6c5b6d/1/wrapper.txt 2>&1 &

I have amended the formatting a little, but we can see that we have four e1000 interfaces, and we are using 1 CPU (-smp 1), 4096 memory (-m 4096), and the qcow2 file in use is virtioa.qcow2. In the original post on Setting up NX-OS, I called my file hda.qcow2. I am not sure if this is where some of the issues that people have stemmed from, but if you look at the contents of titanium.php (/opt/unetlab/html/templates/), there is nothing there to say that it must be called one or the other. But it may be worth renaming the file to virtioa.qcow2, and running the wrappers command again (/opt/unetlab/wrappers/unl_wrapper -a fixpermissions).

Final steps for troubleshooting NX-OS

If all else fails, you can leave a comment below, but please do explain your setup, i.e.:

Standalone ESXi server, or hosted on your machine)
How much memory and CPU the UNetLab VM has
What kind of CPU (make/model)
What do the logs show you…

Alternatively, you can post in the forum.

If we get enough feedback about what kind of setups people are using, we might be able to help each other. NX-OS is pretty popular amongst UNetLab users, so let’s help each other!

Learn more!

If you want to know how to do more with NX-OS, then NX-OS and Cisco Nexus Switching: Next-generation Data Center Architectures is a great resource!

NX-OS and Cisco Nexus Switching: Next-generation Data Center Architectures


  1. Mohammad Ishaq October 30, 2016
  2. Chichi November 3, 2016
    • Stuart Fordham November 3, 2016
  3. Nilesh March 23, 2017
    • Stuart Fordham March 30, 2017
  4. baihao April 6, 2017
  5. JZ April 1, 2018