Search results

Thank you for this, I think we're good then. The update-fingerprints run went through OK on both hosts after clearing known hosts and running a connection firstly from each.

Either cloud-init or provisioning scripts not being fully disabled/deleted. Will poke around to figure out why it regenerated. Thanks for that. Will sort the extra root cause then focus back on getting this working well. :) Should it need cron-jobbing, or should the SSL/API fingerprints...

Hi there, Just checking if this is expected behaviour. I know there is --delete which lets you remove it on-successful-completion however it details that if not used, it should stop. So with the job finishing successfully as below, it seems odd that they are still locked with the paper plane...

Hmm, another qm remote-migrate question. We are getting the below response when trying to live-migrate, however the thin-pool and VG are both named as such on the gaining node. remote: storage 'raid10ssd' does not exist! Any idea why? We added a new storage pool, then created a Thin/Logical...

This is now possible via qm remote-migrate as of Proxmox VE 7.3: https://pve.proxmox.com/pve-docs/qm.1.html

Host key verification failed. So more than fingerprints need updating in order to retain connectivity? What needs updating? And will leveraging update-fingerprints on-cron then be sufficient to avoid comms breakage? Otherwise it tends to lose connection to other members every month or two...

How do you accomplish this? Just reading this and below, trying to figure out v6. https://forum.proxmox.com/threads/setting-ipv6-on-proxmox.51008/

We also see the error when trying to avoid the cluster losing sync with members. root@pmg-node1:~# pmgcm update-fingerprints 500 update fingerprints failed: unable to get remote node fingerprint from 'pmg-node2': command 'ssh -l root -o 'BatchMode=yes' -o 'HostKeyAlias=pmg-node2'...

Hi there, This is a bit of an edge case, though being so short on time it's taking me a while to understand the inner workings of IPv6. There's a reason they say "throw out your understanding of v4 as it has no bearing with v6", holy moly are they right! It's great but needs to be understood...

All of us lovers of darkness thank you endlessly for this - THANK YOU!! :D

We now have an active-backup bond, and a LACP bond. The former is fibre-first with LACP on fibre-fail; the latter is the LAG for 2x 1G RJ45. So the copper LAG bond is utilised as the backup component of the fibre bond and, as below, it doubles as the full-time PVE interface for cluster syncing...

Good news! This is getting closer now - noticed this in the PVE 7.3 release notes: You can run it (experimentally) via CLI already. Hallelujah! See the man page for qm >> remote-migrate: https://pve.proxmox.com/pve-docs/qm.1.html

Having done some research into this today, the L3+4 configuration isn't fully RFC-compliant as data can arrive out-of-order. By default, the HP switch configurations (where they can handle a hash policy at L4, but are not configured to) will use L3, with fallback to L2. So the...

No way, this is Proxmox we're talking about - @Dominic and the crew will have plenty of backups!

This makes plenty of sense. SpamExperts (back when they had decent owners) had an Outlook plug-in, and a mailbox you could forward to (which understood forwards, thus only interpreted the data that mattered). PMG is effective though it does feel like it's tricky to get up & off the ground. I...

Per the reply from Stoiko within the bug, interest needs to be shown towards the bug for it to be prioritised at all. If you comment on Bugzilla then it will help the case in terms of having it be catered for. Honestly though, I'd say 1-2 years given the low levels of interest.

Just want to mention that we had ECC RAM showing up in dmidecode all well and good, but not showing in Proxmox (nor free etc). Turned out to indeed be the memory. 2 of the 4 new sticks in the problem machine were duds even though they appeared OK. Replaced & all good.

This is now done on every node in this cluster, and we confirm all is happy again. :) Many thanks for your prompt help in ensuring this was patched!

Is the below what you're referring to with "VMs need rebooting to use the new QEMU binary"? root@node4:~# apt install ./pve-qemu-kvm_6.1.0-2_amd64.deb Reading package lists... Done Building dependency tree... Done Reading state information... Done Note, selecting 'pve-qemu-kvm' instead of...

Thank you kindly. Will wait for it to hit no-sub unless that'll take a while. As it's a cherry-picked patch only, nothing else seems to have changed in the package, would it be a quick transfer there?