qcow2 image: ERROR refcount block 69 is outside image

Question

I have this backup.qcow2 image which was working fine in my kvm/qemu virtual machine before.

When I attach it to another virtual machine, Windows recognizes the disk but fails to read partitions. The disk appears in the state initial in Disk Management.

The file format is qcow2 Version 2:

# qemu-img info backup.qcow2
 file format: qcow2
 virtual size: 246G (263704281088 bytes)
 disk size: 137G
 cluster_size: 65536
 Format specific information:
    compat: 0.10
    refcount bits: 16

Note the format compat: 0.10. I'm not sure if it matters in this case.

I run other images which work fine, but have the compat:1.1 setting, which is Version 3 of qcow2.

The vm config part of the disk:

<disk type='file' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source file='/opt/libvirt/backup.qcow2'/>
  <target dev='vdc' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</disk>

Hexeditor on that image reveals qcow2 header, some NTFS markers and relevant user data is visible, so I presume the image has valid data.

Inspecting the image tells me:

#qemu-img check backup.qcow2
**ERROR refcount block 69 is outside image**
Leaked cluster 3 refcount=1 reference=0
...
1 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.

1966018 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
Image end offset: 147866845184

and

#virt-rescue --ro -a backup.qcow2
...
><rescue> fdisk -l /dev/sda
Disk /dev/sda: 245.6 GiB, 263704281088 bytes, 515047424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

><rescue> gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

I'm not sure of the guest partitioning but I assume it was GPT and NTFS filesystem.

I converted the image into raw format, but it finishes in one second and I can see only 00 bytes

qemu-img convert -f qcow2 -O raw backup.qcow2 backup.raw

How do I approach this case? It may be just a misconfiguration in the host vm.

Or do I need a valid partition table first, before I can access any data. How would I restore that?

Host-System: Linux (Fedora 28), Virtual Machine Manager Guest-System: Windows 7, Windows 2016

Update

# dnf history info 92
Packages Altered:
Upgraded ethtool-2:4.17-1.fc28.x86_64                 @updates
Upgrade          2:5.0-1.fc28.x86_64                  @updates
Upgraded fuse-common-3.4.2-2.fc28.x86_64              @updates
Upgrade              3.4.2-6.fc28.x86_64              @updates
Erase    kernel-4.20.16-100.fc28.x86_64               @updates
Install  kernel-5.0.16-100.fc28.x86_64                @updates
Erase    kernel-core-4.20.16-100.fc28.x86_64          @updates
Install  kernel-core-5.0.16-100.fc28.x86_64           @updates
Upgraded kernel-headers-5.0.9-100.fc28.x86_64         @updates
Upgrade                 5.0.16-100.fc28.x86_64        @updates
Erase    kernel-modules-4.20.16-100.fc28.x86_64       @updates
Install  kernel-modules-5.0.16-100.fc28.x86_64        @updates
Erase    kernel-modules-extra-4.20.16-100.fc28.x86_64 @updates
Install  kernel-modules-extra-5.0.16-100.fc28.x86_64  @updates
Upgraded libqb-1.0.3-4.fc28.x86_64                    @fedora
Upgrade        1.0.5-1.fc28.x86_64                    @updates
Upgraded libxcrypt-4.4.4-2.fc28.x86_64                @updates
Upgrade            4.4.6-1.fc28.x86_64                @updates
Upgraded libxcrypt-devel-4.4.4-2.fc28.x86_64          @updates
Upgrade                  4.4.6-1.fc28.x86_64          @updates
Upgraded libzstd-1.3.8-1.fc28.x86_64                  @updates
Upgrade          1.4.0-1.fc28.x86_64                  @updates
Upgraded mediawriter-4.1.2-1.fc28.x86_64              @updates
Upgrade              4.1.4-1.fc28.x86_64              @updates
Upgraded microcode_ctl-2:2.1-26.fc28.x86_64           @updates
Upgrade                2:2.1-29.fc28.x86_64           @updates

It looks like something has corrupted the qcow2 file itself. Bad hard drive write, maybe? Cosmic rays? Who knows. I would be thinking about restoring from backup. — Michael Hampton, May 25 '19 at 17:03
Unfortunatly this is the backup. See my thirst sentence. The qcow2 header is intact and looks reasonable. — JanPl, May 25 '19 at 22:35
can you also confirm qemu version for source and destination? — asktyagi, May 26 '19 at 08:16
Actually both virtual machines are on the same host. So the current qemu version is identical, which is 2.11.2-5.fc28 by the way. There was an update though, see my supplement to the question. — JanPl, May 26 '19 at 12:26

score 0 · Answer 1 · answered May 26 '19 at 09:44

I am suspecting below things:

size (In first output it is showing 16 check the other node which is default for that machine)

can be b (8 bits), h (16 bits), w (32 bits) or g (64 bits). On x86, h or w can be specified with the i format to respectively select 16 or 32 bit code instruction size.

compat (May be both versions are different)

Determines the qcow2 version to use. compat=0.10 uses the traditional image format that can be read by any QEMU since 0.10. compat=1.1 enables image format extensions that only QEMU 1.1 and newer understand (this is the default). Amongst others, this includes zero clusters, which allow efficient copy-on-read for sparse images.

try make source and destination identical.

All images have refcount bits set to 16. I'm not sure what is ment by source and destination. — JanPl, May 26 '19 at 21:43

qcow2 image: ERROR refcount block 69 is outside image

1 Answers1