Search results

Can't say for FreeIPA as I do not use it, but I'm joining my PVE servers to my AD (samba4) domain using sssd / adcli. It's working without issue.

Looks like you haven't reduced the swap LV, as there's still the same amount of free extents

So, swap is referenced by its path, so no need to touch it. Just reduce the swap partition as I posted, then retry the lvconvert --repair

It's your volume group which hasn't enough free space. You either add another disk and add it to the VG, or reduce the swap LV for example. swapoff -a lvreduce -L4G pve/swap mkswap /dev/pve/swap # Check in /etc/fstab if the swap is referenced by UUID or by path, update UUID if needed

Looks like a thin pool metadata corruption. Be sure you have backups. And try to repair with lvconvert --repair /dev/pve/data

No, vzdump doesn't dump the RAM of the guest. It uses the qemu agent to freeze / unfreeze FS inside the guest to ensure consistency instead. When you say 4-5 sec of interruption, do you mean network outage of the VM ?

You can try qemu-img check -r on a copy of the corrupted image.

check_pve_sudo needs some parameters. The script can be run manually with eg /var/lib/zabbix/bin/check_pve_sudo --cluster /var/lib/zabbix/bin/check_pve_sudo --node=pve1 /var/lib/zabbix/bin/check_pve_sudo --guest=110 /var/lib/zabbix/bin/check_pve_sudo --storage=local-zfs (you can add --pretty...

Well, you have to debug why zabbix server can't talk to the agent. Test the port is reachable (eg with telnet), check the agent respond etc.

This is really more a Zabbix issue than a PVE one. On the PVE node, you have to check you have allowed your server (or proxy, depending on your setup) in /etc/zabbix/zabbix_agentd.conf with the Server directive. You also need to have the port 10050 reachable

OK. So, the zabbix user account running Zabbix agent on your PVE must be able to run the scripts with sudo, without password. You should be able to just drop conf/sudo.conf in /etc/sudoers.d/zabbix_agent.conf and it should work. (just adapt the path if you use something else than...

You need a zabbix agent running on the pve node

No step by step doc written, but here are the main steps : Put disco_pve_sudo and check_pve_sudo on the PVE host you want to monitor. For example in /var/lib/zabbix/bin. Makes sure the scripts are executable. You might need to install some perl libs if they are not already installed...

You can hook this with some scripts and configuration. Here's what I'm doing, working with Zimbra as backend email server : In Zimbra, there's always specials spam and ham users, where emails are fowarded when a user mark a mail as spam or as ham In Zimbra, I create an IMAP account for PMG...

No, it doesn't work from the GUI even when logged in with the root@pam account Yes, starting like this does work

Exactly the same issue with ZFS over iSCSI storage. Probably a regression in a very recent 6.x update, haven't tracked it down yet

You can have a look at my scripts, made to monitor a whole cluster (just point zabbix at one node, which will monitor everything else) : https://git.fws.fr/fws/zabbix-agent-addons in zabbix_scripts, you'll find disco_pve_sudo and check_pve_sudo which will do the hardwork (it's calling pvesh to...

Try to define a new storage, then move the VM disks one by one to this new storage while they are still running

Also had this error, quite easy to reproduce if you set the same schedule for pruning and gc on a datastore (eg, "daily" for both)

I think the only way is to restore the vzdump archive on a PVE host, and then backup the restored VM on PBS