Replies: 9 comments 2 replies
-
Yep. Discussion question: I have not run anything in LocalServer on Windows in over 5 years, maybe 7 years. The local server is a nuisance. Hold on to your hat. My script is running in 0 second mode now. In this script run, I am not starting gns3. I have a 4 hour csv file - which I can turn into a graph in 15 seconds. My Start-Gns3.ps1 is very powerful and all encompassing; but it is initially created because of the atrocity which is Windows AppData. My main problem is I am have not learned exceptions (how to handle errors) - it is hard to do that like the gns3 developers do it. And my coding skill is low, but getting better, so have never made a Class and I use Script Blocks. I do not think I want to "fix" my script until April. My code, in my HUMBLE opinion, obliterates the gns3 developers code. But my scriptblock $GetVmrunResultSB start-gns3vm.ps1 is called from start-mygns3vm.ps1 and start-mygns3vm.ps is building a csv file for how long it takes to start the gns3 vm. the number of loops is 240 because of how microsoft excel works. I have no traditional comments yet in my start-gns3vm.ps1 <# function Start-Gns3VM {
} #end function $Gns3VmStartTime = Start-Gns3VM Edit: oh yeah, and yesterday was the first time I removed a function from a script, so this script will not have a function. |
Beta Was this translation helpful? Give feedback.
-
The anomalies in the graph could be caused by anything in Windows. Edit: AND btw, I like a safety factor of 3-4. I read the python code and the code is 120 seconds before it throws an error - a possible FALSE error. A possible false is EXTREMELY damaging to new gns3 users because they go in an change stuff; that should be expected from new gns3 users. My code is looking for a factor of 4 to protectnewgns3 users. |
Beta Was this translation helpful? Give feedback.
-
I see no rational reason why the gns3 developers should associate with powershell. |
Beta Was this translation helpful? Give feedback.
-
@eantowne thanks for this post, totally agree 👍 |
Beta Was this translation helpful? Give feedback.
-
New windows gns3 users can not handle troubleshooting the local server option because they do not know if it is windows, the gui, or the server. They go to the internet and start causing trouble by turning off their firewall or try to run gns3 in admin mode or maybe start messing with their vmware vmnets. My start-gns3.ps1 starts vmware first, the gns3 vm, gns3_server.exe and then the gns3.exe "after the gns3 vm is green". The remote server option for windows, to the best of my recollection, prevents vmware vms to work - but I do not support them anyway. |
Beta Was this translation helpful? Give feedback.
-
Oh, the "initialization complete signal" is highly desirable. It is vastly superior methodology not to try to load a project until the gns3_server.exe and gns3 vm are known to be communicating; the icon for the gns3 vm is green in the gui. |
Beta Was this translation helpful? Give feedback.
-
the gns3 developers have to come to the realization that there design of starting the gns3 client before the gns3 server/gns3 vm is an incorrect design there is no way around that. Ean's point of "For those Windows users out there, my question is this,"...new windows gns3 users can not handle that question. Linux users have KVM, their hypervisor, up and running - normally - already before they start gns3. The best analogy I came up with in the last 3 weeks is that if I spend an hour driving to a store and I find the store is closed, then I am not going to break into the store - which is what the gns3 users are metaphorically trying to do. With gns3, if the gns3 client and the gns3 vm/gns3 server are not communicating, then
The hypervisor must be started first. This is a gns3 developer problem and not a gns3 windows user problem. |
Beta Was this translation helpful? Give feedback.
-
To a certain extent, I agree, kind of. In it's current state, yes, it does cause issues. However, if the Client had all "normal operations" menu items and such disabled until the connection to the Controller was established and the Controller validates that all Computes are connected, then that would solve the particular issue you are getting at.
Not really sure that "New" Windows, or any other operating system, users are really the demographic here on this GitHub repository. Along with that, previously you stated (Dec 31st, as the first response to me):
So, would this be your answer, "There is no valid use case for the "local" server on Windows?
I honestly am not sure that I agree with this sequence. I understand the logic of it, however my first comment points to a direction that could make swapping the first two viable.
Nope, sorry, I cannot get behind you on this one. Incoming Rant.... Look at the history of GNS3 and what it originally supported and the environment it ran in. GNS3 has been evolving to accommodate new technologies in the appliances, the virtualization of them, as well as the underlying Operating Systems. While there are improvements that can be made, I am NOT going to lay it at the feet of the Dev Team and walk away. You want to know where the blame starts? Head out to Redmond, WA and ask the folks in MS why their operating system is so unbelievably dysfunctional. Ask the folks and Apple why they sandbox and break everything, or why they have not turned on the nested virtualization in their Operating System for the CPU's they make that have the capability baked into them? Nothing is stopping you from switching to Linux... |
Beta Was this translation helpful? Give feedback.
-
i recommend this thread be closed |
Beta Was this translation helpful? Give feedback.
-
Cross post from GNS3 Community Post
I am going to describe a solution for solving 90% of user experienced issues when using GNS3 on Windows. The method proposed will probably be an unpopular choice. I invite discussion regarding the pros and cons of this method.
Background:
90% of the problems that user experience when using GNS3 on Windows comes down to one thing: the GNS3 "Local" server. This is a GNS3 server running in Windows. It provides a couple of very useful capabilities, such as:
The majority of issues seem to be:
GNS3 3.0 will remove the Windows GNS3 server as an option, however, development on 3.0 is still ongoing and a release date has not been determined.
Solution:
Stop using the "local" server, for anything. In fact do not even configure the desktop client to start/use the "local" server. When installing the GNS3 client or running the setup wizard, select "Remote" and enter the IP address of the GNS3 VM. Majority of problems are now solved.
Discussion:
Ok, so how do I run my Windows or some other VM that I run in VMware on the GNS3 VM? Easy, create a custom QEMU appliance in GNS3 and use the .vmdk drives, because GNS3 can use those. Ok, but what about UEFI booting? Once again, GNS3 provides a solution, the OVMF2016.fd (or something like that) is a file that can be added to a QEMU image to boot Tianocore "BIOS", which is a UEFI compatible loader. Finally, it looks like there is even a solution for TPM (I have not tested it though).
So how do I start the GNS3 VM? Open your virtualization software and start the VM. Not sure why that seems to be such an issue. I am sure that a batch file or PowerShell script could be written to start very easily.
This method works really well for the simple fact that you are removing the majority of back and forth interactions and complexity between Windows, the virtualization software and GNS3 server(s).
Discussion question:
For those Windows users out there, my question is this, what benefit does the "local" server provide you that you cannot live with out? If there was a viable alternative, would you try it?
I can think of one possible use.
You only run dynamics based images and have limited system resources, so you do not run the GNS3 VM. Fair enough, but then again, this particular use case eliminates 75% of the issues anyway as it only uses dynamics appliances. If you don't have the resources to run the GNS3 VM, you are most likely also not integrating VM's from VMware WS/Virtualbox either. It does still leave possible issues with NAT/Cloud host interactions.
Beta Was this translation helpful? Give feedback.
All reactions