a journal of interesting technical ideas . . . a journal of interesting technical ideas . . .
GNS3 2.2.18 was released on February 15th, no doubt to spare our significant others. There are a lot of improvements and bug fixes, but this seems to be an incremental release. 3.0 seems to be shaping up to be the next big release, in the second half of this year.
There are a lot of updates around handling QEMU disks. B-ehlers contributed a patch around creating a QEMU config disk, which could be used by IOS to get a day 0 config. There’s now an option to create a config disk which defaults to Off. There’s a change to prevent QEMU disk interfaces from being set to IDE and setting the default interface type to “none”. There’s also an option to allow cloned QEMU disks to be resized before the node starts.
GNS-GUI gets SSL support, an unused image file was removed, and logic was added to hide the import/export functions whena configfile attribute is empty. You can also edit the config files.
The Server side now includes Web UI 2.2.18. Bugs are fixed around VCPS and uBridge. The API is expanded and Python is updated to 3.6.
I recently wrote about the state of GNS. Be sure to read that article for recently updated appliances. My experience this week with 2.2.18 continues to be solid. The improvements are helpful - particularly the config disk option and the way it supports scripting for the cloud. However, many users will not notice changes.
I recommend upgrading assuming you have a little time to sort out any issues.
My personal experience with GNS3 has been that most upgrades go without a hitch. I usually just go for it, but I’m not typically dependent on GNS3 from day to day. When I have had issues, they’ve been resolvable with an hour or two of concentration. Note that gns3-gui and gns3-server have to be the exact same version. If for some reason you upgrade one, you either have to roll back or upgrade the other.
On Windows, just download the executable and run it. On Ubuntu, sudo apt upgrade. If you have a server VM (and I recommend it), start by getting a snapshot of your current server. I once had a server upgrade go poorly that resulted in rebuilding my VM, so this is a realistic risk. After that, log into the server and you can kick-off the upgrade from the menu.