G2

Luca P.

Chief Operations Officer DEQUA Studio | Formerly CTO in MarTech

Marketing and Advertising

Mid-Market (51-1000 emp.)

6/18/2026

"Still the type-2 hypervisor I reach for when I need a clean OS in a window fast"

4.5/5

What do you like best about VirtualBox?

Snapshots are the feature I would defend hardest, and they are the reason VirtualBox sits at the center of how I test anything. Before I run an installer I am unsure about, apply a kernel update, or push a config change that might not take, I snapshot the guest first. If it goes wrong, and it regularly does, I roll the machine back to the exact state it was in moments earlier and try again. The snapshot tree means I can branch as well as rewind, so I can take a clean base, try approach A down one branch, then jump back and try approach B without the two contaminating each other. That single capability turned testing from something I did carefully into something I do quickly, because the cost of breaking a machine dropped to almost nothing.

The range of guest operating systems it will run is the next thing that keeps it in daily use. On one laptop I keep a Windows guest, a couple of Linux distributions, and the odd BSD image, and I can have the same shell script running against CentOS, Debian, and Ubuntu in the space of an afternoon without owning three machines to do it. Creating a VM is handled by a guided wizard that walks through OS type, CPU and memory allocation, and disk, so getting from an ISO to a booting machine is quick even for someone who has not done it before. For the builds I repeat, the unattended installation support, which now understands cloud-init style setups, lets me script the whole install rather than clicking through a guest's own installer every time.

Cloning is the part I lean on to avoid reinstalling the same base over and over. I build one golden image, get it patched and configured the way I want, and then clone it whenever I need a fresh instance of that environment. Linked clones share the base disk so they cost almost no extra space and spin up fast, which suits throwaway work, and full clones give me a completely independent copy when I need the new machine to outlive the original. Either way I am working from a known starting point instead of rebuilding from an ISO.

Guest Additions are what make a guest feel like part of the host rather than a sealed box. Once they are installed I get shared folders, a shared clipboard, drag and drop between host and guest, dynamic resizing so the desktop follows when I stretch the window, and proper mouse integration so the pointer is not trapped. In practice that means I move a file into a guest without standing up a network share, paste a command straight from my notes into a terminal inside the VM, and resize the window without the guest desktop staying stuck at one resolution. Recent versions added file transfer over the shared clipboard on Windows and Linux, which closed one of the small gaps I used to hit.

VBoxManage is the piece that takes it from a GUI app to something I can automate. The command-line tool exposes effectively everything the interface does, so I create, configure, start, snapshot, and destroy machines from a script, which is how I rebuild an entire lab from a file rather than clicking through dialogs for an hour. Guest Control lets me run commands inside a guest from the host, and headless mode runs a VM with no window attached, which is what I use when a machine just needs to sit there serving something while I work on the host. None of this needs a separate product bolted on. It is in the base package.

Networking is more flexible than people expect from a desktop hypervisor. The adapter modes (NAT, NAT Network, bridged, host-only, and internal) cover most of what I need to simulate a small network on a single machine. A host-only network gives me an isolated segment where several VMs talk to each other and to the host but not to the outside world, which is exactly right for building a multi-machine lab. Bridged mode puts a guest on the real LAN as if it were its own physical box when I need it to be reachable, and NAT covers the common case where a guest only needs outbound access. Because the network config is saved with the machine, the setup survives a reboot and a clone.

The cost and the licensing on the base package are hard to argue with. The core hypervisor is free and open source under the GPL, there is no account to create, and nothing is phoning home or nudging me toward an upsell, which is rarer than it should be. The same build runs on Windows, macOS, and Linux hosts, so I am not learning a different tool depending on which machine I am sitting at. For lab and personal work, paying nothing and getting this much capability sets a high bar for anything that would replace it.

The interface itself I will describe more plainly: it works. It is not the most modern thing I use, and the visual design shows its age in places, but the VM manager is clear about what state each machine is in, and the creation wizard is approachable enough that I have handed it to junior teammates and watched them get a VM running with very little hand-holding. I do not love looking at it, but it stays out of the way and does what I open it to do. Review collected by and hosted on G2.com.

What do you dislike about VirtualBox?

Graphics performance is the weakest part by a distance. The 3D acceleration is limited and inconsistent, and GPU passthrough is not a realistic option the way it is on heavier hypervisors, so any guest that leans on the GPU feels sluggish. A graphical Linux desktop with compositing turned on, or anything doing real video, is where this shows up most. For the headless and server-style guests that make up most of my work it does not matter at all, but if your use case is a smooth graphical desktop inside the VM, you will feel the ceiling. My workaround is to keep graphical guests lightweight, turn off desktop effects, and not expect video playback to be pleasant.

General performance carries the same caveat. On identical hardware it is heavier than the commercial alternatives, and running two or three VMs at once will make a modest laptop work for its living. The practical defense is discipline about resource allocation: do not over-assign RAM and CPU to machines that do not need it, and shut down the guests I am not actively using rather than leaving a pile of them idling in the background. Once I treat VM resources as something to budget rather than hand out freely, it behaves.

Guest Additions on Linux guests are a recurring source of small pain because they are kernel modules. When a guest's kernel updates, shared folders or automatic resizing can stop working until I rebuild the modules against the new kernel, and if the matching kernel headers are not installed the rebuild fails with an error that is not obvious to a newcomer. I know to reinstall the additions and pull the headers first, so for me it is a two-minute detour, but it catches people who reasonably assume the integration will keep working after a routine update.

The networking flexibility I praised above has a flip side: the dialog does almost nothing to explain the modes. A newcomer who picks the wrong adapter type and then cannot work out why their VM has no internet, or why two VMs refuse to see each other, has no obvious path to the answer from inside the interface. The modes are not complicated once you understand what each one does, but the learning happens through trial and error or documentation rather than anything the tool tells you, and that first hour of confusion is real.

Extension Pack licensing is the one that genuinely catches organizations, and it deserves a clear flag. The base package is free, but the Extension Pack, which adds USB 2.0 and 3.0 device support, the VirtualBox RDP server, host webcam passthrough, and PXE boot, is covered by the Personal Use and Educational License. That license is free for personal and educational use only; any commercial or business use requires a paid Oracle license. The pack installs with a couple of clicks and the line between personal and work use is easy to cross without noticing, and the old 30-day evaluation option has been removed from the license, so there is no built-in trial inside the product to lean on anymore. Anyone deploying VirtualBox in a company should keep the base package and the Extension Pack mentally separate and treat the latter as something that needs a license decision. A few features that used to live in the Extension Pack, like full disk encryption and the NVMe controller, have moved into the open-source base package in a recent release, which narrows the set of things you actually need the paid pack for.

The smaller rough edges are worth a mention together. The mouse and keyboard capture behavior is confusing on first contact, before you understand the host key and how the grab works, and a new user can find themselves apparently stuck inside a VM window with no idea how to get the cursor back. Some menus could be reorganized, and the settings layout assumes you already know roughly where things live. None of this is a serious problem, and all of it fades once the tool is familiar, but it adds up to a first-run experience that is rougher than it needs to be.

One structural limitation rather than a bug: there are no datacenter features here. No live migration, no built-in high-availability clustering, no central management console for a fleet of hosts. That is not a fault so much as a statement of what the tool is, a workstation-class hypervisor rather than a server platform, and if you need those capabilities you are already looking at something like vSphere or Proxmox. Know the ceiling before you build a process on top of it. Review collected by and hosted on G2.com.

What problems is VirtualBox solving and how is that benefiting you?

The core problem it solves is testing things without risking my working machine or buying hardware to do it. Before I relied on it, trying out an unfamiliar installer, a system change, or a piece of software I did not fully trust meant either keeping a spare physical machine around, dual-booting, or running the test on my actual working system and hoping it cleaned up afterward. Now I do all of that inside a guest I can break and discard, so the benefit is simple: I can be reckless safely. The thing I am testing has no path to my real files or my real OS unless I deliberately give it one.

Cross-operating-system testing is the next problem it quietly removes. A lot of what I write or configure has to work on more than one OS, and before VirtualBox I did not have convenient access to every target, so I tested on whatever I happened to be running and discovered the platform-specific failures later, usually at an inconvenient moment. With a guest standing in for each target OS, I run the same script or config against CentOS, Debian, Ubuntu, and a Windows box in a single sitting and catch the differences while I am still in front of the work, not after it has shipped.

Snapshots changed how I approach any risky change, and that is a benefit in its own right separate from the feature itself. The before-state was that a bad update or a configuration that wrecked a machine meant rebuilding the box or restoring it from a backup, both of which are slow enough that I would hesitate before trying something uncertain. The after-state is that I revert in seconds and try again. Removing that hesitation means I experiment more, which means I learn the failure modes of a change before it ever touches a system that matters.

Building repeatable lab environments used to be a manual, slightly inconsistent chore, and the tool turned it into something scripted. Hand-building each test setup meant no two were ever quite identical, which made it hard to trust that a result in one lab would hold in another. Now a base image plus a set of VBoxManage commands lets me stand up a known environment from scratch on demand and tear it down when I am done, so the environment I test in today is the same one I will get tomorrow. That consistency is worth more than it sounds when you are trying to reproduce a problem.

Isolating untrusted or unknown software is a problem it handles cleanly, which matters for anyone whose work touches security even occasionally. Running a questionable installer or poking at something suspicious on a real machine is a risk I am not willing to take, so I spin up a disposable VM with no network attached or only a host-only adapter, look at the thing in there, and delete the whole machine afterward. Nothing it does inside the guest follows it out. That containment is the entire point, and VirtualBox makes setting it up quick enough that I actually bother every time rather than cutting the corner.

Sharing a working environment and onboarding someone new both got shorter because the machine is portable. Instead of writing a wiki page describing how to build a test setup and hoping a teammate follows it correctly, I export the machine as an appliance and hand it over, and they import a ready-made VM that already works. Because the host is abstracted away, the same exported machine runs on their Windows laptop or my Linux desktop without changes, so the environment is genuinely the same for everyone rather than approximately the same. Standardizing a dev or test setup across a small team stopped being a documentation exercise and became a file transfer.

There is also a quieter benefit that sits a little outside pure infrastructure work, which is that it makes learning and experimenting cheap. When I want to try a new Linux distribution, a different server stack, or some tool I have only read about, I do not have to commit my main OS to it or find a spare machine. I spin up a VM, try the thing, and either keep it or throw it away, and the low cost of doing that means I try more things than I otherwise would. For staying current in a field that does not sit still, that ease of just having a go is more valuable than any single feature. Review collected by and hosted on G2.com.