Why GNS3 use UUID?
A common question about GNS3 is why I can’t easily locate on disk the files of a node due to the usage of UUID in folder naming.
An UUID is a 128-bit number. The generation of an UUID doesn’t require a central registration authority in order to be almost unique. Their is a low probability of collisions. In GNS3 we represent an UUID like this: 42a1b682-b5bf-4de4-b5af-5366fc20a111.
More informations about UUID: https://en.wikipedia.org/wiki/Universally_unique_identifier
Because UUID are unique, you have the warranty that an UUID for a project or node on your computer is not use on another computer. This allow to share project without conflicts, otherwise you have an high probably to use the same name for nodes or project.
If you list the files of a project you will see that the nodes folder use UUID:
# ls -R myproject
The UUID for a node is stable and will never change.
The main reason for using UUID instead of name, is most emulators doesn’t support changing the path of their files when the emulator is running. If you want to rename to node and change the path of a folder you need to stop the node and restart it.
The second reason is some emulators have restriction on the characters in path, by using UUID user don’t need to care about that.
When you use GNS3 on your local computer, you can choose the location of the project files. It’s for backward compatibility and to allow user to free disk space without starting GNS3. But on a remote server all project are in the same directory with an UUID as their name.
The first reason is to avoid trouble when renaming/copy a project. Second reason is to prevent problem if the remote server filesystem doesn’t support UTF-8.
This also allow to run multiple GNS3 server using the same shared projects folder without risk of collision. Or in the future to support multiple user with same project name sharing a common server.
There's a reason for GNS3 to not consider the need to have a user friendly file system. Nobody should directly interact with what is the folder. It’s GNS3 internals and there's good reasons for that. GNS3 provide tools to export or edit file and you need to use them. If you build a third party's application use the API to apply your modification.
If you browse the disk you will see stuff that could be the configuration file on the node. But this not always sync, for various reason they could be out of sync and it’s normal. You could have a delay when you save in the emulator and when GNS3 is notify about the change and dump the configuration on disk.
What you change on disk could be lost at next sync.
It’s the worse case scenario. User modify something on disk outside GNS3 and GNS3 write the file at the same time. This could corrupt the files. Some configuration file modifications can even crash the emulator.
If you split your project on multiple server the data could be located on multiple server. If you use the API you don’t need to care about that.