ghost
commented
4 years ago One of the problems is the GNS3 cloud is down level because "every" device in the GNS3 gui needs to be connected to the mgmt interface and the management interface should be connected to the host machine. Dockers are great. But all the action is on the host device because it will become a severe burden to start copy and pasting and backing all kinds of scripts back from the dockers to the host.
You can not really have 20 ethernet switches to support 20 GNS3 images to connect to 1 Cloud - it's a mess in the GUI. The nGCloud (next GNS3 cloud - forgive me for adulterating ng") must be invisible and the links to it must be invisible. This ngCloud and these nGLinks can show up in a "mgmt" tab in a browser to the web-gui, but that will not happen in my lifetime.
IMHO, only experienced users would want such a thing, so that would be a github "won't fix" or "don't fix" or "don't care".
But....all users should be gently pushed into designing things to follow BCP and implement such a management-only layer.
On Windows 10 and Ubuntu 18.04: I run a GNS3 Cloud appliance connected to a VM image. I also run a GNS3 NAT appliance connected to the same image. The images have been either Ubuntu 16.04 in October, November, and December in 2019. The images have been either Ubuntu 16.04 or Ubuntu 20.04 in April, May, June, and July of 2020. The GNS3 versions have been either 2.1.10 for both Ubuntu and Windows or 2.2.10 for Ubuntu and 2.2. for Windows.
On Ubuntu, I never see a problem. On Windows 10, the VM image is on the same subnet as the Windows host, but it has no default gateway for that subnet. But it gets it's default gateway from the NAT. I download large amounts of data on the network supplied by the NAT appliance and I recover it from Cloud appliance with my Windows 10 host.
Mysterious posts have been showing up on the community about "pings stop working after awhile" or "disable/enable the VMnet interface" to fix some problem. Since October, I have been either deleting the link to the Cloud, or deleting the Cloud. On Wednesday, the failure moved from very intermittent to, almost, clockwork every 20 minutes.
Friday morning, I had to rearrange my logging so I could save all logs (VMware, Windows, GNS3) before opening up GNS3 and also then clearing all logs before I started up GNS3. Then I save all logs, but do not clear all logs when I close GNS3. This took 8 hours for me to implement.. I have the failure recorded once, but I have not fully investigated the failure. I can narrow down the failure to within 1 minute.
I am suspecting the VMware Pro and Windows 10 interaction, but that would take me about 40 hours to obtain the skill level to troubleshoot that interaction.
I had to wipe out my usage of the NAT link because I can not now afford to get involved with troubleshooting this problem.
I will let the guest qcow2 devices on my GNS3 VM on my Windows 10 host roll for 3 weeks on just the Cloud appliance to see if they encounter any problems.
But as far as I am concerned, there is some kind of problem.
So as far as I am concerned, if someone writes a post that pings stop working after awhile. Then I can respond back, it is being investigated, and then I can suggest a workaround.
t