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:
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.
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.
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.
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.
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.
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.