Search results

We still have both of these these bugs a year later in pve-manager/6.3-6/2184247e. I guess we should open a bug report, if noone else has?

I guess you could open a bug report and force upgrade of drivers that way? Maybe we need to wait for Ubuntu to update in theirs and bumb should be made there. Anyway, open a bug report, i probably will do more than a forum post.

Your text really is confusing, so I will just tell you that, do NOT add new nodes to the same cluster, if they are not in the same data center. It is asking for trouble with network outages and latency. If you need to migrate VMs, just use ZFS with pve-zsync, etc. Regards, M.

Thank you for your answer. Will restarting pve-ha-lrm result in restarting of any virtual instances or host itself? So, after restart it should look like this: root@p35:~# ha-manager status quorum OK root@p35:~# ha-manager config root@p35:~# And not have any lrm or any other type resources...

Hi, thank you for your answer. Backing up of templates makes sense, because If the server where templates are goes down, I can restore them to another. Sometimes I use replication for that. Sometimes both. Sometimes nothing. :-)

Thank you for all your answers. So if HA was ever defined, even if the HA resources have since been deleted, there is a watchdog running which will reboot node with loss of quorum. Do I understand correct? If that is so, how can I check if such watch dog is running and how can I disable it...

@Fabian_E We have needed this ( https://bugzilla.proxmox.com/show_bug.cgi?id=3351 ) for years and we could finally stop using znapzend. @onlime you should consider using znapzend also. Allows us just that, to have different number of snapshots on different locations. Well to be frank, with...

If I want to backup a template from the template server to PBS, the backup fails, because the template has too many cpus defined. This makes sense only if you want to run the VM, not if you want to backup it. My template node obviously has less CPUs than compute nodes, but my templates are used...

Bump.

Hi, a coworker made a network loop for 60 seconds and it turned out that some PM cluster which uses WAN side for clustering rebooted itself - all nodes. It made me wonder, can network loop cause PM to reboot itself? Will it reboot, even if no HA resources are defined on cluster? Under what...

systemctl restart pvedaemon and pveproxy shuld suffice.

A little update. I added another node yesterday, logging tcpdump on bridges and physical cards, but it joined without a problem. Will log the same when adding another node, in case if the error pops up again. I will have and share the tcpdumps.

Hi guys, sorry for delay, but "life" happens. :) @Pierre-Yves i think this is still the way to go. I just create bridge after joining cluster. @dcsapak @spirit Now I'm not sure, if it still it has something to do with with bridge multicast traffic, but it certainly is bridge related. So I will...

@Stoiko Ivanov @dcsapak tags. :-)

Or use vlans with QoS.

I didn't read whole thread but I think I noticed the same bug a weak ago. Here is the report: https://forum.proxmox.com/threads/pm-6-multicast-related-bugs.83703/ Disable igmp snooping on a bride before adding the node, or do not use a bridge when adding. It's a PM bug.

https://forum.proxmox.com/threads/pm-6-multicast-related-bugs.83703/ here. I stopped debugging publicly, because no1 seemed to care. Above is the link with summary of my debugging. Also I wish @tom would contribue more that with just a comment to upgrade. This regression should also be caught...

HI, it took me some time, but I finally understood that is going on. Before I open bugs on bugzilla, I want to make sure I get things right. 1. BUG: Proxmox docs state, that PM 6 cluster does not require multicast. "Note: Proxmox VE 6.0 uses corosync 3 which switched out the underlying...

Adding the node again, fails again. Both nodes were updated prior to adding. Will now have coworker gather all logs and open a bug report.

I added another updated node to the cluster, just to see the same cluster lockup and failure. :-) I guess there is a bug somewhere. Have no time to debug. Will recover as previously. Kill new node, reinstall it, remove it add it again. Hopefully, this time it works. :-)