Moving a virtual machine from one Unraid box to another isn’t as scary as it sounds. Under the hood, Unraid VMs are just standard KVM\/QEMU domains, so the process boils down to: copy the disk, copy the config, fix a couple of host-specific details, and boot it up. Here’s the full walkthrough, based on a real migration I ran recently between two of my own servers (referred to below as A few things to have ready:<\/p>\n Unraid usually stores VM disks under This shows the This tells you how long the copy will take and whether it’s worth running in the background.<\/p>\n Running it with A word of caution:<\/strong> if SSH between the two servers isn’t already using key-based auth, a backgrounded If you see Then retry the copy \u2014 it should run unattended from here on.<\/p>\n (Note: Unraid’s default root filesystem is read-only on part of Once the disk copy is running (or finished), grab the VM’s full definition from the source server:<\/p>\n Take a look through it for a few things that will need adjusting for the new host:<\/p>\n If your VM uses UEFI\/OVMF firmware, it has a small NVRAM file tied to its UUID, stored at:<\/p>\n Copy this over too, to preserve the exact UEFI state:<\/p>\n On the new server:<\/p>\n If you skip this, libvirt will just generate a fresh NVRAM file \u2014 the VM will still boot, but any custom UEFI boot order or settings will reset to firmware defaults.<\/p>\n Before starting the VM, confirm the OVMF loader file referenced in the XML actually exists on the new server:<\/p>\n Both servers running the same Unraid version should already have this in place.<\/p>\n Copy your edited XML to the new server, then define the VM:<\/p>\n You should see the VM listed as It should now show as Give the guest OS a minute to boot, then confirm network connectivity:<\/p>\n If that responds, SSH in and check that whatever services the VM runs actually came back up cleanly. If a service normally runs under systemd, check it there; if not, a simple process check works just as well:<\/p>\n Once you’re confident the VM is stable on its new home \u2014 I’d recommend giving it at least a day of normal use first \u2014 you can remove the old copy from the source server:<\/p>\n There’s no rush on this step. Keeping the old copy around costs disk space, but it’s a free safety net until you’re sure the migration is solid.<\/p>\n Migrating a VM between Unraid servers is really just a disk copy plus an XML config with a few host-specific edits. The main gotchas are CPU pinning that doesn’t map across different hardware, SSH auth that isn’t set up yet, and remembering the NVRAM file if your VM uses UEFI. Once you’ve done it once, it’s a pretty quick process the next time around.<\/p>\n","protected":false},"excerpt":{"rendered":" Migrating a VM between Unraid servers: copy the disk, export and edit the XML config, handle UEFI NVRAM, then define and start the VM on the new host.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[13],"class_list":["post-187","post","type-post","status-publish","format-standard","hentry","category-general","tag-unraid"],"_links":{"self":[{"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=\/wp\/v2\/posts\/187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=187"}],"version-history":[{"count":0,"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=\/wp\/v2\/posts\/187\/revisions"}],"wp:attachment":[{"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dionysismedia.ca\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Old_Server<\/code> and New_Server<\/code>).<\/p>\nBefore You Start<\/h2>\n
\n
Step 1: Find the VM’s Disk Image<\/h2>\n
\/mnt\/user\/domains\/<vm-name>\/<\/code>, but yours might live somewhere custom (a different share, a pool, or unassigned devices). If you’re not sure, pull it straight from the VM’s XML definition:<\/p>\nvirsh dumpxml <vm-name> | grep -A2 \"<disk\"<\/code><\/pre>\n<source file='...'\/><\/code> path for each attached disk \u2014 note the real path before assuming the default location.<\/p>\nStep 2: Check the Disk Size<\/h2>\n
du -sh \/path\/to\/vdisk1.img<\/code><\/pre>\nStep 3: Copy the Disk to the New Server<\/h2>\n
mkdir -p \/path\/on\/New_Server\/domains\/<vm-name>\/\nnohup rsync -avP --progress \/path\/to\/vdisk1.img root@New_Server:\/path\/on\/New_Server\/domains\/<vm-name>\/ > \/root\/vmcopy.log 2>&1 &<\/code><\/pre>\nnohup<\/code> and backgrounding it (&<\/code>) keeps the transfer alive even if your SSH session drops. Watch progress with:<\/p>\ntail -f \/root\/vmcopy.log<\/code><\/pre>\nrsync<\/code> can hang silently waiting on a password prompt that never arrives. If nothing shows up in the log after a minute or two, check for stuck processes:<\/p>\nps aux | grep rsync<\/code><\/pre>\nrsync<\/code>\/ssh<\/code> processes sitting idle, kill them and set up an SSH key first:<\/p>\nssh-keygen -t ed25519 -N \"\" -f \/root\/.ssh\/id_ed25519\ncat \/root\/.ssh\/id_ed25519.pub | ssh root@New_Server \"mkdir -p \/root\/.ssh && cat >> \/root\/.ssh\/authorized_keys && chmod 700 \/root\/.ssh && chmod 600 \/root\/.ssh\/authorized_keys\"<\/code><\/pre>\n\/root<\/code>, so you may see a harmless known_hosts<\/code> write warning during SSH connections. It doesn’t block anything \u2014 the connection still succeeds.)<\/em><\/p>\nStep 4: Export the VM’s XML Configuration<\/h2>\n
virsh dumpxml <vm-name> > \/root\/vm-export.xml<\/code><\/pre>\n\n
<cputune><\/code>)<\/strong> \u2014 if the two servers have different CPU models or core counts, pinned core IDs from the old server won’t map correctly to the new one’s topology. Easiest fix is to delete the entire <cputune><\/code> block and let the new host’s scheduler handle placement<\/li>\nbr0<\/code>); check with ip a | grep br0<\/code> on the destination<\/li>\n<\/ul>\nStep 5: Handle the UEFI NVRAM File (If Applicable)<\/h2>\n
\/etc\/libvirt\/qemu\/nvram\/<uuid>_VARS-pure-efi.fd<\/code><\/pre>\nscp \/etc\/libvirt\/qemu\/nvram\/<uuid>_VARS-pure-efi.fd root@New_Server:\/root\/<\/code><\/pre>\nmkdir -p \/etc\/libvirt\/qemu\/nvram\/\nmv \/root\/<uuid>_VARS-pure-efi.fd \/etc\/libvirt\/qemu\/nvram\/<\/code><\/pre>\nStep 6: Verify the Firmware File Exists<\/h2>\n
ls -la \/usr\/share\/qemu\/ovmf-x64\/OVMF_CODE-pure-efi.fd<\/code><\/pre>\nStep 7: Define and Start the VM<\/h2>\n
virsh define \/root\/vm-export.xml\nvirsh list --all<\/code><\/pre>\nshut off<\/code>. Start it:<\/p>\nvirsh start <vm-name>\nvirsh list --all<\/code><\/pre>\nrunning<\/code>.<\/p>\nStep 8: Verify Everything Actually Works<\/h2>\n
ping -c 4 <vm-ip><\/code><\/pre>\nps aux | grep <process-name><\/code><\/pre>\nStep 9: Clean Up (Whenever You’re Ready)<\/h2>\n
virsh undefine <vm-name> --nvram\nrm -rf \/path\/to\/old\/domains\/<vm-name>\/<\/code><\/pre>\n
\nSummary<\/h2>\n