Search results

With the fsfreeze-thaw command

From the cmdline of the host : root@pve:~# qm agent 119 fsfreeze-status thawed root@pve:~# qm agent 119 fsfreeze-freeze 5 root@pve:~# qm agent 119 fsfreeze-status frozen root@pve:~# qm agent 119 fsfreeze-thaw 5 root@pve:~# qm agent 119 fsfreeze-status thawed root@pve:~# If you can reproduce...

OK, now that we're sure the issue is when using the guest-agent, you can try to debug a bit more. Try to enable it again and see what's happening if you manually send a guest-fsfreeze-freeze command

Yes, toggling this setting needs a VM reboot to take effect.

Without the qemu agent, the backup will be made the same way. But without the FS freeze in the guest. So the FS might need an fsck in case of a restore (it'll be in the same state as it would be if there was a power cut at the time of the backup). The qemu agent just make this a little bit more...

Try to disable the qemu-agent option from proxmox and see if the problem disappear. This would confirm an issue with the freeze operation ran by the guest, and will help debuging it further.

OK but is the agent enabled and running ? Try to disable the option in Proxmox and check if the issue is still present.

Would you happen to have enabled the qemu guest agent feature while qemu guest agent is not installed in the guest ?

Sorry, my bad, I miss read your top screenshot. It's indeed ~7.5GB of free mem, not buffers (which only account 22M). Not sure where the diff comes from. Probably something to do with the way the FreeBSD kernel frees memory

Because caches and buffers are not accounted in the used memory from the guest POV, but is still used memory from the host POV (you can see ~7.5GB being used as buffers).

This has always been the case. That's the purpose of ballooning, so I'm not sure I understand the problem

My 2 cents : give up now. OVH CDA is just not up to the task (I tried). It's far too slow to be used by anything, even lightly loaded test VM

Nop, sorry. Have no idea where this corruption may come from

No. All disks must support snapshots. There's no way for now to exclude a disk from a snapshot

This has nothing to do with the cpu model but it's about the storage : you are using raw files, which do not support snapshots. Check https://pve.proxmox.com/wiki/Storage

What storage are you using ? Are you sure files were not already corrupted ? Any backup to compare the affected files ?

Instead of manually converting the image and injecting it with dd, I'd recommend using qm importdisk (see man qm) which will do nearly everything required

I don't think so. You would still risk split-braining your /etc/pve FS, so it wouldn't be safe at all

No. For VM, Proxmox creates zvols, which are presented as raw block devices. You must use another FS inside the guest (except for very specific use cases). You will not loose all the benefit of ZFS : snapshot, compression etc... can be managed at the proxmox level

I'd avoid installing stuff on proxmox itself (especially Docker which will probably insert its own iptables rules and mess up the ones from Proxmox). Install Gitlab in a guest. Either a VM or a container (or a Docker inside a VM). Choose the guest OS you're confortable with.