Search results

I've never had to do anything but reboot ...works fine. Latest PVE as of this writing on 3 x Dell r510s in an HA cluster.

OK ... lesson learned ... --- the last post is correct ... but ... it missed that an update can overwrite the: /etc/systemd/system/timers.target.wants/pve-daily-update.timer file and remove any changes. More Googling and new strategy: 1) list the file that we would like to change: cat...

Systemd timers has a bit of a learning curve! To help the next person who finds this thread here's what I did. It took a lot of piecing things together from other threads and Google searches. My goal is to change pve-daily-update.timer from a daily schedule to a weekly schedule. That is from...

LOL ... you spelled it out "pve-daily-update.timer". I'll try that and report back.

Hi Wolfgang, Thank you for the reply. Once again I'm learning something new. I'm used to looking for cronjobs. Would you help me to find the correct Systemd Timers to change? systemctl list-timers shows this: NEXT LEFT LAST PASSED...

Hi All, I'd like to change the schedule that's in place for running "apt-get update" with the default install. Is this possible? (I don't see where / how it's scheduled now.) Any warnings? best, James

Hi Spdflyer, It sounds like you have a good grip on how all of this works. We run a 3 node Ceph / Proxmox cluster with everything on those three nodes ... Ceph storage Proxmox, etc. This works well for us now and minimized our startup costs. We're considering adding SSDs for Windows server...

Maybe a minimal Linux install that boots strait to an RDP client that's set to auto connect and go full screen ... there's got to be something ... here's a start: https://www.ubuntupit.com/10-fast-and-secure-remote-desktop-client-software-for-linux/ RDP will feel like she's running the VM on...

Thanks for the response Wolfgang. That first Wiki is interesting ... hope that we go after new hardware at that point. I'd much prefer to add the new node, role VMs to it and retire an old node.

Hi, I can't speak to all of your questions but I can to your future cluster. 3) Yes, there are plenty of options in the GUI. 4) We're running a three node cluster (3 x Dell r510s) with Ceph for the file system. Ceph is very nicely integrated into Proxmox right out of the box. There are...

Hi All, I'm looking for some input on best practices for updating / patching our three node cluster. As a bit of background, we've been running 5.2 for nearly a year in a three node cluster. This was rock solid stable. I would update it once a month from the free repositories with no issues...

Thanks Stoiko. The time on the nodes is definitely synchronized. After reading about the changes / fixes in 5.4 I decided to upgrade. The cluster hasn't rebooted since. Everything seems to point to something in 5.3 that didn't work well with my config. I'm guessing something in my hardware...

https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+7+1700X&id=2969 That's decent CPU power for what you are doing. The RAM isn't too bad either. That's about 6GB per VM. As long as you're only running a couple of light apps on each VM they shouldn't start swapping to disk. Be sure that you...

My actions started the events that led to the cold start. Here's the details to be sure that my calling it a cold start is correct. Cluster node 3 was running on an older kernel and needed to be rebooted to load the newer kernel as part of troubleshooting. Troubleshooting details here. I...

Hi All, Today when our three node cluster restarted cold. I received an email from ait3, one of the nodes. The node 'ait3' failed and needs manual intervention. The PVE HA manager tries to fence it and recover the configured HA resources to a healthy node if possible. Current fence status...

Definitely ... here are some logs from AIT3, the last node to reboot and the one that I have syslog entries for. The reboot happened just after Apr 5 05:19:30. The nodes address is 172.20.64.14. 172.20.64.253 is one of our monitoring servers. Apr 5 05:00:00 ait3 systemd[1]: Starting Proxmox...

I checked for '/var/log/journal' it's there on all three nodes. I'm not sure but I think that it's created when journaling is restarted. AIT3 is the only node with a reboot that is still visible in the syslogs ... the syslogs containing reboots for AIT1 and AIT2 have already been deleted...

Thanks Stoiko. What you just wrote confirms what a lot of Googling just taught me. I didn't expect you to write back so soon. Too bad I didn't refresh this post while Google-ing. LOL I didn't have persistent journaling enabled but do now. Here's what I've done: - edited...

Yes How is this best done? I'm not sure where to look for these. --- edit --- investigating journalctl now ...

Interesting. We're having similar issues where a cluster node slows to the point where the watchdog triggers a hard reboot. This all started after an upgrade to 5.3-12. I've moved the most heavily loaded node back to 5.3-11 and it's been stable for three days now. We're using Ceph though ...