2.0.3-80 - IOSv filesystems don't persist across node stop/start

[d_b]

After upgrading 2.0.3-77 -> 2.0.3-80 (apt-get update ; apt-get install eve-ng ; apt-get upgrade ; reboot), all newly created IOSv nodes have become incapable of keeping files in nvram and flash filesystems across node stop/start (this is not 'reload'). Whether it is new node in pre-existing lab or new node in a new lab doesn't make a difference. Pre-existing nodes (in pre-existing labs obviously) work fine, files are saved normally and persist across node stop/start.

Steps to reproduce:

- upgrade EVE-NG to 2.0.3-80 (apt-get update ; apt-get install eve-ng ; apt-get upgrade ; reboot)
- create new blank lab
- add IOSv node
- right click start the node
- connect to console
- observe factory default config on device
- modify device config, save to nvram ('wr mem') and flash
- confirm startup config is saved ('more nvram:startup-config', 'dir nvram:', 'dir flash0:')
- reload device ('reload')
- confirm startup-config has been loaded
- right click stop the node
- right click start the node
- observe factory default config on device, saved configs are gone - PROBLEM

I used:

vios_l2-ADVENTERPRISEK9-M 15.2(4.0.55)E
VIOS-ADVENTERPRISEK9-M 15.6(2)T

IOL doesn't experience this problem.
Didn't test other kinds of nodes, reverted back to last known good snapshot of my EVE-NG machine.

My setup:

macOS 10.12.6 (16G29)
VMware Fusion Professional Version 8.5.8 (5824040)
EVE-NG 2.0.3-77 -> 2.0.3-80
Filesystem Size Used Avail Use% Mounted on
udev 2.9G 0 2.9G 0% /dev
tmpfs 595M 18M 578M 3% /run
/dev/mapper/eve--vg-root 22G 10G 11G 50% /
tmpfs 3.0G 0 3.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 3.0G 0 3.0G 0% /sys/fs/cgroup
/dev/sda1 472M 124M 324M 28% /boot
/opt/unetlab/wrappers/unl_wrapper -a fixpermissions - done

I can upload sick VM in case kind gentlemen of EVE-NG would like to take a look at what's wrong with it after an upgrade.

Thank you!

[Uldis (UD)]

no, not true, I did all your steps and confirm those images works and same and boot after stop/start node....
We discussed this in forum

Did tests on vers 80

UD

[d_b]

The root cause: my IOSv images were named hda.qcow2 not virtioa.qcow2.
There was conflicting information regarding proper naming on "How-To" (hda.qcow2) and "Image Naming" (virtioa.qcow2) pages which is now updated accordingly.

Because my pre-existing labs are using hda.qcow2 images, what I ended up doing is creating additional IOSv image directories then copying respective hda.qcow2 to virtioa.qcow2. This way I can keep pre-existing labs intact as well as new labs using virtio.

Thanks to UD who spotted the issue!