ESXi import fails at a reproducible offset with "qemu-img: error while reading ... Input/output error"

P

pastrufazio

New Member
Jun 23, 2026
3
2
3
Hi,

I'm trying to import a VM from VMware into Proxmox VE and the import consistently fails at the exact same offset.

Environment​

VMware​

vCenter Server 6.7.0 (build 20504362)
ESXi 6.7.0 Update 3 (build 16713306)

Proxmox​

proxmox-ve: 9.2.0
pve-manager: 9.2.3
qemu-server: 9.1.16
pve-esxi-import-tools: 1.0.1
pve-qemu-kvm: 11.0.0-4
kernel: 7.0.6-2-pve

Import details​

Using the built-in ESXi import functionality from the Proxmox GUI.

Source VM: srvtestfe
Source datastore: Sviluppo/datastore1
Disk size: 150 GB
Destination storage: ZFS zvol

Error​

The import proceeds normally until about 83% and then fails every time:

transferred 94.6 GiB of 150.0 GiB (63.08%)
transferred 96.1 GiB of 150.0 GiB (64.08%)
transferred 97.6 GiB of 150.0 GiB (65.08%)
transferred 99.1 GiB of 150.0 GiB (66.09%)
transferred 100.6 GiB of 150.0 GiB (67.09%)
transferred 102.1 GiB of 150.0 GiB (68.09%)
transferred 103.6 GiB of 150.0 GiB (69.09%)
transferred 105.1 GiB of 150.0 GiB (70.09%)
transferred 106.6 GiB of 150.0 GiB (71.09%)
transferred 108.1 GiB of 150.0 GiB (72.09%)
transferred 109.6 GiB of 150.0 GiB (73.10%)
transferred 111.1 GiB of 150.0 GiB (74.10%)
transferred 112.6 GiB of 150.0 GiB (75.10%)
transferred 114.1 GiB of 150.0 GiB (76.10%)
transferred 115.6 GiB of 150.0 GiB (77.10%)
transferred 117.1 GiB of 150.0 GiB (78.10%)
transferred 118.6 GiB of 150.0 GiB (79.10%)
transferred 120.1 GiB of 150.0 GiB (80.10%)
transferred 121.7 GiB of 150.0 GiB (81.11%)
transferred 123.2 GiB of 150.0 GiB (82.11%)
transferred 124.7 GiB of 150.0 GiB (83.11%)
qemu-img: error while reading at byte 135190774784: Input/output error
TASK ERROR: unable to create VM 1007 - cannot import from 'vsphere-dev:Sviluppo/datastore1/srvtestfe/srvtestfe.vmdk' - copy failed: command '/usr/bin/qemu-img convert -p -n -t none -f vmdk -O raw /run/pve/import/esxi/vsphere-dev/mnt/Sviluppo/datastore1/srvtestfe/srvtestfe.vmdk zeroinit:/dev/zvol/rapido/vm-1007-disk-0' failed: exit code 1

transferred 124.7 GiB of 150.0 GiB (83.11%)
qemu-img: error while reading at byte 135190774784: Input/output error

TASK ERROR: unable to create VM 1007 - cannot import from
'vsphere-dev:Sviluppo/datastore1/srvtestfe/srvtestfe.vmdk' - copy failed:
/usr/bin/qemu-img convert -p -n -t none -f vmdk -O raw \
/run/pve/import/esxi/vsphere-dev/mnt/Sviluppo/datastore1/srvtestfe/srvtestfe.vmdk \
zeroinit:/dev/zvol/rapido/vm-1007-disk-0
failed: exit code 1

VMDK layout​

The descriptor file looks normal:
RW 314572800 VMFS "srvtestfe-flat.vmdk"
Files visible through the ESXi mount:
srvtestfe.vmdk
srvtestfe-flat.vmdk (150G)
srvtestfe_1.vmdk
srvtestfe.vmx

Troubleshooting performed​

I tested direct reads against the mounted VMDK from the Proxmox host.

Reading around 125 GiB succeeds:

Code: 
dd if=/run/pve/import/esxi/vsphere-dev/mnt/Sviluppo/datastore1/srvtestfe/srvtestfe-flat.vmdk \
of=/dev/null bs=1M skip=128000 count=100
Result:

Code: 
100+0 records in
100+0 records out
104857600 bytes copied
Reading slightly later consistently fails:

Code: 
dd if=/run/pve/import/esxi/vsphere-dev/mnt/Sviluppo/datastore1/srvtestfe/srvtestfe-flat.vmdk \
of=/dev/null bs=1M skip=128928 count=100
Result:

Code: 
dd: error reading '...srvtestfe-flat.vmdk': Input/output error
0+0 records in
0+0 records out
Another test:

Code: 
dd if=/run/pve/import/esxi/vsphere-dev/mnt/Sviluppo/datastore1/srvtestfe/srvtestfe-flat.vmdk \
of=/dev/null bs=1M skip=128927 count=2
Result:

Code: 
dd: error reading '...srvtestfe-flat.vmdk': Input/output error
1+0 records in
Code: 
1+0 records out
1048576 bytes copied
The failure is reproducible and always occurs at approximately the same offset.

Additional information​

The VM was fully operational on VMware before the migration attempt. It booted normally and had been actively used until I shut it down specifically to perform the migration to Proxmox. No filesystem errors, guest OS issues, or application-level problems had been observed while the VM was running on ESXi, and the VM has not shown any symptoms suggesting disk corruption during normal operation.

This is also not the only VM affected. I have successfully imported some VMs from the same VMware environment, but multiple VMs have failed during import with read errors. The failing VMs do not necessarily fail at the same percentage or offset, but the issue is reproducible for each affected VM.

Because more than one VM is involved, I'm wondering whether this could be related to the ESXi import mechanism itself, the ESXi datastore access layer, or a compatibility issue with this VMware 6.7 environment, rather than corruption of a single VMDK.

Questions​

At this point I'm trying to understand whether:

  1. The VMDK itself contains unreadable blocks.
  2. There is an issue with the underlying VMFS datastore.
  3. The problem is related to the ESXi import/FUSE layer used by Proxmox.
Since the read error is reproducible through: /run/pve/import/esxi/... is there a way to determine whether the error originates from the ESXi datastore itself or from the Proxmox ESXi import layer?

Has anyone seen a similar issue with the ESXi import tool?

Are there any additional diagnostics I should run from the Proxmox side before attempting VMware-side actions such as snapshot consolidation or cloning the VM?

Thanks!
 
I have not encountered this exact error myself, but I think cloning the VM on the ESXi side would be a useful way to narrow down possibilities 1 and 2.

For example, if a VMware-native clone using vmkfstools fails as well, then the issue is more likely to be on the VMware side, or the underlying storage. If the clone succeeds, then the Proxmox ESXi import/FUSE layer becomes more suspicious.
Cloning the VM or disk to a different datastore, ideally to a non-VMFS datastore such as NFS if available, may also help determine whether the issue is related to the original VMFS datastore. However, a clone failure alone may not perfectly distinguish between a VMDK-level issue and a datastore/storage-level issue, so checking the ESXi logs and the datastore/storage health would still be useful.

There are also migration methods other than the import wizard, so it may be worth trying one of them:

https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE
https://pve.proxmox.com/wiki/Advanced_Migration_Techniques_to_Proxmox_VE

If the VMDK itself is readable, the “Attach Disk & Move Disk” method may also be an option.
If the problem is related to the VMDK format, descriptor, or the Proxmox import/FUSE path rather than actual unreadable guest-visible sectors, a P2V-style approach using Clonezilla may also be worth considering. Clonezilla works at the guest disk level and can avoid some hypervisor/import-layer issues. However, if ESXi itself cannot read certain blocks of the virtual disk, Clonezilla may still hit read errors as well.
 
  • Like
Reactions: Onslow and waltar
Update:

I performed a VMware-native clone directly on the ESXi host using:

vmkfstools -i \
/vmfs/volumes/datastore1/srvtestfe/srvtestfe.vmdk \
/vmfs/volumes/datastore1/srvtestfe/srvtestfe-clone.vmdk \
-d thin

The clone progressed to:

Clone: 66% done.<br>Clone: 100% done.
but then terminated with:

Failed to clone disk: Input/output error (327689).
This suggests the problem is not limited to the Proxmox ESXi import mechanism, since a VMware-native cloning operation also encounters an I/O error when processing the same VMDK.
 
  • Like
Reactions: waltar
Further update:

After the vmkfstools clone failed, I checked vmkernel.log on the ESXi host.

The log shows direct read failures against the source VMDK during the clone operation:

Code: 
BC: read from srvtestfe-flat.vmdk ... failed: I/O error
FS3DM: status I/O error copying 1 extents between two files

In addition, the underlying storage device reported:

Device naa.60080e50002ebef60000089d58d22a33<br>Valid sense data: 0x3 0x11 0x0
From what I understand, this corresponds to a Medium Error / Unrecovered Read Error reported by the storage layer.

This seems to confirm that the failure is not specific to the Proxmox import mechanism, since the same read error is occurring during a VMware-native vmkfstools clone operation.

The VM itself remained fully operational before shutdown and had been running in production without visible guest OS errors.
 
  • Like
Reactions: waltar
Great job tracing it down @pastrufazio . The corrupted region of the disk was likely not needed/used by the VM and hence was not affecting the functionality. Of course one day a disk Write could have hit it and then you would have had an issue.

You can try "vmkfstools -x check" and "mkfstools -x repair" , or even
dd if=/path/to/disk-flat.vmdk of=/destination/path/disk-flat.vmdk conv=noerror,sync bs=1M

Of course you may not have a coherent vmdk in the end, its up to you. If you have a backup - that may be a good source.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
You must log in or register to reply here.
Top Bottom
Back