Skip to main content
HashnodeAyush Hardeniya's CodeNotesAyush Hardeniya's CodeNotes

Command Palette

Search for a command to run...

How to Install Kali Linux on a Secondary Drive without affecting Windows & WSL Performance

Updated
•6 min read
How to Install Kali Linux on a Secondary Drive without affecting Windows & WSL Performance
A
Ayush Hardeniya
Hey, I'm Ayush Hardeniya (aka Ayush Sharma)... An engineering student who treats every coding challenge like a new level to conquer. Through daily reflections, real-world problems, and code breakdowns, I document my journey --- not just to grow, but to help others grow with me. Because honestly... I don’t code, I play it.

Current Setup (Mine):

4 disks: In PowerShell run [to check the statuss of disks]

Get-PsDrive -PSProvider FileSystem

  • C:\ consist of Home (Windows 11)

  • W:\ consist of WSL (Ubuntu + Debian)

    • Confirmation:- [PowerShell]

Target Set Up:

C:\ remains untouched, for future experimental accidents, to avoid any root windows failures

And as there’s 266 GB of space available in W:\ (in my case), we will set up Kali Linux inside W:\ only, along with WSL running in parallel but inside a VM (VirtualBox) for distributed (limited) machine load, as it operates dynamically, doesn’t immediately occupy the complete 60-80 GB required space of Kali Linux on our local machine.

1. Why won't it interfere with WSL

WSL and VirtualBox are like two different apps running on the same computer.

  • WSL (Ubuntu/Debian): Lives in a hidden utility VM managed by Windows.

  • Kali VM: Lives in a standard folder you created on W:\VMs\.

They use the same "engine" (the Windows Hypervisor Platform), so they can run at the exact same time without fighting for control of your hardware.

2. "Will it stay in that folder?"

Yes. When you extract the Kali image and "Add" it to VirtualBox, everything Kali does - every tool you install, every file you save - stays inside a single large file (usually ending in .vdi) located in W:\VMs\Kali-Linux\.

  • No Registry Bloat: It won't scatter files across your Windows C:\ drive.

  • Portability: If you ever get a new laptop, you can literally copy that W:\VMs folder to an external drive, plug it into the new PC, and your Kali setup will be exactly where you left it.

3. Potential "Troubles" to Watch For (and how to fix them)

While they won't break each other, they do share your physical resources (RAM and CPU).

  • RAM Usage: If you give Kali 8 GB of RAM and Ubuntu is already using 4 GB, and Windows needs 4 GB... your system might slow down.

    • Fix: Since you have a Home version of Windows 11, just make sure you don't run too many heavy apps (like Chrome with 50 tabs) while both Kali and WSL are active.

  • Network Conflicts: Sometimes, if you try to run a "Web Server" on Kali and a "Web Server" on WSL using the same port (like port 80), they might clash.

    • Fix: In VirtualBox, use "NAT" mode for networking. This gives Kali its own private internal IP address separate from your Windows/WSL IP.

Conclusion Glimpse:

Set Up:

To ensure VirtualBox and WSL don't fight over your CPU, run this one command in your PowerShell (as Administrator) just to be 100% sure the required Windows feature is active:

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

o/p:

So opening PowerShell and running as an administrator:

confirm again-

Now-

-> Click here for {Set-Up Steps}

Step-by-Step Execution:

  1. Install VirtualBox: Download the .exe and install it. If it asks for a location, just hit "Next" and let it go to C:\ .

  2. Redirect the Storage: * Open VirtualBox.

    • Go to File > Preferences > General.

    • Set Default Machine Folder to W:\VMs.

  3. Setup Kali:

    • Manually create the folder W:\VMs\Kali-Linux.

    • Extract your downloaded Kali .7z file into that folder.

    • In the VirtualBox app, click Machine > Add and select the .vbox file from that folder on W:.

For File > Preferences > General, you should set it to:

W:\VMs

Why not W:\VMs\Kali-Linux?

The "Default Machine Folder" is the parent folder where VirtualBox will look for all your virtual machines.

When you set it to W:\VMs, VirtualBox will treat that as the main "garage."

If you decide to install another OS later (like a Windows Server or another Linux flavor), VirtualBox will automatically create a new sub-folder for it inside W:\VMs (e.g., W:\VMs\WindowsServer).

If you pointed it directly to W:\VMs\Kali-Linux, things would get messy because VirtualBox would try to put files for other machines inside your Kali folder.

The Final Folder Structure on W:\

Once you are done, your drive will look like this:

  • W:\WSL\ (Your existing Ubuntu/Debian)

  • W:\VMs\ (The "Global" VM folder)

    • Kali-Linux\ (The specific folder where your Kali .vbox and .vdi files live)

Quick Recap of the "Add" step:

  1. Set the Preference to W:\VMs.

  2. Click Machine > Add.

  3. Open VirtualBox.

  4. In the top menu, click Machine > Add (or press Ctrl + A).

  5. A file explorer window will open. Navigate to: W:\VMs\Kali-Linux\kali-linux-2026.1-virtualbox-amd64\

  6. Look for a file ending in .vbox (it usually has a blue cube icon and might be named kali-linux-2026.1-virtualbox-amd64.vbox).

  7. Select that file and click Open.

Result: Kali Linux will now appear in the left-hand sidebar of VirtualBox.

2. Quick Hardware Check (For a CS Student's PC)

Before you hit Start, let's make sure it doesn't lag. Right-click the Kali entry in the list and select Settings:

  • System > Processor: Give it 2 or 4 cores. (Since you handle competitive programming and open-source projects, you'll want the speed).

  • System > Motherboard: Ensure it has at least 2048 MB (2 GB) of RAM.

  • Display > Video Memory: Slide this to the max (128 MB). This makes the desktop environment much smoother.

  • General > Advanced: Set Shared Clipboard to Bidirectional. This is a lifesaver for copy-pasting code/commands from Windows.

3. The "Ignition" (First Boot)

  1. Click the green Start arrow at the top.

  2. A new window will pop up. You’ll see some text scrolling - that’s the Linux kernel waking up.

  3. When you reach the login screen, enter the default credentials:

    • Username: kali & Password: kali

Result:

Welcome to Dragon Mode {Kali-Linux}:

How to Access it in future:

1. The Standard Way (GUI)

Whenever you want to start hacking or practicing your CSE labs:

  1. Open VirtualBox from your Start Menu.

  2. Select Kali-Linux from the list on the left.

  3. Click the green Start arrow.

  4. To Close it: Don't just "X" out the window like a browser. Inside Kali, click the Power icon (top right) and select Shut Down. This ensures your virtual hard drive on W: doesn't get corrupted.

2. The "Pro" Way (Save State)

If you are in the middle of a project (like a ZenYukti task or a DSA problem) and don't want to close your terminals:

  1. Click the "X" on the VirtualBox window i.e) close the VM window.

  2. Select "Save the machine state".

  3. Result: VirtualBox will freeze Kali exactly where it is and save it to your W: drive. Next time you click Start, it will "wake up" in 2 seconds exactly where you left off.

#kali-linux#wsl#kali-linux-download#cybersecurity#ayushhardeniya#windows-11

Comments (1)

Join the discussion
S
smirnovatatiana771mo ago

This is a clean setup and a solid write-up — especially the separation mindset. Keeping Windows on C:\ untouched while isolating experiments on another drive is exactly how you avoid painful rebuilds later.

A few things worth reinforcing and extending from a systems perspective:

  1. You’re effectively running two virtualization layers WSL2 already runs on a lightweight Hyper-V VM, and VirtualBox (when Hyper-V is enabled) uses the Windows Hypervisor Platform underneath. That’s why they can coexist — but performance isn’t identical to bare-metal VirtualBox. If anyone notices slower VM performance, that’s usually why.

  2. Disk isolation is your biggest win here Keeping Kali inside W:\VMs\Kali-Linux\ as a .vdi is more than just organization — it’s containment. No registry spread, no accidental writes to C:, and full portability. That’s basically treating your OS like a movable artifact, which is a very “infra-as-file” mindset.

  3. Watch dynamic disk growth Kali images in VirtualBox often use dynamically allocated disks. They don’t take full space upfront, but they will grow silently. That 60–80GB expectation can creep up if you’re installing heavy tools or wordlists.

  4. CPU/RAM contention is the real bottleneck You explained RAM well, but CPU scheduling is just as important. WSL + Kali VM + browser load can spike context switching. If things feel sluggish, limiting CPU cores in VirtualBox (instead of maxing them) often improves overall system responsiveness.

  5. Networking separation via NAT is the right call Using NAT avoids conflicts with WSL and Windows services. If someone later needs inbound access (e.g., testing a web app), they can switch to Bridged — but NAT is the safest default for isolation.

  6. Nice parallel to sandboxed systems This setup is basically a lightweight lab environment:

WSL → fast, dev-focused workloads Kali VM → heavier, security/testing workloads Windows → stable host

Different layers, different purposes, minimal interference.

Overall, this is a practical approach for anyone who wants a segmented dev + security environment without touching their main OS. Clean boundaries like this scale well — especially if you later expand into more VMs or external drives.

More from this blog

A

Ayush Hardeniya's CodeNotes

8 posts

Welcome to CodeNotes, a space where I document my daily tech learnings, code explorations, and deployment experiences.