Using VirtualBox linked clones in the GNS3 network simulator

GNS3 1.3 will create and manage VirtualBox virtual machine linked clones from within the GNS3 user interface. This simplifies the process of setting up VirtualBox virtual machines in GNS3, which makes GNS3 easier to use for studying the operation of open-source routers, switches, and hosts in network simulation scenarios.

In this post, I will show how to set up and use VirtualBox linked clones in your GNS3 simulation scenarios and work through a detailed tutorial.

VirtualBox linked clones

A VirtualBox linked clone is a virtual machine whose virtual disk links to another virtual machine’s virtual disk and saves only the differences in files and data compared to the linked virtual machine. This saves disk space on the host computer.

For more information about the technology used to create linked clones, research Copy on Write (COW) filesystems.

To create a linked clone, you must have a base virtual machine that will be cloned. This base VM is a normal virtual machine managed by VirtualBox. To create a linked clone in the VirtualBox Manager, right-click on a VM and select Clone from the menu that appears. Give the clone a name, then click the Next button. In the next window, select the Linked clone radio button and click Clone.

GNS3 integrates with VirtualBox to management of linked clone VMs. Once it is properly configured, GNS3 will do the work of creating a new VirtualBox linked clone from a base VM every time a node is dragged onto the GNS3 network topology panel. GNS3 will save the clone’s filesystem in the GNS3 project folder.

Benefits of using linked clone VMs

In this post, we show how using VirtualBox linked clones simplifies using VirtualBox virtual machines in GNS3. I found that using linked clones works well, provided one avoids the terrible Save As bug (see below).

Let’s review the benefits of using VirtualBox linked clones in GNS3.

Linked clones simplify GNS3 device management

Most GNS3 users will create many virtual machines in VirtualBox to create multiple instances of each type of node that they plan to use in their simulation. If users are working a large project, or on more than one project, the number of VMs they create may grow to the point that they become hard to manage in the GNS3 devices dock.

GNS3 integration with VirtualBox linked clones allow users to treat VirtualBox VMs in the GNS3 Devices dock as a “device type” that may be used multiple times, instead of as a unique device that may only be used once. This greatly reduces the number of virtual machines managed in the GNS3 Devices dock.

Linked clones prevent overwriting filesystems

Normally, VirtualBox VM filesystems — or virtual disks — are saved in VirtualBox, not in the GNS3 project folder. Nothing prevents more than one GNS3 project from accidentally using the same VirtualBox VM. This can cause a lot of confusion if the VM needs to be configured diffently in each project.

The filesystems of VirtualBox linked clones created by GNS3 1.3 are saved in the GNS3 project’s folder. When a user saves a project, the configuration of each linked clone VM is saved with the project and will not be written over by another project.

How to create base VirtualBox virtual machines

Linked clone virtual machines are linked to a base virtual machine. To demonstrate how linked clones are set up and used in a GNS3 simulation, we must first create the base virtual machines.

In the example below, we create two virtual machines names Router and Host that will be the base virtual machines used later in our tutorial.

Download appliances

An easy way to add routers and hosts based on open source software to your GNS3 simulations is to use appliances prepared by the GNS3 community.

In this example, we will use appliances based on CORE Linux that were created by a GNS3 community member named Radovan Brezula and are available on his Brezular blog download page.

We choose to use the two appliances that are based on the Core Linux 6.3 distribution:

• We will use the Linux Core network host 6.3 x86-64 appliance to create the Host device.
• We will use the Linux Core 6.3 x86-64 with Quagga and Open vSwitch appliance to create the Router device.

Download the appliances’ VMDK files to a folder on your computer. The VMDK format is a VMware virtual disk format, but VirtualBox can open it.

Other VirtualBox appliances are located in the GNS3 Appliance Marketplace.

The Router virtual machine

First, we will create a virtual machine that will serve as the base VM for all Router linked clone VMs in GNS3.

Start VirtualBox and then click the “New” icon in the VirtualBox VM Manager window to start the Create Virtual Machine wizard. In the dialogue box, enter the name “Router”. The VM Type is “Linux” and the Version is “Other Linux”. Then, click “Next”. Set the memory size to 512 MB. This can be changed later if we need to. Click “Next”.

Choose the option to “Use an existing virtual hard drive” and then select the appliance’s VMDK file we downloaded earlier: CorePure64-6.3-openvswitch_2.4.90-quagga_0.99.24.1-bird_1.5.0-keepalived_1.2.19.vmdk.

Click “Create”. The virtual machine Router is now created in VirtualBox.

The Host virtual machine

Next, we will create a virtual machine which will be used as the base VM for all Host linked clone VMs in GNS3. Repeat the steps we used to create the Router virtual router with the following changes:

• The VM name is Host
• The memory can be reduced to 128 MB
• The appliance image is CorePure64-6.3-host.vmdk

Now, we should see two virtual machines in the VirtualBox window: Router and Host.

Set up VirtualBox devices in GNS3

To use the VirtualBox devices, Router and Host, in GNS3 simulations we must create GNS3 virtual machine templates for them. Create and edit the virtual machine templates in the GNS3 Preferences panel and choose a device symbol that best represents the function to be provided by the virtual machine in the GNS3 simulation. We show how to do this below.

Create GNS3 VirtualBox VM templates

For each device type that will use a virtual machine we must create a VM template. Open the GNS3 Preferences window and select the VirtualBox VM templates panel. Then click on the “New” button to create a new VirtualBox VM template in GNS3.

The “VM List” menu will show the VMs currently set up in VirtualBox. In our example, there are two. We will create a template for each one.

Choose the Router VM and select the option: Use as a linked base VM (experimental). This enables the GNS3 VirtualBox linked clone feature.

Repeat the same process to add the Host device into GNS3. Also ensure you select the Use as a linked base VM (experimental) option.

Edit GNS3 VirtualBox VM templates

You should see two VirtualBox virtual machines in the VirtualBox VM templates panel. Select each VM and click the Edit button.

In the VirtualBox VM Configuration window, we see two tabs: General settings and Network. In the General settings tab, select all the options to enable the remote console, start the VM in headless mode, and to use as a linked base VM.

In the Network tab, set the number of interfaces each device will have. The Router device will have many interfaces (I chose eight interfaces) and the Host device will have one interface.

Check the option to Allow GNS3 to use any configured VirtualBox adapter. This will allow GNS3 to use the eth0 interfaces on each new linked clone created. If you do not check this option, eth0 on each linked clone will be NAT interface, even if you disabled that interface in VirtualBox, and will not be usable by GNS3.

NOTE: Another way to resolve the conflict is to configure more than one interface on the Host device when we set it up in the GNS3 Preferences panel, and avoiding using eth0 on any device when setting up a simulation.

Change device symbol

Lastly, change the symbol of the Router device so it looks like a router in the GNS3 devices panel. Right-click on the Router VM in the VirtualBox VM templates panel and select Change symbol.

From the symbol selection window, choose the router symbol.

Create a new GNS3 project

To show how linked clones work, we will create a new project and use the devices we created in the above steps.

Create a new project in GNS3. Click on the File → New blank project menu command, or press Ctrl–N. Enter a project name and press the OK button.

You must give the project a name and save it because VirtualBox linked clones are not supported in temporary projects. If your current GNS3 project has the title, “Unsaved project” then it is a temporary project.

Note that you cannot change the project name after you save it because the GNS3 Save as command has a major bug that will corrupt your project so you must not use Save as to create a copy of the project with a new name.

Add devices

Click on the Browse all devices icon in the GNS3 GUI. We should now see two new devices in the devices dock: the Host device, and the Router device.

The new VirtualBox devices, because they have been configures as linked base VMs, operate just like the built-in GNS3 devices like the Ethernet switch. Each time the user drags one of these devices onto the Topology window, GNS3 creates a new instance of the device with a number appended to it.

In the example shown below, we dragged the Router device onto the canvas to create three routers and dragged the Host device onto the topology window to create four hosts. We also added a switch and some links.

Then we started the simulation by pressing the green Start simulation button on the GNS3 GUI.

NOTE: We used the name “Host” for the Host VM but there is another GNS3 device that is also called Host. However, we can see that the Host we created uses the VirtualBox VM device image (a PC with a waveform image in its monitor) so it should still be possible to differetniate between the devices and choose the right one.

View linked clones in VirtualBox Manager

When starting the simulation, GNS3 asks VirtualBox to create the linked clones. Look at the VirtualBox Manager application and see all the new virtual machines created by GNS3’s VirtualBox linked clone feature.

Saving GNS3 projects that include VirtualBox linked-clone VMs

To save a project in GNS3, use the Save project command from the GNS3 menu. Never use the Save As command. See the next section below to learn why.

When a project containing VirtualBox linked clone VMs is saved, the filesystem of each linked clone VM is saved in the GNS3 project folder. These filesystems will be used to re-create the linked-clone virtual machines when the project is loaded again.

Saving filesystem changes

In our example, we are using the CORE Linux distribution in the VMs that will emulate routers and hosts in our GNS3 project. CORE Linux operates in RAM and does not write anything to disk during normal operation.

To save configuration changes in CORE Linux, you must execute the file backup command, filetool.sh -b, which will write changes to each VM’s virtual disk. After saving changes made in RAM to the VM’s virtual disk you may save the GNS3 project. If you forget to back up the VM’s RAM before saving the GNS3 project, the configuration changes will not be saved with the GNS3 project.

Before saving the GNS3 project, save your configurations by executing the following command on each device in the simulation scenario:

# filetool.sh -b

When making configuration changes in a device running CORE Linux, be aware of which files will be saved. Please read my post about persistence in CORE Linux for more information.

Configure nodes in the GNS3 project

To test the operation of the devices we created in this GNS3 simualtion, we need to configure basic networking information on the hosts and routers.

We will set up the devices’ network interfaces as follows:

Device	Interface	IP Address
Host 1	eth0	10.0.1.100/24
Host 2	eth0	10.0.2.100/24
Host 3	eth0	10.0.3.100/24
Host 4	eth0	10.0.3.101/24
Router 1	eth0	10.0.1.1/24
Router 1	eth5	10.0.105.1/24
Router 1	eth7	10.0.107.1/24
Router 2	eth0	10.0.2.1/24
Router 2	eth6	10.0.106.2/24
Router 2	eth7	10.0.107.2/24
Router 3	eth0	10.0.3.1/24
Router 3	eth5	10.0.105.2/24
Router 3	eth6	10.0.106.1/24

Each host will have a default route pointing to its router and each router will have OSPF routing enabled.

Follow the configuration steps listed below to set up the network so that each node is able to reach any other node in the network.

Host-1

Double-click on the Host-1 device to open a terminal connected to Host-1. Log in to *Host-1″. For all devices in this tutorial, the userid is tc and the password is tc.

Edit the /opt/bootlocal.sh file on Host-1:

$ vi /opt/bootlocal.sh

Add the following commands to the /opt/bootlocal.sh file:

sudo ip addr add 10.0.1.100/24 broadcast 10.0.1.255 dev eth0
sudo ip link set dev eth0 up
sudo ip route add default via 10.0.1.1
sudo pkill udhcpc

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Host-2

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following commands to the /opt/bootlocal.sh file:

sudo ip addr add 10.0.2.100/24 broadcast 10.0.2.255 dev eth0
sudo ip link set dev eth0 up
sudo ip route add default via 10.0.2.1
sudo pkill udhcpc

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Host-3

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following commands to the /opt/bootlocal.sh file:

sudo ip addr add 10.0.3.100/24 broadcast 10.0.3.255 dev eth0
sudo ip link set dev eth0 up
sudo ip route add default via 10.0.3.1
sudo pkill udhcpc

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Host-4

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following commands to the /opt/bootlocal.sh file:

sudo ip addr add 10.0.3.101/24 broadcast 10.0.3.255 dev eth0
sudo ip link set dev eth0 up
sudo ip route add default via 10.0.3.1
sudo pkill udhcpc

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Router-1

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following command to the /opt/bootlocal.sh file on Quagga-1:

sudo pkill udhcpc

Start the Quagga shell:

$ vtysh

Enter the following commands into the Quagga shell:

configure terminal
router ospf
network 10.0.105.0/24 area 0
network 10.0.107.0/24 area 0
redistribute connected    
exit
interface eth0
ip address 10.0.1.1/24
exit
interface eth5
ip address 10.0.105.1/24
exit
interface eth7
ip address 10.0.107.1/24
exit
exit
write
exit

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Router-2

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following command to the /opt/bootlocal.sh file on Quagga-1:

sudo pkill udhcpc

Start the Quagga shell:

$ vtysh

Enter the following commands into the Quagga shell:

configure terminal
router ospf
network 10.0.106.0/24 area 0
network 10.0.107.0/24 area 0
redistribute connected    
exit
interface eth0
ip address 10.0.2.1/24
exit
interface eth6
ip address 10.0.106.2/24
exit
interface eth7
ip address 10.0.107.2/24
exit
exit
write
exit

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Router-3

Edit the /opt/bootlocal.sh file:

$ vi /opt/bootlocal.sh

Add the following command to the /opt/bootlocal.sh file on Quagga-1:

sudo pkill udhcpc

Start the Quagga shell:

$ vtysh

Enter the following commands into the Quagga shell:

configure terminal
router ospf
network 10.0.105.0/24 area 0
network 10.0.106.0/24 area 0
redistribute connected    
exit
interface eth0
ip address 10.0.3.1/24
exit
interface eth5
ip address 10.0.105.2/24
exit
interface eth6
ip address 10.0.106.1/24
exit
exit
write
exit

Save changes to the filesystem and reboot:

$ filetool.sh -b
$ sudo reboot

Save the GNS3 project

Save the GNS project by clicking the File → Save project menu command or press Ctrl–S.

Linked clones and Filesystems

We previously saw that the GNS3 integrates with VirtualBox to create linked clone VMs when new nodes are created in a GNS3 simulation scenario.

Linked clones use the VirtualBox snapshot feature to create the filesystems they use. When GNS3 creates a new node, it tells VirtualBox to create a snapshot of the linked base VM in a new folder inside the GNS3 project folder. A snapshot saves only the differences between the base VM’s filesystem and the new filesystem.

In the VirtualBox Manager, look at one of the nodes running in the GNS3 simulation. For example, we will look at the Host-1 VM. Click on Settings and look at the General settings’ Advanced tab. You will see the Snapshot folder used by the linked clone VM.

When you drag a Router or Host device onto the GNS3 simulation, VirtualBox creates a new linked clone in Powerer Off state. If you start the device in GNS3, VirtualBox will change its state to Powered On.

If you stop and then delete the device from GNS3, VirtualBox will remove the linked clone from the VirtualBox Manager window.

Managing virtual machines

One benefit of using linked clones is that VirtualBox Manager does not get filled up with copies of VMs used in your various GNS3 projects. Only the base VMs are kept in the VirtualBox manager after a GNS3 project is closed, or after you quote GNS3.

You must never modify the based VMs because that could cause unexpected problems with the linked clone VMs.

When you quit GNS3, or when you open a new blank project, you should see VirtualBox clear all the linked clones it is currently managing, leaving only base VMs in the VirtualBox manager.

In the example above and below, we opened a new blank project (after ensuring we saved our existing project) so GNS3 tells VirtualBox to remove all the linked clone VMs it doesn’t need, anymore.

Since there are no devices in the new project yet, VirtualBox manager shows only the base VMs and no linked clones.

Unique filesystems for new projects

In the new project we can create new devices and they will re-use the numbering system so the first host will be named Host-1 and the first router will be named Router-1. But, because the snapshots for these new linked clones are saved in a different project folder, they do not overwrite the filesystems for the devices we created in the previous project even though the device names appear to be the same.

Load the GNS3 project again

Now we will reload the previous project, named Project-01 in this example. We see that VirtualBox manager will create new linked clone VMs and that each new linked clone will use the filesystem snapshot file saved in the GNS3 project file, which means it will start with any configurations that were created and saved in the GNS3 project named Project-01.

Click on the File → Open project GNS3 menu command or press Ctrl-O. Then open the GNS3 project folder and select the project file. Click Open

Now we see the GNS3 project topology and all the linked clones created in VirtualBox manager.

When we start the project, can verify that all the saved configurations are restored by running a ping command to test communication between Host-1 and Host-4 in GNS3. Double-click on host-1 in the GNS3 topology window, log into Host-1 from the terminal window and start the ping command. We should see zero packet loss.

we have seen that the VM filesystem snapshots saved in the GNS3 project folder are used to create the linked clone VMs in a saved project when it is loaded into GNS3.

The terrible Save As bug

We mentioned in several steps above that you must never use the Save As GNS3 menu command to rename or copy a project that uses GNS3 VirtualBox linked clones.

Due to a bug in GNS3 1.3, the GNS3 project Save As command is terribly broken when linked clones are used, and will corrupt the virtual disks for all virtual machines used in the project.

The Save As bug will destroy both the original project and the new project created by the Save As command so it can really ruin your day. Fortunately, it is easy to avoid: just never use the Save As command if you use VirtualBox virtual machines in your simulation project.

The Save command still works

Users may save a GNS3 project that uses GNS3 VirtualBox linked clones by using the “Save” menu command. After a project has been saved for the first time, users can save changes to the project by using the Save command again.

However, users cannot rename the GNS3 project or create a copy of it because the Save As command will corrupt the GNS3 project.

Details of the problem

The GNS3 Save As command does not yet account for the way GNS3 manages virtual disks for its virtual machines. The Save As command will create duplicate disk IDs, called UUIDs, and break the virtual machines used in the saved project. See the VirtualBox user guide for more information about how VirtualBox registers UUIDs.

Conclusion

We set up a VirtualBox VM to be used as a linked base VM for linked clones created by GNS3. We saw how GNS3 1.3 integrates with VirtualBox to make it easy to use VirtualBox VMs in your network simulation scenarios.