You've got an LXC container running some service on your Proxmox VE box, and now you need it to behave like a full virtual machine. Maybe you need a different kernel. Maybe GPU passthrough only works cleanly in a VM. Maybe you just clicked Create CT instead of Create VM eight months ago and didn't think it would matter.
You go looking for a "Convert to VM" button. It doesn't exist. Not in the GUI, not as a pct subcommand, not anywhere in the official Proxmox VE documentation. That surprises a lot of people, so let's talk about why, and what you should actually do about it.
What You Will Learn
By the end of this guide you'll understand why Proxmox VE has no native container-to-VM conversion tool, what the unofficial scripts floating around the forums actually do to your disk, and how to move a workload out of a container and into a proper VM without losing data or your weekend. We'll also cover the mistakes that trip people up, the errors you'll see if you try to shortcut the process, and a handful of questions worth answering before you start.
What Is This Feature?
First, a quick reality check on what a container and a VM actually are, because the answer to "can I convert one to the other" depends entirely on this.
An LXC container shares the host's Linux kernel. When you create a container in Proxmox VE, you're not booting an operating system — you're launching a set of isolated processes that think they're on their own machine, using Linux namespaces and cgroups to keep them separate from everything else on the host. There's no bootloader, no kernel image inside the container, no BIOS or UEFI handoff. pct start 105 just unpacks a filesystem and starts a process tree inside it.
A virtual machine is a completely different animal. Proxmox VE uses QEMU and KVM to emulate real hardware — a virtual CPU, virtual disk controller, virtual network card — and boots a full, independent operating system on top of it, kernel included. That's why a VM can run Windows, FreeBSD, or a different Linux kernel version than the host, and a container can't.
Converting a container to a VM would mean taking a folder full of application files and somehow turning it into a bootable disk image with its own kernel, initramfs, and bootloader. That's not a format conversion. It's closer to building a new computer around an old hard drive.
Why Would You Use It?
People usually go looking for this because they hit one of these walls:
- They need GPU passthrough, and while LXC can do GPU passthrough for some workloads, full PCI passthrough with device isolation is far more reliable in a VM.
- They need a kernel module or feature the Proxmox host kernel doesn't provide, because containers are stuck using whatever kernel the host is running.
- They're running something that wants to run Docker with full privileges, and they'd rather not deal with nested containers or a privileged LXC container.
- They want live migration, snapshots on shared storage, or other VM-specific features that behave more predictably than their container equivalents.
All of those are legitimate reasons to want a VM. None of them require you to preserve the container's actual disk bytes. That distinction matters, because it changes the whole strategy.
Prerequisites
Before you start moving anything, make sure you have:
- SSH or console access to both the Proxmox VE host and the container you're migrating (root or a user with
sudo). - Enough free storage for a backup of the container plus a new VM disk, at least temporarily. Double the container's current disk usage is a safe rule of thumb.
- The installer ISO for the container's Linux distribution, uploaded to Proxmox VE's local storage (Datacenter → Storage → your ISO storage → Upload).
- A maintenance window, even a short one, if this is a service people rely on. Plan for downtime measured in tens of minutes, not seconds.
You don't need anything exotic here. This is a data migration, not a disk surgery project, and that's on purpose.
Step-by-Step Tutorial
There are two approaches you'll find if you search around. One is the "rebuild it properly" method, which is what I'd actually recommend to almost everyone. The other is a raw disk conversion using community scripts, which I'll explain honestly so you know what you're getting into if you go that route anyway.
The recommended approach: rebuild, don't convert
Step 1: Document what's actually running in the container
Before you touch anything, find out exactly what distribution and version the container is running:
pct exec 105 -- cat /etc/os-releaseReplace 105 with your container's VMID. This tells you exactly which ISO to grab for the new VM — matching the distro and major version avoids a pile of small compatibility headaches later. While you're in there, note the installed packages (dpkg -l on Debian/Ubuntu, rpm -qa on RHEL-based systems), any custom config files under /etc, and where the application stores its data.
Step 2: Back up the container
Run a proper backup before you do anything else:
vzdump 105 --mode snapshot --storage local --compress zstdThis gives you a restore point if anything goes sideways. It also gives you an easy way to pull files back out later if you forgot to copy something in step 3.
Step 3: Copy the data you actually care about
Application binaries you can reinstall from a package manager. Config files and data you can't easily recreate — database files, uploaded content, SSL certificates, cron jobs. Pull those off the container to somewhere safe, like your workstation or another server:
rsync -avz root@container-ip:/var/lib/myapp/ /tmp/myapp-backup/If the container doesn't have its own IP or SSH access, use pct exec 105 -- tar czf - /var/lib/myapp piped over SSH from the Proxmox host instead. Either way, the goal is the same: get the data off the container and onto something durable.
Step 4: Create the new VM
In the Proxmox VE web interface, click Create VM, pick the ISO you uploaded in the prerequisites, and walk through the wizard. Match the CPU and RAM allocation the container had, at minimum — you can always adjust later. For the disk, VirtIO SCSI with a reasonably sized qcow2 or raw disk on your fastest available storage is a solid default for most Linux guests.
Install the OS like you would on any fresh machine. Yes, this takes longer than flipping a switch. It also gives you a clean, bootable system with a real kernel and bootloader, which is the entire thing a converted container disk would be missing.
Step 5: Reinstall the application and restore your data
Install the same packages you noted in step 1, then copy your backed-up data back onto the new VM:
rsync -avz /tmp/myapp-backup/ root@new-vm-ip:/var/lib/myapp/Restore your config files, import any database dumps, and start the service. Check the logs. This is the point where mismatched versions or missing config values tend to show up, so don't rush it.
Step 6: Test before you cut over
Point a browser or a test client at the new VM directly by IP before touching DNS or your reverse proxy. Confirm the application actually works end to end — not just that the process started.
Step 7: Cut over and retire the container
Update DNS records, reverse proxy configs, or firewall rules to point at the new VM. Once you've confirmed everything is stable — I'd give it at least a day for anything important — stop the old container rather than deleting it immediately:
pct stop 105Keep it around for a week or two as a rollback option before you actually remove it with pct destroy.
The other approach: raw disk conversion (and why I'd think twice)
You'll find community tools and forum threads describing a more direct method: archive the container's root filesystem, dump it onto a raw VM disk, boot a rescue ISO, chroot into that disk, and manually install a kernel and a bootloader like GRUB. It's a real technique, and for someone who's comfortable with chroot environments and boot repair, it can work.
It's also not something Proxmox supports or documents, and it's easy to end up with a disk that boots into a kernel panic instead of your application. For most homelab and small-business use cases, the hour you'd spend debugging a broken bootloader costs more than the twenty minutes you'd save skipping a fresh OS install.
If you want to explore it anyway, search the Proxmox forums for community LXC-to-VM conversion scripts — just go in knowing you're on your own if something breaks, and always keep a backup of the original container untouched until the new VM boots correctly.
Commands Explained
| Command | What it does |
|---|---|
pct exec <vmid> -- <command> | Runs a command inside a running container without opening a full shell session. |
cat /etc/os-release | Prints the Linux distribution name and version — the fastest way to confirm exactly what you're rebuilding. |
vzdump <vmid> --mode snapshot | Creates a backup archive of a container or VM without stopping it, using a filesystem snapshot. |
rsync -avz src dest | Copies files while preserving permissions and timestamps (-a), showing progress (-v), and compressing data in transit (-z). |
pct stop <vmid> | Shuts down a running container without deleting it — the safe middle step before pct destroy. |
Common Errors
A few things trip people up when they try to shortcut this process:
- "No bootable device" or "Operating system not found" — this shows up when someone dd's a container's rootfs straight onto a VM disk and tries to boot it. The disk has files on it, but no bootloader and no kernel, so the VM's firmware has nothing to hand control to.
- Files owned by the wrong user after copying data — if the container is unprivileged, its UIDs are shifted by an offset on the host (this is what keeps container root from being real host root). Data copied out and back in with the wrong tool can end up with ownership that looks scrambled.
rsyncrun as root over SSH avoids this because it's working with UIDs from inside the container's own view, not the host's shifted view. - Duplicate IP address on the network — if you give the new VM the same static IP as the old container while both are still running, you'll get intermittent connectivity issues that look nothing like a network problem. Test the new VM on a different address first.
Troubleshooting
If the new VM won't boot after an OS install, double check the disk controller type matches what the guest OS expects — VirtIO SCSI needs drivers that some minimal installers don't include by default, so SATA is a safer fallback if you hit a "no root filesystem found" error during install.
If a restored application won't start, check for hardcoded paths or container-specific assumptions in its config — some software reads /proc or /sys values that look different on real hardware versus a container's shared kernel view, and a config written for one won't always behave identically on the other.
If networking doesn't come up on the new VM, confirm it's attached to the same bridge (usually vmbr0) the container was using, and that the VM's network model is set to VirtIO for best performance and driver compatibility on Linux guests.
Best Practices
- Keep the original container powered off, not deleted, until the new VM has been running in production for at least a few days.
- Match the OS version as closely as possible — going from Debian 12 to Debian 12 is painless; jumping two major versions during a migration just adds variables you don't need right now.
- Do a dry run on a low-priority service first if this is your first time doing a migration like this. Learn where the friction is before you touch anything customers depend on.
- Use a Cloud-Init template if you're migrating several similar containers — Cloud-Init lets Proxmox VE automatically configure hostname, network, and SSH keys on a fresh VM at boot, which cuts down on repetitive manual setup.
Frequently Asked Questions
Is there really no built-in way to do this?
Correct — as of current Proxmox VE releases, there's no pct or qm command, and no GUI button, that converts a container into a virtual machine.
Will I lose data if I follow the rebuild method?
Not if you back up first. The whole point of copying data out before you start is that you're never relying on a single, unverified copy.
Can I just attach the container's disk to a new VM and skip reinstalling the OS?
You can try, but it won't boot on its own — there's no kernel or bootloader on that disk. You'd need to manually chroot in and install both, which is exactly the risky shortcut this guide is steering you away from.
Do I need to reuse the same VMID?
No. Container VMIDs and VM VMIDs share the same numbering pool in Proxmox VE, but there's no requirement to reuse the old one. Pick a free ID and move on.
What about the community LXC-to-VM scripts I've seen mentioned?
They exist and some people have had success with them. They're unofficial, unsupported by Proxmox, and can leave you with an unbootable disk if something in the chroot step goes wrong. I'd only reach for one if I already knew how to fix a broken bootloader by hand.
Is GPU passthrough really that much better in a VM?
For full, isolated PCI passthrough, yes — a VM gives the guest exclusive control of the device the way most drivers expect. LXC can do some GPU sharing scenarios, but it's a narrower fit than full passthrough to a VM.
Conclusion
Container-to-VM conversion sounds like it should be a one-liner, and the fact that it isn't catches a lot of people off guard. Once you understand that a container is just processes on the host's kernel and a VM is an entirely separate machine underneath, the reason clicks into place — you're not converting a format, you're building something that didn't exist before.
Rebuilding the service in a fresh VM takes longer than a single command would, but it also gives you a clean, properly booting system with none of the guesswork a manual disk hack carries. For almost everyone reading this, that trade is worth it.