It’s not that difficult do virtual > physical migrations in Linux. Linux is inherently portable, thanks to the kernel, you don’t need to worry about stuff like drivers, at least for drivers which are part of the kernel (so not counting proprietary nVidia drivers - which you wouldn’t be using in a VM anyways.)

Roughly, the process would go like this:

1. Use qemu-img convert to convert your virtual disk to a raw image format
2. Use dd to write the image to your physical disk
3. Use gparted to resize/expand partitions on the disk as required
4. Examine the disk using fdisk/blkid to see which device node your disk is using (eg /dev/nvme0n2 etc), then mount the new root volume and edit the fstab to the correct disk paths if required
5. Chroot into the disk and reinstall your bootloader (GRUB or systemd-boot etc). The process for this will vary based on your bootloader, and your distro. Usually most distros should have some wiki or documentation on how to repair GRUB or w/e from chroot.
6. Boot from the new disk and test. You may need to manually add an entry to your UEFI boot entries, if it’s not showing up as an option in your UEFI boot menu.
7. You may need to potentially install some extra stuff, for instance, you may need to install the Vulkan driver package for your GPU, maybe the CPU microcode package etc.

This is all of course, assuming you’re migrating to a dedicated hard drive and you’re only going to be using a single OS. On the other hand, if you’re migrating on to an existing disk (dual-booting) the process would be a bit different - instead of dding the entire image, you’d use losetup and mount your raw disk image as a loop device, then use something like clonezilla or GParted to copy over only specific partitions excluding the ESP. After that, the rest of the process should be similar to the above, except you won’t need to reinstall your bootloader - but you may need to update it’s config to detect the new OS.

I’ve not accounted for complex setups btw, such as using LUKS or LVM. But the process still remains roughly the same, you’ll just need a few additional commands to decrypt the partition before you copy them over.

In saying that, it may be easier to just reinstall the distro fresh on your real hardware. There are scripts out there to export your dotfiles and package lists, to make the migration easier.

I wish this was a thing. But I don’t think it is. I’d love to have a USB drive that could be run virtually and vice versa.

If you are comfortable with fedora and want KDE as your Desktop, then you could try out Fedora’s KDE spin among other spins avaialble at https://fedoraproject.org/spins/

Also If you haven’t already gotten familar with the command line, I recommend you do that as it’s gonna be the same no matter what Desktop you choose to use. Plus it’s gonna improve your Linux experience and your life.

yeah, that works. just small problems like maybe fixing the boot loader/efi or fstab because disks are enumerated differently or propietary drivers missing. you can also likely just export package manager selections, /etc, /var and your home dir as tarballs to change a fresh install of the same distro into yours.

i also did the reverse: on a dual boot gentoo+debian with 2 HDs, i installed vmware in gentoo and configured the HD of the debian install as HD in the VM and it ran very well. the linux kernel autodetects all drivers at boot anyway. same for X or Wayland nowadays. (long ago, it was different and you would have needed to swap 2 X configs, for example, but nowadays it’s all very flexible and dynamic)

Maybe a roundabout solution, but if you spend your effort into setting it up via ansible, then it would theoretically be easy to redeploy it to your real machine? Doesnt help if you’ve already setup your vm.

deleted by creator