VM Migration error

F

Frank-75

New Member
Dec 3, 2025
20
1
3
Code: 
026-08-01 19:39:00 use dedicated network address for sending migration traffic (172.21.21.7)
2026-08-01 19:39:00 starting migration of VM 101 to node 'pve-ML350pGen8' (172.21.21.7)
2026-08-01 19:39:01 found local disk 'LOCALSTORE_RAID5_VM:vm-101-disk-0.qcow2' (attached)
2026-08-01 19:39:01 found local disk 'LOCALSTORE_RAID5_VM:vm-101-disk-1.qcow2' (attached)
2026-08-01 19:39:01 found local disk 'LOCALSTORE_RAID5_VM:vm-101-disk-2.qcow2' (attached)
2026-08-01 19:39:01 copying local disk images
2026-08-01 19:39:01 ERROR: storage migration for 'LOCALSTORE_RAID5_VM:vm-101-disk-0.qcow2' to storage 'LOCALSTORE_RAID5_VM' failed - cannot migrate from storage type 'lvm' to 'lvm'
2026-08-01 19:39:01 aborting phase 1 - cleanup resources
2026-08-01 19:39:01 ERROR: migration aborted (duration 00:00:02): storage migration for 'LOCALSTORE_RAID5_VM:vm-101-disk-0.qcow2' to storage 'LOCALSTORE_RAID5_VM' failed - cannot migrate from storage type 'lvm' to 'lvm'
TASK ERROR: migration aborted

Hi all,
I converted the datastores of two separate servers with RAID storage from directories to LVM (volumegroup).
In between, I used an iSCSI-LVM datastore on NAS to move the VM disks then 'ive have migrated the VM to second server.
Now that I'm done, the servers have the same datastore configuration with the same name. I can no longer migrate the VMs from one server to the other with the error reported.
What am I missing? I switched to LVM to have more resilience between the two nodes (I have a qDevice acting as a witness), but instead I find myself in a worse situation. Why can't the system migrate VMs between two identically created LVM storage devices?
 
Code: 
dir: local
    path /var/lib/vz
    content iso,vztmpl
    shared 0

lvmthin: local-lvm
    thinpool data
    vgname pve
    content images,rootdir

cifs: NAS-DS216se
    path /mnt/pve/NAS-DS216se
    server 172.20.20.231
    share ProxMox-BackupLXC
    content backup,snippets
    domain NAS-DS216se
    prune-backups keep-all=1
    username bstoczio.ahahah

pbs: LXC-ProxMoxServerBackup
    datastore NAS-DS216se
    server 172.20.20.19
    content backup
    fingerprint 0d:-----------:dd
    namespace Backup-VM
    prune-backups keep-all=1
    username bassoreta@pbs

iscsi: iSCSI-NAS-DS213
    portal 172.20.20.232
    target iqn.2000-01.com.synology:DS213-3TB.Target-1--------
    content images

lvm: iSCSI-LVM
    vgname VolumeGroup-iSCSI-LVM
    base iSCSI-NAS-DS213:0.0.1.scsi-36001405218e9a--------
    content images,rootdir
    saferemove 0
    saferemove_throughput -52428800
    shared 1
    snapshot-as-volume-chain 1

lvm: LOCALSTORE_RAID5_VM
    vgname LOCALSTORE_RAID5_VM
    content images,rootdir
    nodes pve-ML350pGen8,DL160gen9
    saferemove 0
    shared 0
    snapshot-as-volume-chain 1

The LXC migration is working correctly.
This morning I rebooted one of the nodes because I had done the updates (damn, once a week! :-( ) ), but nothing changed in the VMs.
The two servers have a dedicated network (class 172.21) with direct communication (no switch) at 10Gb, so it's right that the class is different.

Code: 
2026-08-02 08:44:20 use dedicated network address for sending migration traffic (172.21.21.7)
2026-08-02 08:44:20 starting migration of CT 504 to node 'pve-ML350pGen8' (172.21.21.7)
2026-08-02 08:44:20 found local volume 'LOCALSTORE_RAID5_VM:vm-504-disk-0' (in current VM config)
2026-08-02 08:44:22   Logical volume "vm-504-disk-0" created.
2026-08-02 08:44:25 1025245184 bytes (1.0 GB, 978 MiB) copied, 3 s, 342 MB/s
--
2026-08-02 08:45:04 15747710976 bytes (16 GB, 15 GiB) copied, 42 s, 375 MB/s
2026-08-02 08:45:04 245760+0 records in
2026-08-02 08:45:04 245760+0 records out
2026-08-02 08:45:04 16106127360 bytes (16 GB, 15 GiB) copied, 43.0763 s, 374 MB/s
2026-08-02 08:45:09 186406+118708 records in
2026-08-02 08:45:09 186406+118708 records out
2026-08-02 08:45:09 16106127360 bytes (16 GB, 15 GiB) copied, 46.8497 s, 344 MB/s
2026-08-02 08:45:09 successfully imported 'LOCALSTORE_RAID5_VM:vm-504-disk-0'
2026-08-02 08:45:09 volume 'LOCALSTORE_RAID5_VM:vm-504-disk-0' is 'LOCALSTORE_RAID5_VM:vm-504-disk-0' on the target
2026-08-02 08:45:09 # /usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=pve-ML350pGen8' -o 'UserKnownHostsFile=/etc/pve/nodes/pve-ML350pGen8/ssh_known_hosts' -o 'GlobalKnownHostsFile=none' root@172.21.21.7 pvesr set-state 504 \''{}'\'
  Logical volume "vm-504-disk-0" successfully removed.
2026-08-02 08:45:10 start final cleanup
2026-08-02 08:45:12 migration finished successfully (duration 00:00:52)
TASK OK
 
Last edited:
good morning, maybe your remount of or nas share don't work correct and now you are working local on the mount point?
 
The storage is not shared.
I enabled the option and then disabled it to verify that I hadn't accidentally moved the VMs to the wrong node with the files on the other. But that's not the case.
Anyway: CT (LXC) VMs, Linux VM migrations, no problem, VM migrations with RAW disks have no issues. However, the problem is with Windows VMs with QCOW2 format disks (essential because I need snapshots).
@news: If I switch from LVM NAS storage, no problem except for the longer migration time (it's a 1GB network).
@longer: what's is vgs (excuse i don't understand)
 
Last edited:
Frank-75 said:
The storage is not shared.
I enabled the option and then disabled it to verify that I hadn't accidentally moved the VMs to the wrong node with the files on the other. But that's not the case.
Anyway: CT (LXC) VMs, Linux VM migrations, no problem, VM migrations with RAW disks have no issues. However, the problem is with Windows VMs with QCOW2 format disks (essential because I need snapshots).
@news: If I switch from LVM NAS storage, no problem except for the longer migration time (it's a 1GB network).
@longer: what's is vgs (excuse i don't understand)
Click to expand...
Hmm so the problem only occurs whenever you use qcow2, Interesting finding.
I am not aware of such problems when using snapshot-as-volume chain. I will try to reproduce and share my result.
 
Last edited:
Thank's!
Notes:
the migration with QCOW2 works only if I do 2 step: 1° move disk to i-SCSI lvm (NAS) and 2° move to datastore 2° NODE A-to-B and B-to-A same issues. VM migration issues with Windows Server 2016, 2019 and 2022. Linux: Debian and ubuntu no issues. VM with RAW disk no issues.
Proxmox patched with last update on all nodes (9.2.6), nodes are rebooted.
Last week (Proxmox 9.2.4) i have migrated from same storage but formatted ext4 (no migration issues). - snapshot preview feature enabled on all nodes.
 
VM Windows Server 2016 (with last security updates), this is on node A (ML350gen8)
Code: 
agent: 1
balloon: 6144
bios: ovmf
boot: 
cores: 1
cpu: kvm64
efidisk0: LOCALSTORE_RAID5_VM:vm-101-disk-0.qcow2,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=528K
hotplug: disk,usb
machine: pc-q35-10.0+pve1
memory: 8192
meta: creation-qemu=9.2.0,ctime=1761210810
name: DCSrv2016A
net0: virtio=BC:24:11:72:50:C1,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
sata2: none,media=cdrom
scsi0: LOCALSTORE_RAID5_VM:vm-101-disk-2.qcow2,cache=writethrough,iothread=1,size=100G
scsi1: LOCALSTORE_RAID5_VM:vm-101-disk-1.qcow2,cache=writethrough,iothread=1,size=80G
scsihw: virtio-scsi-single
smbios1: base64=1,manufacturer=SFBF,uuid=aaaa18a5-a67f-492a-8763-7aaaaaaaaaaa
sockets: 2
vga: qxl,memory=8
vmgenid: a94aa37-90aa-4a3a-a5aa-aaa7220aaaaa

VM Windows Server 2019 (with last security updates), this is on node B (DL160gen9)

Code: 
agent: 1
balloon: 12288
bios: ovmf
boot: order=scsi0;net0
cores: 2
cpu: x86-64-v2-AES
cpulimit: 6
efidisk0: LOCALSTORE_RAID5_VM:vm-106-disk-1.qcow2,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=528K
machine: pc-q35-10.0+pve1
memory: 16384
meta: creation-qemu=11.0.0,ctime=1780815781
name: WEBsrv2022A
net0: virtio=BC:24:11:BB:54:10,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsi0: LOCALSTORE_RAID5_VM:vm-106-disk-2.qcow2,cache=writethrough,discard=on,iothread=1,size=150G
scsihw: virtio-scsi-single
smbios1: uuid=8aaa6a2a-39aa-4526-9aaaa-6a553aaaaaaa8,manufacturer=SFBF,base64=1
sockets: 4
tpmstate0: LOCALSTORE_RAID5_VM:vm-106-disk-0.qcow2,size=4M,version=v2.0
vga: virtio,memory=8
vmgenid: 15286aaa-88aa-4aa9-9aaa-78aaaaaaaaaa

thank's in advance for your help!
 
Okay, I will test this and update you hopefully tomorrow.

If possible please also share journalctl log from the source pve covering the migration time, for example:
root@pve :# journalctl --since "2026-08-xx xx:00:00" --until "2026-08-yy yy:00:00" > /tmp/syslog.txt.gz

Please adjust the date and time as needed to cover the migration time and include some hours before and after the migration time.

--
There's one limitation mentioned in prxmox wiki regarding snapshot as volume chain:
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Storage_boxes_(SAN/NAS)
"When using "Snapshots as Volume-Chain" (technology preview) with VMs with TPM state, the top-most snapshot cannot be removed while the VM is running.
"
It doesn't seems releated to migration in general but wanted to mentioned anyway.
 
Hi,

This is expected behavior. Although both nodes have an LVM storage with the same name, they are still separate local storages. Proxmox does not support storage migration directly from local LVM to local LVM, which is why you see the error
 
If so, it would have been better to know in advance that LVM is worse for my purpose. In all the posts I read, users have configurations with LVM datastores, not Directory.
 
powersupport said:
Hi,

This is expected behavior. Although both nodes have an LVM storage with the same name, they are still separate local storages. Proxmox does not support storage migration directly from local LVM to local LVM, which is why you see the error
Click to expand...
Where is this mentioned? could you please add link to wiki or pve doc mentioning this?

I have tested with local lvm for linux vm it work with no error (I will check win vms as well and share result whenever I got time):
Bash: 
root@node3:~# grep "node3-lvm" /etc/pve/storage.cfg -A6
lvm: node3-lvm
        vgname vg00
        content rootdir,images
        nodes node3,node4
        saferemove 0
        shared 0
        snapshot-as-volume-chain 1

root@node3:~# vgs
  VG                                        #PV #LV #SN Attr   VSize   VFree 
..
  vg00                                        2   1   0 wz--n-  51.99g <46.99g


# Node 4, notice diffrent size vg
root@node4:~# vgrename node4 vg00
  Volume group "node4" successfully renamed to "vg00"

root@node4:~# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg00   1   1   0 wz--n- <15.00g 6.99g

root@node4:~# pvesm status --storage node3-lvm
Name             Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
node3-lvm         lvm     active        15724544         8392704         7331840   53.37%



here is migration task:

Code: 
2026-08-03 11:16:38 starting migration of VM 100 to node 'node4'
2026-08-03 11:16:38 found local disk 'node3-lvm:vm-100-disk-0.qcow2' (attached)
2026-08-03 11:16:38 starting VM 100 on remote node 'node4'
2026-08-03 11:16:40 volume 'node3-lvm:vm-100-disk-0.qcow2' is 'node3-lvm:vm-100-disk-0.qcow2' on the target
2026-08-03 11:16:40 start remote tunnel
2026-08-03 11:16:41 ssh tunnel ver 1
2026-08-03 11:16:41 starting storage migration
2026-08-03 11:16:41 scsi0: start migration to nbd:unix:/run/qemu-server/100_nbd.migrate:exportname=drive-scsi0
drive mirror is starting for drive-scsi0
mirror-scsi0: transferred 1.3 GiB of 8.0 GiB (16.25%) in 1s
mirror-scsi0: transferred 1.7 GiB of 8.0 GiB (21.50%) in 2s
mirror-scsi0: transferred 3.0 GiB of 8.0 GiB (37.34%) in 3s
mirror-scsi0: transferred 8.0 GiB of 8.0 GiB (100.00%) in 4s, ready
all 'mirror' jobs are ready
2026-08-03 11:16:45 switching mirror jobs to actively synced mode
mirror-scsi0: switching to actively synced mode
mirror-scsi0: successfully switched to actively synced mode
2026-08-03 11:16:46 starting online/live migration on unix:/run/qemu-server/100.migrate
2026-08-03 11:16:46 set migration capabilities
2026-08-03 11:16:46 migration downtime limit: 100 ms
2026-08-03 11:16:46 migration cachesize: 256.0 MiB
2026-08-03 11:16:46 set migration parameters
2026-08-03 11:16:46 start migrate command to unix:/run/qemu-server/100.migrate
2026-08-03 11:16:47 average migration speed: 2.0 GiB/s - downtime 73 ms
2026-08-03 11:16:47 migration completed, transferred 247.7 MiB VM-state
2026-08-03 11:16:47 migration status: completed
all 'mirror' jobs are ready
mirror-scsi0: Completing block job...
mirror-scsi0: Completed successfully.
mirror-scsi0: mirror-job finished
2026-08-03 11:16:49 stopping NBD storage migration server on target.
2026-08-03 11:16:50 stopping migration dbus-vmstate helpers
2026-08-03 11:16:50 migrated 0 conntrack state entries
2026-08-03 11:16:52 flushing conntrack state for guest on source node
  Logical volume "vm-100-disk-0.qcow2" successfully removed.
2026-08-03 11:16:54 migration finished successfully (duration 00:00:16)
TASK OK
 
@Frank-75 please post the full migration task log, and the full "pveversion -v" output from both source and target node.
 
You must log in or register to reply here.
Top Bottom
Back