dataloss when migrating from qcow2 or raw to lvm

[SL-FH]

Out environment is PVE 8.4.1, 3 Nodes connected to an iSCSI storage. Multipathd is configured. LVM is configured as shared storage.

When a harddisk is cloned from qcow2 or raw images to LVM then all non NULL blocks are equal and NULL blocks are potentially filled with old data. The result are corrupt disks. Full filled disks are OK.

Steps to reproduce:
1. Attach a VM with qcow2 image
2. Fill the image with some data
3. Move image to LVM

Required bugfix: Overwrite NULL Blocks on target LVM volume.

 

[SL-FH]

It looks like setting the “saferemove” feature can help, but the current default behavior can lead to data loss.

 

[Magnus-mercer]

Maybe there are other ways:

1: Use qemu-img convert to preallocate and zero out

qemu-img convert -O raw -o preallocation=full,zero /path/to/source.qcow2 /dev/mapper/vgname-lvname

This forces all blocks—including NULL blocks—to be zeroed before writing to the LVM.


2: Enable zeroing when creating an LV (for non-thin LVs)

lvcreate --size 10G --zero y --name vm-301-disk-0 vgname

The --zero y flag wipes all blocks during LV creation.

 

[spirit]

2: Enable zeroing when creating an LV (for non-thin LVs)

lvcreate --size 10G --zero y --name vm-301-disk-0 vgname

The --zero y flag wipes all blocks during LV creation.

--zero only zeroing first kb , and it's enabled by default

https://linux.die.net/man/8/lvcreate

-Z, --zero {y|n}Controls zeroing of the first KB of data in the new logical volume.
Default is yes.
Volume will not be zeroed if read only flag is set.
Snapshot volumes are zeroed always.
Warning: trying to mount an unzeroed logical volume can cause the system to hang.

 

[fiona]

Hi,
just guessing, but some storage(s) have broken fallocate implementations, see: https://bugzilla.proxmox.com/show_bug.cgi?id=5754#c17 and earlier comments.