Launching GNS3 should auto-launch VirtManager and open GNS3VM; just like in VMware and VirtualBox.

[PranavBhattarai]

Is this something due to the lack of some features in VirtManager or is this something we need to do inside GNS3?

I'm curious. It would have been a time savior if VirtManager auto-launched itself whenever I open GNS3 (especially when the user uses GNS3VM), and it makes sense to do. This is not a new thing/feature since this is done without any user intervention in the case of VMWare and VirtualBox. I was wondering why this is not the same case for VirtManager?!

[cristian-ciobanu]

Virt-Manager is only available only for Linux platform and not for Windows natively (can be installed only by enabling WSL which will add complexity to the setup).
Also if I remember GNS3 does not use libvirt API for managing Qemu VMs, but instead is uses the Qemu commands so I do not see any useful usecase for using VirtManager with GNS3.

[josephmhiggins]

There was a long ago post in the gns3.com community board by Julien Duponchelle, one of the gs3 developers, that libvirt/virt-manager/virtmanager was chosen no to be included in gns3 because it did not provide cross-platform support.

[eantowne]

I would add that, there may have been some assumption that since the GNS3 VM was created partially specifically for Windows/Mac OS and Type 1 hypervisor use, that Linux users would be using the native GNS3 installation.

There are some use cases to justify using the VM on a Linux based system however. In such cases, I would rather specify that should there be a need to launch the VM by starting the client, then there is actually no need to start virt-manager, as it is not needed to start nor control the VM. This will create a bit of code in the desktop client that is absolutely not cross platform in intent or functionality.

Personally, I think simply creating documentation explaining how to use the KVM version of the GNS3 VM on Linux desktop implementations should be enough. I think more focus needs to be on using the GNS3 server as an installation/use case as I continually interact with people that think they need the VM on Linux in order to get full functionality.

[josephmhiggins]

"I continually interact with people that think they need the VM" - you are not going to fix that easily. People google stuff and do not go to the gns3 community board.

"There are some use cases to justify using the VM on a Linux based system" - agreed - only in a high security context - because of Dockers. But this is not going to last long because computers have so much more power and much more ram then when I started using gns3. In other words, 5 years from now, the handicap of using the gns3 vm will be meaningless. I started with a 4G laptop that cost $300 and now I have a server that has 384Gig. So, I prefer the GNS3 VM in the future because I think that ram and cpu will outpace the VMs created by OEMs; the VMs created by OEMs seem to be growing and not shrinking (this primarily affects the gns3 export project which is definitely not optimized for Windows).

"Personally, I think simply creating documentation explaining how to use the KVM version of the GNS3 VM on Linux desktop implementations should be enough." - you are HIRED.

I think I can optimize the export project for Windows,....... next year. I can not hurt gns3 by optimizing that.

I do not know what you mean by:
"I would rather specify that should there be a need to launch the VM by starting the client"

My framework is going along quite nicely and we will have to wait for gns3 3.0.
But my windows 10 framework starts in order:

gns3 vm
backup-appdatagns3
gns3server
watch-oncreate gns3server.log
watch-onchange gns3server.log
send to kiwi
gns3gui
and this is where I am now
watch-oncreate gns3gui.log
watch-onchange gns3.gui.log
send to kiwi
and i have a major problem with exceptions.log because it is misnamed and it is new and just noticed it

backup-appdatagns3

My framework is so vastly superior to gns3 < 3.0.
On Windows 10, the GNS3 VM should be started first in gns3 < 3.0
On Windows 10, gns3server.exe should be started after the gns3 vm in gns3 < 3.0
On Windows 10, the gns3 client, gns3-gui.exe must be started last.

The watch-oncreate/watch-onchange are very, very, very tricky.

[eantowne]

@josephmhiggins

I do not know what you mean by:
"I would rather specify that should there be a need to launch the VM by starting the client"

then there is actually no need to start virt-manager, as it is not needed to start nor control the VM.

The important part is the rest of the sentence. Virt-manager is not needed to start and control the GNS3 VM on Linux. Like a lot of things in Linux, the GUI of virt-manager is nothing more than a front-end to a bunch of command-line utilities. The VM can be started and run just fine without virt-manager, and can be completely controlled via CLI. Same basic concept as how GNS3 starts, runs and controls Qemu appliances in the GNS3 VM.