Update Jul 8, 2019: The Kali Linux appliance has been updated, it now includes the persistent disk. So there is no need anymore to modify the appliance.

Kali Linux is a nice distribution for penetration testing. The Kali Linux appliance makes it easy to integrate it into GNS3. But it has one major shortcoming, you have no way to save your work. Every time you start the Kali node, you have to begin from scratch.

Kali Linux supports the use of an USB drive for storing your changes persistently. Based on that Kali documentation, this guide uses a virtual disk image for saving your changes.

Installing the Kali Linux Appliance

If you haven’t already done, you need to install the appliance.

Search in the GNS3 documentation for ‘kali’ to find the instructions for installing the Kali Linux appliance.

As SolarWinds, the company behind GNS3, doesn’t want links to the GNS3 website, I can’t give you the direct link to the documentation.

Modifying the Template

First we need to modify the template. For that open the GNS3 preferences, select the QEMU VM section and edit the Kali Linux template.

In the general settings we have to change the boot priority to CD/DVD-ROM.

QEMU General Settings

In the HDD tab we have to add a virtual disk, storing the persistence data. We are doing that by using the ‘Create’ button to start the image creator wizard:

  • Use the defaults in the next two dialogs (‘binary and format’ and ‘qcow2 options’)
  • Set ‘kali-linux-persistence.qcow2’ as file location and choose a suitable disk size, for example 1.000 MiB.
  • Finish the QEMU image creator wizard.

Furthermore change the disk interface to SATA.

QEMU HDD Settings

For the initial creation of the persistent disk we have to unmark the checkbox ‘Use as a linked base VM’.

QEMU Advanced Settings

Now exit the VM template editor with ‘OK’, then exit the preferences (again with ‘OK’).

Initialize the Persistence

From Kali’s point of view there is no difference between an USB stick and a (virtual) disk. Both devices are accessible as /dev/sd devices. So we can closely follow the Kali documentation to initialize the persistent disk.

Create a new temporary project and drag the Kali Linux template to the project area. Then start the node and open the VNC console.

In the boot menu use the default entry ‘Live (amd64)’ to start kali, then login (username root / password toor).

Now start the terminal emulator and enter the following commands:

root@kali:~# parted --script /dev/sda mklabel msdos mkpart primary 1MiB 100%
root@kali:~# mkfs.ext3 -L persistence /dev/sda1
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done
Creating filesystem with 255744 4k blocks and 64000 inodes
Filesystem UUID: ca2df9b1-1f4c-4dae-963a-87e42af76f9a
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

root@kali:~# e2label /dev/sda1 persistence
root@kali:~# mount /dev/sda1 /mnt
root@kali:~# echo "/ union" > /mnt/persistence.conf
root@kali:~# umount /dev/sda1

Then shutdown the Kali Linux VM.

Base Setup (optional)

Now we can setup the base environment for the future Kali VMs. For that start the VM and select ‘Live USB Persistence’ in the boot menu.

Kali Persistence

Then login and setup the VM according to your preferences. When done, shutdown the VM.

Final Steps

The setup of the persistent disk is now complete, delete the temporary project (including the temporary Kali VM).

Then re-enable the ‘Use as a linked base VM’ settings in the template. For that open the GNS3 preferences, select the QEMU VM section, edit the Kali Linux template and select the ‘Advanced settings’ tab. Now mark the checkbox ‘Use as a linked base VM’, then exit the VM template editor with ‘OK’, finally exit the preferences (again with ‘OK’).

QEMU Linked Base

Now the persistent disk is ready for normal use. Just boot with the ‘Live USB Persistence’ option.

As you are now using a disk with a linux file system, refrain from just stopping the VM. Use shutdown instead to cleanly stop the VM.