It is currently Thu Jul 18, 2019 11:13 am


All times are UTC




Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Wed Jun 26, 2013 6:26 pm 
Offline
Site Admin

Joined: Sat Oct 11, 2008 1:41 pm
Posts: 2668
Location: Canada
Hi Guys,

Thanks for all the bug reports/suggestions. The final version is gonna be released in about one week from now and will stay for all summer or winter for our friends down under ;)

I encourage you to test as many things as possible.

Thanks!



_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Thu Jun 27, 2013 10:49 am 
Offline

Joined: Fri Mar 05, 2010 11:33 am
Posts: 1494
Location: Australia
@Jeremy. Looking forward to it.

I have 4 items that I'd like you consider before casting the final commit:

Item 1: Fix the UDP incrementation error bug
Item 2: Fix the Auto-calculate idle-pc bug
Item 3: Qemu defaults need restoring
Item 4: Clear up some confusion over saving startup configurations by
a: - removing the [x] Save IOS startup configs
b: - always saving Qemu FLASH drives - in ~/GNS3/Projects/<ProjectName>/QemuFlashDrives.

Details:

Item 1: UDP incrementation error bug

From my testing, the most serious bug that I've come across is the UDP incrementation error bug. topic6396.html. I wonder if this is the cause of at least some of the 151 other "206-unable to create UDP NIO" errors reported on this forum. I hope this is corrected before final release.

Item 2: Auto-calculate idle-pc bug

Not so serious - but nice to get fixed, is the bug that prevents you from doing the auto-calculate on the idle-pc if the hypervisor is bound to 0.0.0.0 (actually, I think it is if it is bound to anything other than 127.0.0.1) ( topic6518.html ).

Item 3: Qemu default settings have changed

This is fairly straightforward I think. I've been playing with Qemu/ASA/Junos a bit lately, and had a lot of trouble with RC4, until I realised that the default NIC model for Qemu is now rlt8139. (it used to be E1000) It would seem to me that if we are assuming that the "preferred" Qemu version is 0.11, then the default NIC should be E1000.

And while on defaults, can you change the default RAM for the Junos settings to 512MiB rather than 96MiB?

Item 4: Confusion over saving startup configurations
Solution: Change the New Project dialogue - remove [x] Save IOS startup configs
Supplementary Solution: Save Qemu (inc ASA/Junos...) FLASH files

This is a bit of a philosophical one. As I said, I've been playing with Qemu/ASA/Junos a bit lately, and it has occurred to me that (esp since topic6512.html issue got fixed) when a user starts a project using ASAs or Junos (or any Qemu device) there is no indication on the New Project dialogue as to the fact that s/he needs to check the [x] Save nvrams and virtual hard drives.. option to ensure that their configs are saved. This has got me thinking about the whole gamut of saving options we have, and well... here are some thoughts.

1. Since embracing the concept that in GNS3 we work with "Projects", I wonder if there is any point in having the [x] Save IOS startup configurations option at all. Why not just make it the default? Always create a configs directory! Always save the configs - they don't take much room, and would probably remove a lot of confusion.

Honestly, can anyone give me a good reason why you would NOT want this option checked? If you think you do, let me know, but I reckon I have a counter argument.

Solution: Remove the [x] Save IOS startup configurations option from the New Project dialogue

2. Back to Qemu/ASA/Junos etc. The same argument applies. If you go to the trouble of creating a project and adding a Qemu device and saving the project, then you will want the same config on your ASA/Junos/Qemu box next time you load the project.
In the current form, if you have a device called say JUNOS1 in one project and you DIDN'T check the [x] Save nvrams.... option, then you create another project with another JUNOS1, then the second image will overwrite the first - then later when you go back to the first project, JUNOS1 suddenly has the config that the JUNOS1 from the second config. How confusing is that????

I think this is an untenable and completely confusing situation.

Solutions? I see two (or three) approaches:

Solution A: Maintain the status quo - but change Qemu default working directory.

The status quo is that unless you check the [x] Save nvrams option, all Qemu FLASH files get saved in the Qemu Working directory (which is by default the temp directory - which will probably get emptied every now and again). If a user wants to maintain a collection of Qemu devices, currently s/he has to change the Qemu working directory something other than /tmp, and then make sure that they use different names for their Qemu devices in different projects.

This requires a sophisticated user who can remember what names have been used in what topologies, BUT if they go to that much trouble it is possible for them to maintain a fleet of Qemu images with different names - which could be useful. I may have a Qemu device called Micocore1 that I use in many labs, always using IP address 10.1.1.1/8. Using this approach, this could be done (see how below - improvement 2), and is similar in approach to the way today's user does with VirtualBox images - except VirtualBox images DON'T get saved in the /tmp directory by default!

This solution is basically the "do nothing" solution - but we should look to making a couple of improvements:
1. Change the default working directory for Qemu to something else more permanent. I suggest a directory like ~/GNS3/QemuHostFlashDrives. This much could be done before release of 0.8.4
2. When a user places a Qemu host (or ASA or Junos...), in a topology, or if such a device is ever given a name change, a check is made of the Qemu working directory, and a warning issued that "A flash drive for a device with the name XXXX already exists in your Qemu Working directory. Use this flash drive or overwrite? [Use Existing] [Overwrite]". Perhaps this enhancement can come later.

One of the disadvantages of this approach is that Qemu FLASH files will not get deleted if you delete a project. And even if improvement 2 is implemented, you can still clobber a FLASH file that holds the configuration for another Project. For that reason, I prefer solution B.

Solution B: The user friendly approach. (My preferred approach)

Always save the FLASH files (which is kind of what was happening before I opened my big mouth and reported topic6512.html). In other words, saving the Qemu FLASH files should be automatic - no questions asked. Same philosophy as I argued about IOS configs. The problem is of course is that these files can be quite large - 120MB or more. I don't have an answer for that except to say that it is better than trying to maintain a fleet of QEMU images in the Qemu working directory, each with a different name. But it does mean that if I decide to delete a project directory from my hard disk, I delete the Qemu FLASH files too, so I guess it is even.

To implement this solution, all we need do is "undo" what was done in RC4 - I think RC3 was actually working like this.

One little request though - can the Qemu FLASH files be put in a different directory other than the "working" directory. I would suggest a new directory, such as ~/GNS3/Projects/<ProjectName>/QemuFlashDrives. It would get created the moment a user added a Qemu device to the topology. This would keep

Solution C: Hybrid. If we need to keep everybody happy

1. Change the default working directory for Qemu to ~/GNS3/QemuHostFlashDrives.

2. Include a new option in Preferences | Qemu | General Settings.
Code:
Keep Qemu flash drives: (o) with project data
                       (  ) in Qemu working directory

IF someone DOES check the "Qemu working directory" option, then point 2 of Solution A follows - warn them of name clashes.

(I guess an alternative would be to put the above choice in the New Project dialogue, so you get to choose every time, or it could be reduced to a single option:
[x] Keep Qemu flash drives with project data)

Summary:

Item 1: The UDP incrementation error bug needs fixing
Item 2: Auto-calculate idle-pc bug needs fixing
Item 3: Restore E1000 as the default interface for Qemu devices: Set the default RAM for Junos to 512 MiB.
Item 4:
A. The "New Project" dialogue should have the [x] Save IOS startup configurations REMOVED - configs are ALWAYS saved
B. Qemu FLASH drives are ALWAYS saved - no questions asked
C. The location of the saved flash drives be changed from the working directory to ~/GNS3/Projects/<ProjectName>/QemuFlashDrives.
[optionally also include an option to continue doing things the way they are now. But I'd prefer not to have this option]

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Thu Jun 27, 2013 11:16 am 
Offline

Joined: Thu Jul 26, 2012 11:19 pm
Posts: 143
Location: U.K.
I'd like to add a bug relating to some hypervisors/wrappers not binding to the correct hostnames/addresses.

I downloaded a fresh copy of RC4 standalone and unzipped into a folder. gns3.ini is empty.
Start GNS3, exit GNS3 then a gns3.ini is created.

Check gns3.ini for hypervisor and wrapper bindings:
Code:
[Dynamips]
hypervisor_manager_binding=127.0.0.1

[Qemu]
qemu_manager_binding=127.0.0.1

[VBox]
external_hosts=localhost:11525
vbox_manager_binding=127.0.0.1


In the case of W7, W8 localhost resolves to the IPv6 address ::1 rather than IPv4 127.0.0.1, this is probably the case with most recent OS's that have an IPv6 stack. This may explain some reports that folks are unable to connect to VB VMs.

Can I suggest that everything is set to a default of 127.0.0.1? Possibly also a mention of this in the tutorials?

HTH,
Nick.

_________________
GNS3 0.8.4 running on Windows 8.1
GNS3 0.8.4 running on CentOS 6.5


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Thu Jun 27, 2013 11:34 am 
Offline

Joined: Fri Mar 05, 2010 11:33 am
Posts: 1494
Location: Australia
@NickBee Yes - I noticed that on Linux too - forgot to mention it.

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 4:31 am 
Offline
Site Admin

Joined: Sat Oct 11, 2008 1:41 pm
Posts: 2668
Location: Canada
Quote:
Can I suggest that everything is set to a default of 127.0.0.1? Possibly also a mention of this in the tutorials?


This is confusing, everything is already set to 127.0.0.1 by default... or not !?

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 6:25 am 
Offline
Site Admin

Joined: Sat Oct 11, 2008 1:41 pm
Posts: 2668
Location: Canada
@rednectar

Quote:
Item 1: The UDP incrementation error bug needs fixing
Item 2: Auto-calculate idle-pc bug needs fixing
Item 3: Restore E1000 as the default interface for Qemu devices: Set the default RAM for Junos to 512 MiB.


Fixed/changed :)

Item 4 is more sensitive...

Quote:
1. Since embracing the concept that in GNS3 we work with "Projects", I wonder if there is any point in having the [x] Save IOS startup configurations option at all. Why not just make it the default? Always create a configs directory! Always save the configs - they don't take much room, and would probably remove a lot of confusion.

Honestly, can anyone give me a good reason why you would NOT want this option checked? If you think you do, let me know, but I reckon I have a counter argument.

Solution: Remove the [x] Save IOS startup configurations option from the New Project dialogue


I agree, however I have to check if this is safe to do it for the next release.

Quote:
Back to Qemu/ASA/Junos etc. The same argument applies. If you go to the trouble of creating a project and adding a Qemu device and saving the project, then you will want the same config on your ASA/Junos/Qemu box next time you load the project.
In the current form, if you have a device called say JUNOS1 in one project and you DIDN'T check the [x] Save nvrams.... option, then you create another project with another JUNOS1, then the second image will overwrite the first - then later when you go back to the first project, JUNOS1 suddenly has the config that the JUNOS1 from the second config. How confusing is that????

I think this is an untenable and completely confusing situation.


I think overwriting is not possible because GNS3 always have a project, even if you haven't created one yourself. GNS3 uses a temporary project with a random working directory path. However, I agree something needs to be done.

Out of the 3 proposed solutions, I would also prefer solution B. But as I said, this is very sensitive and I could easily break something just before the final release. I'll see what I can do, I don't guarantee this is gonna be implemented soon.

Cheers,

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 7:22 am 
Offline

Joined: Fri Mar 05, 2010 11:33 am
Posts: 1494
Location: Australia
@Jeremy

Re Nickbee's mention of "default of 127.0.0.1" - he was referring to the fact that in gns3.ini, there is still a binding to "localhost" rather than "127.0.0.1"
Quote:
[VBox]
external_hosts=localhost:11525
vbox_manager_binding=127.0.0.1


Quote:
I think overwriting is not possible because GNS3 always have a project, even if you haven't created one yourself. GNS3 uses a temporary project with a random working directory path. However, I agree something needs to be done.


With Qemu/ASA/Junos - GNS3 does not necessarily create a working directory for a project - the FLASH files get put in the qemu working directory if you Don't check [ ] Save nvrams and start building a newtork with ASAs (I think it did in RC2 or RC3 - and I now believe that was a GOOD idea) so it IS possible to overwrite files.

The thing is - how would anyone ever guess that you'd need to check [x] save nvrams.... to save the configs for an ASA? - I mean - they already ticked [x] Save IOS startup configs? You know and I know that "Well... actually to save ASA configs you have to check [x] Save nvrams..... " - which infers "and you mister user are an idiot for thinking that IOS configs meant ASA configs".

I figure the simplest way to save confusion is to ALWAYS save the configs - both for Cisco/dynamips and ASA/qemu. It is just weird that the [x] save nvrams is used for TWO completely different purposes - if I have a topology that has BOTH ASAs and cisco routers (fairly common) then I MAY wish to save ASA configs but NOT my cisco working files. (Hence my idea that Qemu working directory should be something else.

I agree that the this needs a cleanup - not this version - but consider this for this version:

a) Remove the [x] Save IOS configs option. Just do it
b) Play it like it was for ASA/Qemu back in RC2/RC3 when there was ALWAYS a working directory created when you created a project

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 9:51 am 
Offline

Joined: Fri Dec 02, 2011 2:12 pm
Posts: 120
Location: Paris
rednectar wrote:
Summary:

Item 1: The UDP incrementation error bug needs fixing
Item 2: Auto-calculate idle-pc bug needs fixing
Item 3: Restore E1000 as the default interface for Qemu devices: Set the default RAM for Junos to 512 MiB.
Item 4:
A. The "New Project" dialogue should have the [x] Save IOS startup configurations REMOVED - configs are ALWAYS saved
B. Qemu FLASH drives are ALWAYS saved - no questions asked
C. The location of the saved flash drives be changed from the working directory to ~/GNS3/Projects/<ProjectName>/QemuFlashDrives.
[optionally also include an option to continue doing things the way they are now. But I'd prefer not to have this option]

OK to all proposals, except for the location of Qemu Flash drives which are related to device configuration: "<ProjectName>/configs/<DeviceName>" seem more appropriate

_________________
A Collection of GNS3 Labs: https://learningnetwork.cisco.com/message/232820
i7 4700MQ quad-core 2.6 Ghz and 16 GB RAM
CCNA - CCDA
Beta Test Team
GNS3 0.8.6 on Windows 7 64 bits
GNS3 0.8.6 on Ubuntu 13.10 and Qemu 1.5.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


Last edited by actionmystique on Fri Jun 28, 2013 10:44 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 10:41 am 
Offline

Joined: Fri Mar 05, 2010 11:33 am
Posts: 1494
Location: Australia
@ actionmystique. Are you suggesting that we keep the configuration files in the "configs" directory rather than the "working" directory? Brilliant idea!

_________________
RedNectar
http://rednectar.net
@rednectarchris
GNS3 WorkBench-a VMware image of Ubuntu with GNS3 and VPCS installed and a collection of exercises/labs


Top
 Profile  
 
 Post subject: Re: GNS3 0.8.4 RC4
PostPosted: Fri Jun 28, 2013 10:45 am 
Offline

Joined: Fri Dec 02, 2011 2:12 pm
Posts: 120
Location: Paris
@rednectar: Yes, I meant exactly that.



_________________
A Collection of GNS3 Labs: https://learningnetwork.cisco.com/message/232820
i7 4700MQ quad-core 2.6 Ghz and 16 GB RAM
CCNA - CCDA
Beta Test Team
GNS3 0.8.6 on Windows 7 64 bits
GNS3 0.8.6 on Ubuntu 13.10 and Qemu 1.5.2
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 40 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group

phpBB SEO