QEMUPNETLab2026-04

#6 - Why Some PNETLab and EVE-NG Images Need a Second QCOW2 Disk

•3 min read
#6 - Why Some PNETLab and EVE-NG Images Need a Second QCOW2 Disk

Table of Contents

When importing virtual appliances into EVE-NG or PNETLab, some images may not work properly with only a single .qcow2 file. This is common with devices that separate the system image from the data or storage disk.

A good example is FortiManager. Depending on where the image was downloaded from, you may receive only one file, such as:

fmg.qcow2

However, for the appliance to work correctly in the lab, the image structure may need to be adjusted to:

virtioa.qcow2   <- appliance system image
virtiob.qcow2   <- storage disk used by the appliance

This second disk is often required for the appliance to initialize storage properly, save data, or complete the boot process without issues.

Why Does This Happen?

Some virtual appliances are designed with a multi-disk architecture. In these cases:

  • the first disk contains the operating system and boot files
  • the second disk is used for logs, databases, application data, or internal storage
  • the platform expects both disks to exist during boot

In official hypervisor deployments, this second disk may already be included in the package or automatically provisioned during deployment. In EVE-NG and PNETLab, that does not always happen, especially when the image is imported manually.

Because of that, some downloaded images come with only the main system disk, and the additional storage disk must be created by hand.

FortiManager Example

In the case of FortiManager, you may start with only one file in the image folder:

fmg.qcow2

To make it compatible with EVE-NG or PNETLab, you typically need to rename the original file and create a second virtual disk.

Expected final structure

virtioa.qcow2
virtiob.qcow2

Where:

  • virtioa.qcow2 is the main FortiManager image
  • virtiob.qcow2 is the additional storage disk

Step 1 - Go to the Image Directory

Access your EVE-NG or PNETLab shell and navigate to the appliance folder:

cd /opt/unetlab/addons/qemu/fortinet-FMG-v7-build0306/

Adjust the folder name according to your image version.

Step 2 - Rename the Original Disk

If the downloaded image is named fmg.qcow2, rename it to virtioa.qcow2:

mv fmg.qcow2 virtioa.qcow2

This makes the image follow the naming convention expected by the platform.

Step 3 - Create the Second Disk

Now create the additional storage disk using qemu-img:

/opt/qemu/bin/qemu-img create -f qcow2 virtiob.qcow2 100G

Example output:

Formatting 'virtiob.qcow2', fmt=qcow2 size=107374182400 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

This creates a 100 GB virtual storage disk for the appliance.

Step 4 - Fix Permissions

After creating or renaming the files, run the permissions fix command:

/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

This ensures EVE-NG or PNETLab can properly access the image files.

Final Notes

  • Always check whether the appliance expects more than one disk.
  • Follow the virtioa.qcow2, virtiob.qcow2, virtioc.qcow2 naming pattern when required.
  • The additional disk size may vary depending on the appliance.
  • After modifying the image folder, always run the permissions fix command.

This small adjustment can save a lot of troubleshooting time and helps ensure your appliance boots and operates correctly in EVE-NG or PNETLab.