Installing Kali Linux in a Virtual Machine

A virtual machine (VM) is the right way to run Kali Linux when you are learning. It gives you a disposable, isolated environment you can break, reset, and rebuild without touching your real workstation. In this lesson you will install Kali as a guest VM, size it sensibly for a DevOps lab, and understand the networking and snapshot options that make experiments safe to repeat.

Why a VM Instead of Bare Metal

Running Kali inside a VM keeps your host operating system untouched and gives you a clean sandbox for testing.

Isolation — nothing you do inside the VM can accidentally reconfigure your host’s network stack, firewall, or files.
Reversibility — snapshots let you roll back to a known-good state in seconds after a broken package upgrade or a misconfigured tool.
Reproducibility — you can clone, export, and rebuild the exact same lab, which is the same mindset you already use with infrastructure-as-code.
Safe experimentation — you can stand up target machines and practice scanning them without ever touching anything you do not own.

🛠️ DevOps Perspective — A VM is cattle, not a pet. Treat your Kali lab like an ephemeral CI runner: something you can destroy and recreate from a known image at any time. That habit transfers directly to how you should think about build agents, test environments, and container images.

Choosing a Virtualization Platform

Any mainstream hypervisor will run Kali. Pick the one that matches your host OS and comfort level.

Platform	Host OS	Cost	Notes
VirtualBox	Windows, macOS (Intel), Linux	Free / open source	Easiest starting point; great for beginners
VMware Workstation	Windows, Linux	Free for personal use	Strong performance, mature tooling
VMware Fusion	macOS (Intel + Apple Silicon)	Free for personal use	Best VMware option on Mac
KVM / QEMU	Linux	Free / open source	Native Linux hypervisor; fast, scriptable
Hyper-V	Windows 10/11 Pro, Server	Built into Windows	Good on Windows Pro; conflicts with VirtualBox unless configured carefully

A few platform notes worth knowing before you commit:

Apple Silicon (M-series) Macs cannot run the standard x86-64 Kali image. Use the ARM64 Kali build with VMware Fusion or UTM/QEMU instead.
Hyper-V and VirtualBox both want exclusive control of the CPU virtualization extensions on Windows. Running both at once causes VMs to fail to start. Pick one, or use the Windows Hypervisor Platform compatibility mode.
KVM/QEMU is the natural choice on a Linux workstation or a spare server and is the closest match to how cloud VMs actually run.

KVM/QEMU quick check on Linux

Before creating a KVM guest, confirm your host CPU supports hardware virtualization:

# Non-zero result means VT-x (Intel) or AMD-V is available
egrep -c '(vmx|svm)' /proc/cpuinfo

# Confirm KVM is usable and tooling is installed
sudo apt update && sudo apt install -y qemu-kvm libvirt-daemon-system virt-manager
kvm-ok

egrep -c '(vmx|svm)' /proc/cpuinfo counts CPU cores advertising virtualization support; kvm-ok (from the cpu-checker package) confirms KVM acceleration is actually enabled in BIOS/UEFI. If it reports acceleration is disabled, enable virtualization in your firmware settings.

Downloading Kali Safely

Only ever download Kali from the official Kali Linux website (kali.org). This is the single most important safety step in the whole process.

🔐 Security Note — Never install Kali from a random mirror, a torrent posted on a forum, a “pre-configured hacking VM” from a video description, or a link a stranger sent you. A tampered image can ship with backdoors baked in, and you would be giving it privileged access to your machine and network. Download the ISO or VM image only from the official kali.org download page, and always verify it before you boot it.

After downloading, verify the file matches what the Kali project published. The official site lists a SHA-256 checksum for every image. Conceptually there are two layers of verification:

Checksum (integrity) — confirms the file you downloaded is bit-for-bit identical to the published image, i.e. it did not get corrupted or swapped in transit.
Signature (authenticity) — confirms the checksum list itself was published by the Kali team and not forged. Kali signs its checksum file with a GPG key, so verifying the signature proves the checksums are genuine.

# Compute the SHA-256 of the file you downloaded...
sha256sum kali-linux-2024.x-installer-amd64.iso

# ...then compare it, character for character, to the value on the official download page.
# On Windows PowerShell the equivalent is:  Get-FileHash .\kali-...iso -Algorithm SHA256

sha256sum prints a long hexadecimal fingerprint. If it matches the value published on kali.org, the download is intact. If it does not match, delete the file and download again — do not boot it.

ISO vs Prebuilt VM Images

Kali publishes two things you can use to build your VM. Both are valid; they trade setup time for control.

Option	What it is	Best when
Installer ISO	A disk image you boot and install from, choosing partitions, users, and packages	You want to understand the install and control the layout
Prebuilt VM image	A ready-made VirtualBox/VMware/QEMU appliance you import in one step	You want to be up and running in minutes

For a first lab, the prebuilt VM image is the fastest path: download the archive for your hypervisor, extract it, and import/open it. The ISO route is worth doing once so you understand what the installer configures — pick the “Guided – use entire disk” option and accept the defaults.

💡 Note — The prebuilt Kali VM ships with default credentials of kali / kali. Change that password immediately after first boot with passwd. Default credentials are exactly the kind of misconfiguration you will later learn to look for in real infrastructure.

Sizing the VM: CPU, Memory, and Disk

Give the VM enough to be responsive without starving your host. These beginner defaults comfortably run Kali’s desktop plus the tools in this series.

Resource	Beginner default	Notes
vCPU	2	Never assign every host core; leave headroom for the host OS
Memory (RAM)	4 GB (4096 MB)	2 GB is the floor for the desktop; 8 GB if your host has 16 GB+
Disk	40 GB	Use a dynamically allocated disk so it only consumes space as needed
Video memory	128 MB	Smoother desktop; enable 3D acceleration if offered

Guidance for choosing these numbers:

CPU allocation — 2 vCPUs is plenty to learn on. A useful rule: never allocate more than about half your host’s physical cores to a single lab VM, or the host itself becomes sluggish.
Memory allocation — RAM assigned to the VM is reserved from the host while the VM runs. On a 16 GB host, 4 GB for Kali leaves plenty for your host and browser. Do not overcommit into swap.
Disk allocation — A 40 GB dynamically allocated (thin-provisioned) virtual disk grows on demand, so it might only use 12–15 GB at first. This is far safer than a fixed 40 GB file that claims all the space up front.

Sensible beginner Kali lab VM
+------------------------------------------+
|  CPU     : 2 vCPU                         |
|  Memory  : 4096 MB (4 GB)                 |
|  Disk    : 40 GB, dynamically allocated   |
|  Video   : 128 MB, 3D acceleration on     |
|  Network : NAT (default, see below)       |
+------------------------------------------+

Networking Modes Explained

The VM’s network mode decides what the guest can reach and what can reach it. This is the setting beginners get wrong most often, so understand each mode before you change it.

Mode	Guest gets internet?	Guest reachable from host?	Guest reachable from LAN?	Guests see each other?
NAT	Yes	Only via port forwarding	No	No
Bridged	Yes	Yes	Yes	Yes
Host-only	No	Yes	No	Yes (same host-only net)

What each mode actually means:

NAT (Network Address Translation) — the default and safest for beginners. The VM shares the host’s IP address to reach the internet, but the outside network cannot initiate connections to the VM. Think of it as the VM sitting behind a router that only your host operates.
Bridged — the VM gets its own IP address on your real LAN, as if it were a separate physical machine plugged into your network. Convenient for reaching other devices, but it exposes the VM directly to your network, so use it deliberately, not by default.
Host-only — creates a private network shared only between the host and its VMs, with no route to the internet. This is the ideal mode for a self-contained lab where Kali and a target VM talk to each other but nothing leaks out.

⛔ Production Warning — Do not put a lab VM in bridged mode on a corporate, office, or shared network and start scanning. On a bridged interface your traffic hits real devices you may not own or be authorized to test. For any scanning, capturing, or probing practice, use host-only (or an internal network) so activity stays inside your lab. Only test systems you own or are explicitly authorized to test.

A common, safe pattern is to give Kali two adapters: NAT for updates and package installs, plus host-only for talking to your isolated lab targets.

Snapshots

A snapshot captures the exact state of the VM — disk and, optionally, memory — at a moment in time, so you can return to it later.

Take a snapshot right after a clean install and first update, before you change anything. This is your golden baseline.
Take one before any risky change: a big apt full-upgrade, installing an unfamiliar tool, or editing system config.
Roll back in seconds if something breaks, instead of reinstalling from scratch.

# VirtualBox: manage snapshots from the command line
VBoxManage snapshot "Kali" take "clean-baseline" --description "Fresh install + first update"
VBoxManage snapshot "Kali" list
VBoxManage snapshot "Kali" restore "clean-baseline"

These VBoxManage commands take, list, and restore a named snapshot for the VM called Kali. GUI hypervisors expose the same actions through a Snapshots panel. On KVM/libvirt the equivalent is virsh snapshot-create-as and virsh snapshot-revert.

🧪 Try It — Before you install a single tool, take your first snapshot. In VirtualBox: with the VM selected, open Machine → Take Snapshot, name it clean-baseline, and confirm. Now boot Kali, run sudo apt update, break something on purpose (for example remove a package), then restore the snapshot and watch the VM return to its pristine state. That round trip is the safety net you will rely on for the rest of this series.

Guest Additions: Clipboard, Shared Folders, and Display

Installing the hypervisor’s guest tools (VirtualBox Guest Additions, VMware open-vm-tools) unlocks quality-of-life features. On Kali the VMware tools are typically preinstalled; for VirtualBox you install them into the guest.

Clipboard integration — copy/paste text between host and guest. Convenient, but see the security note below.
Shared folders — mount a host directory inside the guest to move files without a network transfer.
Better display — dynamic resolution, larger screen, and smoother rendering.

# In the Kali guest (VirtualBox), install prerequisites then the Guest Additions:
sudo apt update && sudo apt install -y build-essential dkms linux-headers-$(uname -r)
# Then: Devices -> Insert Guest Additions CD image, and run the installer from the mounted media.

build-essential, dkms, and the matching linux-headers let the Guest Additions compile a kernel module so features like dynamic resolution and shared folders work across reboots.

🔐 Security Note — Shared clipboard and shared folders punch a hole between the isolated guest and your host. For a general learning lab that convenience is fine, but if you are ever handling untrusted files or malware samples, disable bidirectional clipboard and shared folders so nothing can cross back to your host. Isolation is only as strong as the doors you leave open.

VM Isolation

The whole point of a lab VM is containment. Keep these boundaries deliberate:

Prefer host-only / internal networks for any target practice so lab traffic never reaches your real LAN or the internet.
Keep clipboard and shared folders off when working with anything untrusted.
Use snapshots as your reset button rather than reusing a drifting long-lived VM.
Never bridge a lab VM onto a network you do not control.

Recommended Kali DevOps Lab VM

A single Kali VM is enough to start, but the most useful learning setup runs a few small VMs side by side on the same host — one attacker/analyst box and a couple of realistic targets you fully own.

Host Computer
      |
      +-- Kali Linux VM
      |
      +-- Ubuntu Server VM
      |
      +-- Docker Lab VM

Why an isolated multi-VM lab is worth building:

Kali Linux VM is your inspection and troubleshooting workstation — where you run the networking, DNS, HTTP, TLS, and scanning tools from this series.
Ubuntu Server VM is a safe, owned target: practice SSH, inspect open ports, troubleshoot a web service, and validate configuration against something realistic instead of a live production system.
Docker Lab VM lets you explore container networking and stand up throwaway services to test against, mirroring how real workloads are packaged.
Put all three on a host-only or internal network and they can talk to each other while staying fully sealed off from your home or office LAN and the public internet.

This mirrors production thinking: separate roles, explicit network boundaries, and everything reproducible. Because you own every machine in the lab, you can scan, capture, and probe freely — the one place where that is always allowed. If you are already comfortable with containers, the Docker Academy is a good companion for building out that Docker Lab VM.

🔎 Troubleshooting Tip — If your new Kali VM has no internet, work through the layers in order: is the network adapter enabled and cabled (ip a should show an interface with an IP)? Is it on NAT rather than an internet-less host-only network? Can it resolve DNS (ping 1.1.1.1 works but ping example.com fails points at DNS, not connectivity)? Most “no network” reports come down to the wrong adapter mode.

Where to Go Next

You now have a safe, resettable Kali VM. Build on it with the rest of the series:

Not sure Kali is the right guest for every job? Compare it with a general-purpose distro in Kali vs Ubuntu.
Ready to assemble targets and run your first exercises? Head to the first DevOps security lab.
Want to understand what NAT, bridged, and host-only really do at the packet level? Continue with networking fundamentals.

What You Learned

Why a VM is the safe, reversible, reproducible way to run Kali — isolate your host, snapshot freely, and rebuild on demand.
How to choose a hypervisor (VirtualBox, VMware Workstation/Fusion, KVM/QEMU, Hyper-V) and the platform gotchas, including Apple Silicon and Hyper-V/VirtualBox conflicts.
How to download Kali safely from the official site and verify it conceptually with a SHA-256 checksum (integrity) and a GPG signature (authenticity).
Sensible beginner sizing — 2 vCPU, 4 GB RAM, and a 40 GB dynamically allocated disk — plus what each network mode (NAT, bridged, host-only) exposes.
Snapshots, guest additions, and isolation — take a clean baseline snapshot first, and keep clipboard/shared-folder doors closed when handling anything untrusted.