Search results

the snapshot volumes need to be active. could you describe which symptoms you are seeing exactly? the only time volumes are usually deactivated are - as part of error handling for freshly allocated volumes - as part of migration to another node if you are missing some deactivation when...

tracked at https://bugzilla.proxmox.com/show_bug.cgi?id=4853

which version are you running on the PBS server? this should be fixed with proxmox-backup-server >= 4.0.17-1

that's not 100% correct - there's two ways chunks can be detected as duplicate, either by the client or by the server. when creating a backup, the client only knows about the chunks referenced by the previous snapshot in the same group, and can therefor only deduplicate against those. in the...

flushing just means that those writes are not done sync (which is faster) so there is a backlog of them that still needs to be written out. for bulk data like this this is the best way to do it normally, I don't think the async-ness is the cause of your slowness here, rather the huge backlog is...

that sounds like flushing the pending writes at the end..

could you try without sync? but still, those numbers don't look super good..

sorry, I didn't read the log closely enough! could you try benchmarking the performance of an LV on your LVM storage (directly on the host) and then of a volume allocated to a VM from within the VM? keep in mind that a clone will incur a double network penalty, as it has to read from the...

and the synology?

possibly a regression caused by https://git.proxmox.com/?p=qemu-server.git;a=commitdiff;h=528df523161aa424cc6dca69230eae1f9a503cef @fiona ?

the whole clone took 1,5h? that's around 500mbit/s of throughput, depending on your network setup that might just be the bottle neck.. how is the connectivity to both storages?

seems like the patch got into 6.17 and 6.16.9, so it should be included in our kernels one way or another soon.

you can switch to chrony..

we haven't yet managed to reproduce this issue in our test lab (as far as I know), and the feedback regarding the patch was not 100% good, so we need more testing. if you are on 9.x, you can also try the 6.17 opt in kernel.

the built-in file restore can only recover what is (easily) readable in a linux VM using the vanilla ntfs3 driver from the linux kernel. anything else requires a windows VM, which needs to be done manually.

don't fret - apparmor is complicated and often not easy to debug either, so misunderstanding things can easily happen.

I think it is likely possible to "heal" the node, but if you want to proceed with reinstallation, that's of course also fine! the log message by corosync indicates that the other nodes reject the upgraded node's traffic because it's not originating from the expected address. this usually...

those look okay to me. what about corosync.conf and the network config? "journalctl -b" from the first boot after the full-upgrade would also be interesting.

could you please save /var/log/apt/* before reinstalling, and provide the contents? the symptoms all look like you did some sort of partial upgrade because of a repository misconfiguration.. maybe you also had pending network changes that got activated by the reboot? those would explain why...

that's not true, our 6.14 kernel supports *more* than ABI 4.0 by virtue of being based on the Ubuntu kernel, which means it carries custom apparmor-upstream patches not yet mainlined. the profiles that don't work don't have an ABI specified, which means they fallback to a very old ABI, and using...