Search results

As far as I know, on windows this is a "domain policy" pushed by the Active Directory. The windows domain policies don't work on anything but windows. Technically you can change the policy (GPT editor) to change the NTP server to something other then the main AD. However in my experience this is...

Not sure if it is 'The' recommended way, but as I mentioned, we rely on a NTP source in our network so it is reachable for all machines. In your case if you do not have the means to set up a dedicated NTP source, using one of the PVE hosts, or your router/switch as a NTP source will work fine...

This is not an 'ntp' option, this is for the startup of the vm, windows likes to have the system date/time in the local time zone, while *nix OS likes to have the system date/time in UTC. This option translates the host time for the vms to the timezone or not depending on that option. Which...

Yes I am, and no I can not, we have link0 on the storage interfaces, and link1 on the front facing, and I dont have more interfaces available

No, thats to a PBS server

in our env we run chrony on all linux vpms using ptp_kvm and that works very well. For windows we currently just sync with the NTP server in our network, which is also used by the pve hosts. The reason for using ptp_kvm is that is has less overhead, although one could argue that ntp is such...

New information. had 2 reboots of hosts this weekend, same host both times, what is weird from the 2nd reboot, we have a very clear "OOM" problem. however our host at the moment has 3x the amount of memory provisioned all vm's combined are allowed to use. Our backup for this hosts starts at...

For my side, had another reboot this friday, 2 PVE hosts. We traced the issue to our ceph HDD pool which is being slow at that moment. Were moving some copy/sync which is going to the HDD pool to be more stretched out and not all hosts hitting it at once, but it still feels silly a node has to...

The current version of pve-ha-manager is 5.1.0 which does not contain any of these patches. Also there is no 'testing' version available yet, the patches seem a bit much to all do manual, do we have any timeline when a 5.1.1 would come in testing?

it seems, but it is absolutely not, our normal cpu load during the day is kept very low, same with memory. This 'overloaded' is caused purely by io delay on the mounted backup volume, which makes sense is slower during backup windows. This should however not cause a complete PVE node to reboot...

`Journalctl -b -1` (previous boot log) - Cleaned up and anonymized. from ~15 min before restart. Jan 24 01:49:28 pve25 vzdump[2026007]: <root@pam> starting task UPID:pve25:001EEA18:06F4E8D3:69741718:vzdump::root@pam: Jan 24 01:49:29 pve25 vzdump[2026008]: INFO: starting new backup job: vzdump...

Good to know this affects everyone equally :-) We have had discussion on this topic in the past on this forum, It would be nice to get a way to see the softdog status and get logging of when the watchers decide to NOT ping the watchdog for whatever reason. So far this whole thing is a big...

We have had this same issue since replacing our intel based nodes with amd ones. Lately we have unexpected reboots at least weekly on one or more nodes. For us this always happens during the backup window (lucky?) and we see high IO delay right before the PVE host decides to shit itself. Still...

That is unfortunate. But yes, you might want to make a 2nd bridge device, and a vm or container to act as a router between the 2 bridges.

You often do not have to, but I would consider it good practice to do anyway so you have a clear indication of what lan these vms are on.

Hi moshe, you have 2 options here, you enable vlan support on the first (default) bridge vmbr0. it you will put vm's on vlan 1, they will be able to communicate with router, vlan1 is the default vlan in most (all) netwerk equiptment. If you put any other vlan besides 1, they can only communicate...

This is a bit of a meh.. issue easy to work around, but would be nice to find out whats going on. Affects: at least PVE 8 & 9 - exact patch version does not matter. - File size in this case does not matter, happens with any size image. Uploading an iso to a server in the cluster that is not...

Crosspost reply here. I also noticed problems with 6.17.2-2 which are not an issue on 6.17.2-1: https://forum.proxmox.com/threads/super-slow-timeout-and-vm-stuck-while-backing-up-after-updated-to-pve-9-1-1-and-pbs-4-0-20.176444/post-822997 On top of that, in that treat it does not look like...

Yes, we have determined as a group the problem is on the PBS (kernel) side, affecting all versions of PVE. - Would also like to add 6.17.2-2 has problems on the PVE side, we have noticed vm disks halting randomly with 'watchers' being stuck on the ceph side. This happens with live migrations...

No ! while this technically might work it invalidates the cluster, you shouldnt have 2 votes on a single node... Might as well install qdevice on 1 of the hosts directly (is that even possible?) What exactly do you disagree with, @SInisterPisces can build a valid 2 node cluster, and there for...