Issue migrating HyperV VM to Proxmox

[Dennis Ayala]

I am converting a Hyper-V virtual machine into Proxmox.

I exported the machine and copied the VHDX files (100G & 800G respectively) to a NFS volume in the Proxmox node.

Did a:

qm importdisk <vmid> FILE.VHDX LVM-STORAGE-VOLUME

The first disk (100G) imported successfuly. The other one (800G) once it reached 100% it
errored out: can't deactivate LV ...
/dev/mapper/LVM-NAME/vm-vmid-disk-1 is in use

Then it removed the vm-vmid-disk-1 successfully.

i am running ProxMox 6.4.8.
My storage is Fibre Channel Storage mounted as LVM shared,

Any idea as to why the 800G would error out but the 100G imports fine?

Regards,

Dennis

 

[Dominic]

Hi,

could you please post your current VM configuration & existing logical volumes?
For example, if your VMID is 100

cat /etc/pve/qemu-server/100.conf
lvs --select name=~vm-100

 

[Dennis Ayala]

Hi,

could you please post your current VM configuration & existing logical volumes?
For example, if your VMID is 100

cat /etc/pve/qemu-server/100.conf
lvs --select name=~vm-100

Hi Dominic! Here it is:

# cat /etc/pve/qemu-server/1018.conf agent: 1 boot: order=ide2;ide0 cores: 2 ide0: IBM-SAS-900G-PROD-07:vm-1018-disk-1,cache=writeback,size=100G ide2: ISOs:iso/virtio-win-0.1.190.iso,media=cdrom machine: pc-i440fx-5.2 memory: 16384 name: MTIPR-SQL net0: virtio=3A:7A:3F:A0:45:82,bridge=vmbr0,firewall=1,tag=1012 numa: 0 onboot: 1 ostype: win10 scsihw: virtio-scsi-pci smbios1: uuid=327e68cf-9cd3-47a2-97c1-627ee6411ad5 sockets: 2 vmgenid: 16830996-6131-4849-a708-c5a6d378e068

Right now I am attempting the import again so you'll see the 800G in the LVS output:

# lvs --select name=~vm-1018 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert vm-1018-disk-0 IBM-SAS-900G-PROD-07 -wi-ao---- 800.00g vm-1018-disk-1 IBM-SAS-900G-PROD-07 -wi-a----- 100.00g

Regards,

Dennis

 

[Dominic]

Thank you! The output looks reasonable.

Let's see if it works now. If not then I'll try to recreate it. In this case I'd appreciate if you could post the full log output of the import.

 

[Dennis Ayala]

Thank you! The output looks reasonable.

Let's see if it works now. If not then I'll try to recreate it. In this case I'd appreciate if you could post the full log output of the import.

Where can I find that log exactly?

 

[Dominic]

I meant just all lines after you enter qm importdisk <vmid> FILE.VHDX LVM-STORAGE-VOLUME

 

[Dennis Ayala]

I meant just all lines after you enter qm importdisk <vmid> FILE.VHDX LVM-STORAGE-VOLUME

Ohhh, ok.

Process is at 28% right now. I will keep you posted.

Thank you,

Dennis

 

[Dennis Ayala]

I meant just all lines after you enter qm importdisk <vmid> FILE.VHDX LVM-STORAGE-VOLUME

It errored out again.

transferred 792.2 GiB of 800.0 GiB (99.02%) transferred 800.0 GiB of 800.0 GiB (100.00%) transferred 800.0 GiB of 800.0 GiB (100.00%) can't deactivate LV '/dev/IBM-SAS-900G-PROD-07/vm-1018-disk-0': Logical volume IBM-SAS-900G-PROD-07/vm-1018-disk-0 in use. Logical volume "vm-1018-disk-0" successfully removed volume deactivation failed: IBM-SAS-900G-PROD-07:vm-1018-disk-0 at /usr/share/perl5/PVE/Storage.pm line 1151.

Regards,

Dennis

 

[Dominic]

Does the log say something like

  Logical volume "vm-1018-disk-0" created.

before the transfer starts?

 

[Dennis Ayala]

Does the log say something like

  Logical volume "vm-1018-disk-0" created.

before the transfer starts?

I'm not 100% sure it does.I might have to try again to see if it does.
I was able to coonvert the machine by manually creating the disk and using Clonezilla to remotely copy the disk from source.

For the benefit of this argument, I will try the process again on a temp VM and post the results here again.

Regards,

Dennis

 

[Dennis Ayala]

Does the log say something like

  Logical volume "vm-1018-disk-0" created.

before the transfer starts?

Yes it did.

 

[Dominic]

Thanks for checking, this output is good.

Unfortunately, I have not been able to reproduce this yet. In the importdisk command the deactivation happens directly after calling qemu-img convert.

  72         PVE::QemuServer::qemu_img_convert($src_path, $dst_volid, $src_size, undef, $zeroinit);
  73         PVE::Storage::deactivate_volumes($storecfg, [$dst_volid]);
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/ImportDisk.pm;h=51ad52eab43ebad24a104de116dc5eea88587c7a;hb=HEAD#l73

So for some reason the LV is in use after qemu_img_convert on your host but not on mine. Have you touched any logical volumes during the import(s)?

 

[Dennis Ayala]

Thanks for checking, this output is good.

Unfortunately, I have not been able to reproduce this yet. In the importdisk command the deactivation happens directly after calling qemu-img convert.

  72         PVE::QemuServer::qemu_img_convert($src_path, $dst_volid, $src_size, undef, $zeroinit);
  73         PVE::Storage::deactivate_volumes($storecfg, [$dst_volid]);
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/ImportDisk.pm;h=51ad52eab43ebad24a104de116dc5eea88587c7a;hb=HEAD#l73

So for some reason the LV is in use after qemu_img_convert on your host but not on mine. Have you touched any logical volumes during the import(s)?

No.

 

[Dennis Ayala]

Thanks for checking, this output is good.

Unfortunately, I have not been able to reproduce this yet. In the importdisk command the deactivation happens directly after calling qemu-img convert.

  72         PVE::QemuServer::qemu_img_convert($src_path, $dst_volid, $src_size, undef, $zeroinit);
  73         PVE::Storage::deactivate_volumes($storecfg, [$dst_volid]);
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/ImportDisk.pm;h=51ad52eab43ebad24a104de116dc5eea88587c7a;hb=HEAD#l73

So for some reason the LV is in use after qemu_img_convert on your host but not on mine. Have you touched any logical volumes during the import(s)?

The funny thing is that it only happens with some disks above 500G, the others convert fine.

 

[Dennis Ayala]

Thanks for checking, this output is good.

Unfortunately, I have not been able to reproduce this yet. In the importdisk command the deactivation happens directly after calling qemu-img convert.

  72         PVE::QemuServer::qemu_img_convert($src_path, $dst_volid, $src_size, undef, $zeroinit);
  73         PVE::Storage::deactivate_volumes($storecfg, [$dst_volid]);
https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer/ImportDisk.pm;h=51ad52eab43ebad24a104de116dc5eea88587c7a;hb=HEAD#l73

So for some reason the LV is in use after qemu_img_convert on your host but not on mine. Have you touched any logical volumes during the import(s)?

I also noticed another thing after upgrading to 6.4.

All my FC LUNs which are 3.351TB (Raw) and 3.27 after formatted used to show @ 3.27 TB on Proxmox 6.3 but after upgrading to 6.4 and in new installs using 6.4 Proxmox show the volumes at 3.60TB which is wrong.

I don't know if this might cause the issue or not but it's something to look at,

Regards,

Dennis

 

[Dennis Ayala]

So for some reason the LV is in use after qemu_img_convert on your host but not on mine. Have you touched any logical volumes during the import(s)?

Dominic:

I ran the process again and it was successful.
I converted all disks prior to assigning them on the VM.
The issue could have been that while the second disk was being imported I was assigning the previously imported disk to the VM and the import process found the second LV in use although the disk is still not available in the VM though.

Regards,

Dennis