grossmj
commented
4 years ago brtfs snapshots could also be used. More broadly, snapshots could eventually be delegated to a script provided by (advanced) users.
In summary here are the steps using brtfs (in French from B3r3n):
btrfs snapshot permet de
faire du versionning de fichier en operation atomique.
En d'autres termes, si tu delegues a un script les snapshots des appliances,
le script pourra alors faire comme bon lui semble et au niveau service, le
qemu snapshot est pulverise...
Pour la faire courte:
- GNS3 liste les snapshots disponibles (format a definir pour l'I/O)
- GNS3 recoit l'ordre de rollback noeud X / version Y et le transmets au
script qui fait le taf. Soit le script coupe le noeud, soit GNS3 le fait.
Apres et dans la mesure ou on aurait :
~gns3/projects/uuid/projects-files/uuid/ en volume BTRFS (script de migration
a faire, facile), soit :
mv ~gns3/projects/uuid/projects-files/uuid
~gns3/projects/uuid/projects-files/uuid.old
soit
btrfs sub del ~gns3/projects/uuid/projects-files/uuid
puis
btrfs sub snap snapshot_ad hoc ~gns3/projects/uuid/projects-files/uuid
operation atomique, fait en 1 parsec.
Node peut alors redemarrer
Idea from B3r3n:
GNS3 offers to snapshot via the classical method : copying the image/config. This works fine but it is awfully slow. To play my CTF, I involved ZFS snapshots, much faster and less space consuming. Associated with a project-control start/stop script, it was a killer :slightly_smiling_face:. I would like to consider the idea of a new GNS3 config feature : capability to delegate to a script the snapshots. Script would react as function : taking args and returning values. I imaging a gns-snapshot create|list|rollback|destroy project/node_uuid could be enough... I can provide the script if you accept the idea and feedback on args to give/get back.