Recent content by tsumaru720

https://bugzilla.proxmox.com/show_bug.cgi?id=4883

Hello Lets say I have a primary backup server, and have pruning + GC configured on it. Lets also say I have another server that exists only to sync from the primary and that I've enabled "Remove Vanished" - Do I still need to set up prune and gc jobs on the sync server?

https://bugzilla.proxmox.com/show_bug.cgi?id=4844

Alright, I think this is a bug in qmeventd https://github.com/proxmox/qemu-server/blob/master/qmeventd/qmeventd.c#L104-L140 Looking at the code, it appears to look for lines that have "qemu.slice" and tries to extract the VM id from it. For some reason the list of cgroups on my other two...

I'm not sure if it makes a difference or not, but here is the contents of /proc/<pid>/cgroup of the VM On the "working" node, ie, the one that doesn't fill syslog # cat /proc/$(ps auxf | grep kvm | grep " 102 " | awk '{print $2}')/cgroup 13:hugetlb:/ 12:memory:/qemu.slice/102.scope...

It might be related to telemetry reporting

I used the PVE GUI to install ceph, but as far as i can tell it is set up and working correctly on all my nodes - ceph status shows all is ok The "crash" file was generated at the time of system boot, but the syslog errors seem to be something trying to do something with it. Looking at the...

Hello, I've recently built out a new PVE8 cluster and set up ceph - I've noticed that on rebooting a node, it seems to generate a ceph crash file, and then fails to process it 2023-07-12T13:50:06.996554+01:00 pve1 ceph-crash[1904]: WARNING:ceph-crash:post...

Hi, I have a 3 node pve cluster. I have an "opnsense" vm running on iscsi storage. I've noticed the following error getting spammed in syslog 2023-07-12T13:40:58.394754+01:00 pve1 qmeventd[1946]: unexpected cgroup entry 13:blkio:/qemu.slice 2023-07-12T13:40:58.395072+01:00 pve1...

Thanks @spirit - i think that'll be my answer...turn off vlan-aware and let it just do the extra interfaces/bridges

Hi @Hannes Laimer 1. Double-check your network configuration: First, please make sure that your network configuration is correct. In particular, ensure that the VLAN IDs for each of your vnets match their respective VLAN tags. Also, check that you've correctly configured the "vlan-aware"...

Hey all Previously my networking was as follows vmbr0 attached to eth1 - vmbr0 used for management IP. Management vlan is untagged. vmbr110 attached to eth1.110 - no ip on host vmbr120 attached to eth1.120 - no ip on host vmbr130 attached to eth1.130 - no ip on host etc to use for guest...

It'd be nice to have something to highlight which backups are changing the most and consuming space in the datastore. I've seen a few forum posts that discuss this already and I understand the limitations of processing this on-demand. Regardless of the deduplication, it'd be nice if there was...

I'm leaning on experience with other backup solutions here - but whilst there may not be 438GB of changes, there will likely be lots of small changes inside chunk boundaries... Lets say your chunk sizes are 4MB (I think its 4MB fixed for VMs?) for example and lets say that MSSQL makes a teeny...

oh ok, so even though the client reported that it had to back up the entire container, thats just the upload to the PBS server and it was likely deduplicated as it was written? I just dont get visibility of how much dedupe happened because there's no previous index for this CT i guess?