You built a VM in VirtualBox months ago. Maybe it's a dev environment with three hours of tool installs baked into it, or a Windows box you finally got activated and configured the way you like it. Now you've got Proxmox VE running on a spare machine or a home server, and you don't want to start over. You want that VM, as it is, running under Proxmox instead.
Good news: you don't have to rebuild it. VirtualBox and Proxmox VE both ultimately store a VM as a virtual disk file plus some configuration, and Proxmox has a command built specifically for pulling in disks from other hypervisors. The configuration part you'll redo by hand — it only takes a few minutes — but the disk, with your OS, your files, and your installed software, comes across intact.
What You Will Learn
- Where VirtualBox actually stores your VM's disk file, and how to get it off your machine and onto the Proxmox host
- How to create an empty VM shell in Proxmox VE and import the VirtualBox disk into it with
qm disk import - Why the target storage type (LVM, ZFS, or a plain directory) changes which disk format you can use
- How to fix the two things that break almost every migrated VM: the wrong disk bus and leftover VirtualBox drivers
- What to do when the migrated VM won't boot, has no network, or blue-screens on first start
What Is This Feature?
There's no "Migrate from VirtualBox" button in Proxmox VE, so it helps to know what's actually happening under the hood. A VirtualBox VM is really just a .vdi (or sometimes .vmdk) file sitting on your hard drive, plus an XML file describing the virtual hardware — CPU count, RAM, network adapter type, and so on.
Proxmox VE stores VMs the same basic way: a disk image sitting on some storage backend, plus a small config file (/etc/pve/qemu-server/<vmid>.conf) describing the hardware. The migration process is really just two steps: get the disk file onto the Proxmox host, then tell Proxmox to register it as a disk for a new VM. The command that does the second part is qm disk import (older guides call it qm importdisk — same command, it's just an alias).
Under the hood, qm disk import uses a tool called qemu-img to read the source file and convert it if needed. Since qemu-img understands VirtualBox's VDI format natively, you don't need any separate conversion step — Proxmox handles it for you during the import.
Why Would You Use It?
The obvious reason is that rebuilding a VM from scratch is a waste of an afternoon. But there's more to it than laziness.
VirtualBox is a type-2 hypervisor — it runs as an application on top of a full desktop OS, competing with your browser and everything else for CPU time. Proxmox VE runs KVM directly on bare metal, so the same VM will generally feel snappier once it's off your laptop and onto a dedicated box. If you've been running a VirtualBox VM on your daily driver just to keep a project alive, moving it to a Proxmox server frees up your actual machine and gives the VM room to breathe.
It's also common for people testing the waters with Proxmox to have a handful of VirtualBox VMs already — a pfSense box, an old Ubuntu server, a Windows VM for one annoying piece of software. Migrating them one at a time is a reasonable way to move your whole homelab over without a big-bang cutover.
Prerequisites
- A working Proxmox VE host. This guide was written against Proxmox VE 9.2, but the same commands work on 8.x and 7.x installs too.
- The VirtualBox VM fully shut down — not paused, not in "saved state." A saved-state VM has its memory contents locked to the disk file in a way that can leave the disk inconsistent if you copy it mid-save. Power it off cleanly from inside the guest first.
- Access to the VM's
.vdifile, or the ability to export it as an OVA from VirtualBox. - A way to get that file onto the Proxmox host — SCP over the network, a USB drive, or a shared folder all work.
- Free space on a Proxmox storage target roughly equal to the size of the virtual disk (check the actual used size, not the max size you set when you created it).
- Root access to the Proxmox shell, either directly or over SSH.
Step-by-Step Tutorial
Step 1: Find the VirtualBox disk file
By default, VirtualBox stores each VM in its own folder:
- Windows:
C:\Users\<you>\VirtualBox VMs\<vm name>\ - Linux and macOS:
~/VirtualBox VMs/<vm name>/
Inside that folder you'll find a .vbox file (the VM's settings, in XML) and one or more .vdi files (the actual disk contents). If the VM has multiple disks attached, note which one is the boot disk — it's usually the largest, or the one listed first under Storage in the VirtualBox VM settings.
If you'd rather not dig through folders, VirtualBox can also export the whole VM as a single .ova file via File → Export Appliance. That's a fine alternative, and Proxmox can import OVAs directly with a different command (qm importovf), but it packages everything — disk and hardware definition — into one bundle, which is less flexible if you want to rebuild the VM's hardware settings from scratch anyway. This guide sticks with the raw disk file, since it gives you more control and is the more common path people run into trouble with.
Step 2: Copy the disk file to the Proxmox host
Get the .vdi file onto your Proxmox server. From a Linux or macOS machine, or from Windows with an SSH client installed, scp works well:
scp "my-ubuntu-vm.vdi" root@192.168.1.50:/var/lib/vz/template/iso/This copies the file over SSH to the Proxmox host's ISO storage folder, which is a convenient scratch location for files like this — it's not actually being treated as an ISO, just parked there temporarily. Adjust the destination if your Proxmox host's IP or the folder you're using is different. A large Windows disk can easily be 40-60 GB, so budget time accordingly on a home network; a gigabit link moves roughly 100 GB per 15-20 minutes in practice, slower over Wi-Fi.
Step 3: Create an empty VM shell in Proxmox
In the Proxmox web interface, click Create VM in the top right. Walk through the wizard, but on the Disks step, delete the default disk it wants to create — you don't need one, since you're bringing your own. Pay attention to a few settings that need to match the original VM:
- OS type — pick the correct guest OS family so Proxmox sets sensible defaults.
- BIOS — most older VirtualBox VMs used legacy BIOS. If yours had EFI enabled in VirtualBox, choose OVMF (UEFI) here to match; otherwise stick with SeaBIOS. Getting this wrong is one of the more common reasons a migrated disk won't boot.
- Memory and CPU cores — set these to roughly what the VM had in VirtualBox. You can change them later without touching the disk.
Finish the wizard without starting the VM. Note the VM ID Proxmox assigned it (shown in the left-hand tree, something like 105) — you'll need it in the next step.
Step 4: Import the disk
This is the actual migration step. From the Proxmox shell:
qm disk import 105 /var/lib/vz/template/iso/my-ubuntu-vm.vdi local-lvmHere, 105 is the VM ID from Step 3, the path is your copied .vdi file, and local-lvm is the storage where the new disk will live — swap in whatever storage you actually want to use.
One detail that trips people up: the target storage type limits which disk format you can use. Block-based storage like LVM, LVM-thin, ZFS, or Ceph only stores raw disks — Proxmox converts to raw automatically and there's nothing to configure. File-based storage like a plain directory or an NFS share supports qcow2 and vmdk as well, and you can pick one explicitly:
qm disk import 105 /var/lib/vz/template/iso/my-ubuntu-vm.vdi local --format qcow2If you don't have a strong reason to use qcow2 (its main advantage is built-in snapshots on storage types that don't otherwise support them), raw on LVM-thin or ZFS is simpler and usually a bit faster.
The import runs qemu-img in the background and can take a few minutes for a large disk. When it's done, check the VM's Hardware tab — you'll see a new line called Unused Disk 0. That confirms the import worked, but the disk isn't attached to anything yet.
Step 5: Attach the disk
Click on Unused Disk 0 in the Hardware tab, then click Edit. Set the Bus/Device to SCSI (with the SCSI controller type set to VirtIO SCSI single, if you're offered the choice), then click Add. Using VirtIO here instead of IDE or SATA makes a real difference in disk performance — IDE emulation is noticeably slower and really only exists for compatibility with very old guest OSes.
Step 6: Fix the boot order
Go to Options → Boot Order and make sure the disk you just attached (scsi0, most likely) is enabled and listed first. VMs imported this way sometimes boot with no boot device selected at all, which just shows a black screen with a blinking cursor — this step is what fixes that.
Step 7: Boot the VM and clean up the guest OS
Start the VM and open its console. What happens next depends on the guest:
Windows guests will very likely fail to boot the first time with a blue screen, because Windows doesn't ship a driver for the VirtIO SCSI controller you just attached the disk to. You'll need to either attach the disk as SATA temporarily to get Windows booting, then inject the VirtIO driver from inside Windows before switching back to SCSI — or boot once with both the VirtIO driver ISO and the disk attached and let Windows find the driver during boot. Either way, this is the same VirtIO driver process used for any Windows VM on Proxmox, not something specific to migration.
Linux guests boot more reliably, since virtio drivers are built into the kernel already, but you should still uninstall the VirtualBox Guest Additions from inside the guest — leftover VirtualBox kernel modules and services (vboxadd, vboxguest) don't do anything useful under KVM and can occasionally interfere with boot or networking. On a Debian or Ubuntu guest:
sudo apt purge virtualbox-guest-utils virtualbox-guest-dkms virtualbox-guest-x11
sudo rebootAfterward, install the QEMU Guest Agent instead — it's the Proxmox equivalent, and it's what lets the Summary tab show the VM's real IP address and lets you shut the VM down cleanly from the GUI:
sudo apt install qemu-guest-agent
sudo systemctl enable --now qemu-guest-agentYou'll also need to tick QEMU Guest Agent under the VM's Options tab in Proxmox for it to actually be used.
Step 8: Verify and clean up
Once the VM boots normally, log in and confirm your files and applications are intact. Check networking — VirtualBox VMs often used an Intel e1000 virtual NIC, and Proxmox defaults new VMs to VirtIO, which is faster but may need the network device re-detected inside the guest (more on that in Troubleshooting below). Once you're confident everything works, delete the leftover .vdi file from /var/lib/vz/template/iso/ on the Proxmox host to reclaim that space — the import already made its own copy on the target storage, so the original isn't needed anymore.
Commands Explained
| Command | What it does |
|---|---|
scp file root@host:/path | Copies a file from your computer to the Proxmox host over an encrypted SSH connection |
qm disk import <vmid> <source> <storage> | Imports an external disk image (VDI, VMDK, raw, qcow2 — anything qemu-img can read) into Proxmox as an unused disk on the given VM and storage |
qm disk import ... --format qcow2 | Forces the disk to be converted to a specific format on the target storage; only relevant on file-based storage |
qm importovf | A different command that builds an entirely new VM from an OVA/OVF appliance package in one step, instead of importing a disk into an existing VM |
qm config <vmid> | Prints the VM's current configuration — useful for confirming which disk is attached to which bus after you make changes |
systemctl enable --now qemu-guest-agent | Enables and immediately starts the QEMU Guest Agent service inside a Linux guest, so Proxmox can communicate with the OS |
Common Errors
| Error / Symptom | Likely Cause |
|---|---|
unable to parse volume filename | The source path is wrong, or has a typo — double-check the exact filename and that it actually copied over |
lvcreate ... not supported or format-related failure on LVM/LVM-thin | You tried to force --format qcow2 or vmdk on block storage, which only supports raw disks |
| VM boots straight to "No bootable device" | The imported disk is still sitting as "Unused Disk" and was never attached, or the boot order wasn't updated |
Windows blue screen, INACCESSIBLE_BOOT_DEVICE (0x0000007B) | Windows has no driver for the VirtIO SCSI controller — attach as SATA first, or boot with the VirtIO driver ISO mounted |
| Black screen, no cursor, VM appears "running" | Usually a BIOS/UEFI mismatch between the original VirtualBox VM and the new Proxmox VM's boot mode |
Troubleshooting
If the VM boots but there's no network, check the guest's network device list first. Linux distributions that use predictable interface naming (like enp0s3 under VirtualBox) will often assign a completely different name — say, ens18 — once the underlying virtual hardware changes, because the name is generated from the device's PCI address. The old configuration, still pointing at enp0s3, simply won't apply to the new interface. Run ip a to see what the interface is actually called now, and update your netplan or interfaces file to match.
If performance feels sluggish after migration even though the VM "works," check two things: the disk bus (it should be SCSI with VirtIO SCSI, not IDE) and the network adapter model in the VM's Hardware tab (it should be VirtIO, not the default Intel E1000 some people leave selected out of habit from other hypervisors). Both can be changed after the fact — for the network adapter it's usually a quick edit in the Hardware tab; for the disk bus, you may need to detach and reattach as described in Step 5.
If the import command itself hangs or times out on a very large disk over a slow storage backend, it's not actually stuck — qemu-img conversion on a multi-hundred-gigabyte disk can genuinely take a long time. Check Datacenter → Tasks in the GUI to watch progress rather than assuming the shell has frozen.
Best Practices
Don't delete the original VirtualBox VM or its disk file until you've actually booted the migrated version and confirmed it works — including logging in and checking that your data is where you expect it. It costs nothing to keep the old copy around for a week.
Take a snapshot immediately after your first successful boot, before you start installing updates or making changes. If something goes sideways during cleanup, you've got a known-good rollback point.
Switch to VirtIO SCSI and VirtIO network as part of the migration rather than leaving IDE/SATA and e1000 in place "because it works." It works either way, but VirtIO is noticeably faster and it's a lot easier to make that change once, right after migration, than to come back and do it on a VM you've already been using for months.
If you're migrating more than one VM, do them one at a time rather than copying every disk file over first. It's much easier to debug a boot problem when you know it's isolated to the one VM you just touched.
Frequently Asked Questions
Do I need to convert the .vdi file before importing it?
No. qm disk import reads VDI files directly through qemu-img and converts them automatically during the import — there's no separate qemu-img convert step required.
Can I import a VMDK file the same way?
Yes. The command works the same way regardless of whether the source is VDI, VMDK, or raw — just point it at the file.
Will my VirtualBox snapshots come across too?
No. Only the current, live state of the disk gets imported. If you need to preserve a snapshot's state, restore the VM to that snapshot in VirtualBox first, then export the disk from that point.
Skip snapshots you don't actually need before migrating — there's no way to bring old snapshot history into Proxmox once the disk is imported.
What if my VirtualBox VM has more than one disk?
Run qm disk import once per disk file, targeting the same VM ID each time. Each import adds another "Unused Disk" entry, and you attach each one in the Hardware tab afterward.
Is this any different from importing an OVA?
An OVA bundles the disk and the hardware description together and Proxmox builds the whole VM from it in one step with qm importovf. Importing the raw disk file, as this guide does, means you build the VM shell yourself first — a bit more manual work, but it means you're deliberately choosing BIOS mode, disk bus, and resource settings rather than inheriting whatever VirtualBox had configured.
Conclusion
Migrating off VirtualBox isn't a rebuild — it's a file copy and one import command, plus a handful of settings to get right on the way in. The disk itself, with everything on it, comes across without any drama. Most of what goes wrong afterward traces back to one of three things: a BIOS mode mismatch, a missing VirtIO driver on Windows, or a disk still sitting unattached as "Unused Disk 0." Check those three first if a migrated VM won't cooperate, and you'll usually find the fix in under a minute.