Corrupt Filesystem after snapshot

I can confirm it does happen with SCSI Virtio devices, too, and neither do I think it's related to QNAP/Synology. NFS share on FreeNAS showed the same symptoms, unfortunately.

Strange thing is: Some Vms (all Debian) do snapshots just fine and some (Debian, too) end up with a corrupted filesystem.

I have not found a way to reproduce this reliably though.
 
Jan 18, 2017
97
2
8
36

dkuo

New Member
Mar 13, 2018
2
0
1
40
This just happened to me in my environment as well. I had a VM on a Synology and created many snapshots without problems until I migrated it to a different host. At that point when I tried to create another snapshot it failed. Luckily I could create a clone from a snapshot I had made earlier in the week.
 

dmulk

Member
Jan 24, 2017
66
3
13
45
This is still an issue! Any news? Any way to work around this issue or recover from it?

<D>
 

GadgetPig

Member
Apr 26, 2016
138
19
18
50
Those of you with qcow2/NFS/Virtio combo and getting corruption, could you also test if the corruption happens with a CIFS/SMB share on the NAS? I was just curious if the type of share has any effect.
thnx
 
Dec 26, 2017
8
0
1
40
I've been avoiding snapshots due to the possibility of the corruption issue still existing. I'll try test again on a non-critical VM when I get a chance.
A good point @GadgetPig - I don't have the environment to test CIFS/SMB at this time, but I am interested to hear how it goes, if others do get around to testing what you've suggested.
 
Jul 18, 2018
1
0
1
15
We've been using snapshot functionality for years (since 3x) and never got such problems .

Now we got the same issues (sometimes corupted qcow images by snaphoting) - according the others posts may it be somehow related to 4.4.xversion ???

All the time we use the same config - The same HP servers, images on local disk with HW array, ext4, qcow image.

"Funny" is that there are no errors in the host area - just corrupted image.

Does someone found what's wrong going on?

Thanks
Petr

ps: yes, we can use LVM, but not everyone like it or they may have own needs.
 
Aug 19, 2018
2
0
1
51
Hi Members,
i run into the same Problem. But after a small analysis I mean i have found the problem and have also a solution:

It's a hardisk Cache Problem with VirtIO in combination of caching...
If I use the "write back" cache for my VMs - I have the Problem :-(
If I use the "Default (No Cache)" Option - I haven't any Problems :)

I hope this can help.
 

dkuo

New Member
Mar 13, 2018
2
0
1
40
Hi Members,
i run into the same Problem. But after a small analysis I mean i have found the problem and have also a solution:

It's a hardisk Cache Problem with VirtIO in combination of caching...
If I use the "write back" cache for my VMs - I have the Problem :-(
If I use the "Default (No Cache)" Option - I haven't any Problems :)

I hope this can help.
The disks were already using the default of "No Cache" for us when I had the problem.
 
Aug 19, 2018
2
0
1
51
Hi Bart, hi dkuo,
i have no more idea, sorry.
But i have checked my Proxmox Server (5.2) now for one more week with Windows Server 2016 and also Linux (Lubuntu) VMs. I tried many Snapshots with two "Test-VMs" and take snapshots in deep (a snapshot recursion with more than 3 snapshots for a VM).
I did not have problems with this VMs after create and delete the snapshots.
But if i have in near future snapshot problems i will write it here in this "thread"
Thanks and best regards,
Matthias
 

cvhideki

Member
Jan 19, 2016
5
0
6
33
Hi guys,
i have same problem after Rollback my VM (Proxmox 5.2-5)
My VM after works 5-10 min. and gives an error "File system read only"
My VM use "write back" cache, tried changed to default of "No Cache", result not successful has Corrupt Filesystem (2 screen)
run check qcow2 iso
qemu-img check -r all /var/lib/vz/images/100/vm-100-disk-1.qcow2

Repairing OFLAG_COPIED data cluster: l2_entry=8000000220230000 refcount=2
The following inconsistencies were found and repaired:

955254 leaked clusters
42 corruptions

Double checking the fixed image now...
No errors were found on the image.
1064960/1064960 = 100.00% allocated, 3.68% fragmented, 0.00% compressed clusters
Image end offset: 79676964864

but i still have broken VM and file system to him

maybe any have idea how resolve them?
 

Attachments

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!