KVM vs VirtualBox — Kali Docker Toolbox

Scenario

My main Linux machine AKA the MintBookPro was being used for two different purposes:

1. Running Open WebUI for local AI.
2. Running a full Kali Linux virtual machine for cybersecurity testing.

The problem was that the virtualisation requirements for these two workflows conflicted.

Open WebUI was tied into a Docker setup that relied on KVM, while the Kali VM was being run through VirtualBox. KVM and VirtualBox both wanted access to the machine’s hardware virtualisation features. They could not comfortably use them at the same time.

This created an awkward workflow. If I wanted to use the full Kali VM, I had to release KVM so VirtualBox could use the hardware virtualisation extensions. If I wanted to return to the Docker/Open WebUI environment, I had to reverse the process and make KVM available again.

A pair of scripts became the workaround:

KVM enabled
    ↓
Docker / Open WebUI available
    ↓
Release KVM
    ↓
VirtualBox can run Kali
    ↓
Stop VirtualBox
    ↓
Re-enable KVM
    ↓
Docker / Open WebUI available again

It worked, but it meant that simply wanting access to Kali tools could require changing the underlying virtualisation state of the machine.

---

The original approach: full Kali VM

My normal cybersecurity workflow had been to start a complete Kali Linux virtual machine.

That gave me:

• a complete Kali operating system
• Kali desktop environment
• dedicated virtual networking
• isolated filesystem
• allocated RAM and CPU
• the complete Kali software ecosystem

This made sense when Kali was treated as another computer in the lab.

The disadvantage was that a full VM was relatively expensive in resources and depended on the virtualisation layer being available. On MintBookPro this became particularly inconvenient because using VirtualBox could interfere with the KVM-based environment supporting Docker and Open WebUI.

---

The change in approach

The solution was not to find a more complicated way of switching between KVM and VirtualBox. Instead, I changed the role of Kali. Rather than using Kali as a complete operating system every time, I created a Kali Docker CLI toolbox. The Kali Docker container gives me a Kali userspace containing the security tools I need without running another complete virtual machine.

The normal workflow became:

docker start kali-toolbox
docker exec -it kali-toolbox bash

On the current MintBookPro configuration the Kali container lives in the Docker Desktop context, so the explicit commands are:

docker --context desktop-linux start kali-toolbox
docker --context desktop-linux exec -it kali-toolbox bash

I now enter a Kali shell rather than booting a Kali computer.

---

Does it Work?

Well yes! I still need cheat sheets but as it stands most of the cybersecurity tasks I was using Kali for were command-line activities anyway.

Examples include:

nmap
nikto
hydra
whois
dig
netcat
traceroute
Metasploit CLI
other reconnaissance and testing tools

Even more importantly, many of the main cybersecurity tools are already installed natively on Linux Mint. This means there are now effectively three levels available:

Linux Mint native tools
        │
        ▼
Kali Docker CLI toolbox
        │
        ▼
Full Kali virtual machine

The lightest appropriate option can be selected for each task.

Native tools

Use Linux Mint directly when the required tool is already installed.

Examples:

nmap
whois
dig
burpsuite
traceroute
wireshark

There is no reason to start another operating environment just to run these.

Kali Docker toolbox

Use the container when I want the Kali environment or Kali-specific tooling without needing a complete virtual machine.

docker --context desktop-linux exec -it kali-toolbox bash

This gives me a disposable, isolated security-tool environment with very little overhead. The VM remains available if I genuinely need a complete Kali environment. Using the fullsized VM now the exception rather than the default.

---

Resource difference

A full VM requires resources to be allocated to an entire guest operating system:

Host Linux
├── Host applications
├── Docker / Open WebUI
└── Kali VM
    ├── Linux kernel
    ├── system services
    ├── desktop
    ├── virtual disk
    └── security tools

A Kali container is much smaller conceptually:

Linux host kernel
├── Open WebUI container
└── Kali toolbox container
    └── security tools

The container consumes resources when the tools actually need them rather than reserving several gigabytes of RAM for an entire guest desktop. This is particularly useful on older hardware like mine.

---

Docker Learning

This was one of the points where the distinction between containers and virtual machines became real. I originally thought in terms of that I need cybertooling so I must run Kali.

The container approach changed that to one of just needing to add the Kali base tooling to my own operating environment. Docker let me to package the environment without necessarily virtualising the whole computer.

---

Current System Configuration

The MintBookPro can now support several roles simultaneously:

MintBookPro
│
├── Quartz publishing
│   ├── Node
│   ├── npm / npx
│   └── Git publishing workflow
│
├── Local AI
│   └── Open WebUI
│
├── Native cybersecurity tools
│   ├── Wireshark
│   ├── Nmap
│   ├── Burp Suite
│   └── supporting CLI utilities
│
└── Kali Docker toolbox
    └── additional Kali CLI tooling

---

Key lesson

The solution to the KVM/VirtualBox problem was ultimately not another virtualisation tweak. It was an architectural change. Instead of repeatedly switching MintBookPro between two competing hypervisor requirements, I reduced the number of tasks that actually required a hypervisor.