Re: Failed to start Proxmox VE replication runner

2022-11-09 Per discussione Diego Zuccato

Il 09/11/2022 14:06, Piviul ha scritto:

anch'io ero arrivato a quella conclusione cioé che venivano 
ridirezionati verso l'ultimo mac address che aveva usato il bond (avevo 
detto ip ma in effetti non è giusto, il bond non sa nulla degli ip...) e 
se il bond contemporaneamente è utilizzato da più macchine con mac 
address differenti succedeva che alcuni pacchetti venivano ridirezionati 
al mac address sbagliato e quindi ignorati e mano a mano che il traffico 
aumentava i pacchetti persi aumentavano a dismisura... ma in effetti non 
dovrebbe succedere nulla se il bond viene usato da una macchina sola... 
mi sa che ci riproverò.
Mi sa che ci fosse qualche problema di altro genere. A meno che tu non 
avessi VM che condividevano l'IP e che fossero in esecuzione su due 
Proxmox diversi.
Se hai un solo Proxmox, anche con tante VM, i MAC address "saltellano" 
un po' tra le due interfacce ma al limite lo switch a monte inoltra i 
pacchetti ad entrambe (sprechi metà della banda in ricezione e la VM 
riceve pacchetti duplicati).
Se hai più Proxmox, ma con VM che lavorano su IP diversi, semplicemente 
si affiancano situazioni del singolo Proxmox, e ancora non dovresti 
perdere nulla.
Se invece hai p.e. 2 OPNSense in VM e usi un singolo VIP, se metti le 
due VM su due Proxmox gli switch si vedono arrivare un MAC address da 4 
interfacce diverse e potrebbero non gradire...


la banda è sempre un problema ;) e in assenza di standard legarsi ad una 
tipologa di switch che immagino siano anche molto costosi... anche no, 
grazie!
Non posso che condividere. Ma magari puoi valutare soluzioni di bonding 
diverse, con diverse opzioni per l'hashing.


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: Failed to start Proxmox VE replication runner

2022-11-09 Per discussione Piviul

On 09/11/22 11:41, Diego Zuccato wrote:

Il 09/11/2022 08:29, Piviul ha scritto:

io perdevo proprio dei pacchetti perché venivano ridirezionati 
all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi 
sembra di ricordare proprio così...
Uh? Gli switch dovrebbero al limite ridirezionarli all'ultimo MAC che 
ha usato il bond, e questo non provoca la perdita di pacchetti (a meno 
di guasti): il bond, in ricezione, dovrebbe essere interface-agnostic.


anch'io ero arrivato a quella conclusione cioé che venivano 
ridirezionati verso l'ultimo mac address che aveva usato il bond (avevo 
detto ip ma in effetti non è giusto, il bond non sa nulla degli ip...) e 
se il bond contemporaneamente è utilizzato da più macchine con mac 
address differenti succedeva che alcuni pacchetti venivano ridirezionati 
al mac address sbagliato e quindi ignorati e mano a mano che il traffico 
aumentava i pacchetti persi aumentavano a dismisura... ma in effetti non 
dovrebbe succedere nulla se il bond viene usato da una macchina sola... 
mi sa che ci riproverò.





Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma 
pochi switch permettono di gestire uno "switch virtuale" con bond 
LACP e connessioni a due switch fisici differenti.
questo è molto interessante... Quindi gli switch quale standard 
dovrebbero seguire per poter gestire uno "switch virtuale" per fare 
una bond LACP con switch differenti?
Non mi risulta esistere uno standard. Mi pare che lo facessero alcuni 
HP di fascia alta, configurando uno "switch virtuale" che utilizza più 
switch fisici: a quel punto basta definire un trunk LACP inserendogli 
porte di due switch fisici diversi. Altrimenti, se la banda non è un 
problema, basta un semplice failover.


la banda è sempre un problema ;) e in assenza di standard legarsi ad una 
tipologa di switch che immagino siano anche molto costosi... anche no, 
grazie!


Grazie ancora

Piviul




Re: Failed to start Proxmox VE replication runner

2022-11-09 Per discussione Diego Zuccato

Il 09/11/2022 08:29, Piviul ha scritto:

io perdevo proprio dei pacchetti perché venivano ridirezionati 
all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi 
sembra di ricordare proprio così...
Uh? Gli switch dovrebbero al limite ridirezionarli all'ultimo MAC che ha 
usato il bond, e questo non provoca la perdita di pacchetti (a meno di 
guasti): il bond, in ricezione, dovrebbe essere interface-agnostic.


Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma 
pochi switch permettono di gestire uno "switch virtuale" con bond LACP 
e connessioni a due switch fisici differenti.
questo è molto interessante... Quindi gli switch quale standard 
dovrebbero seguire per poter gestire uno "switch virtuale" per fare una 
bond LACP con switch differenti?
Non mi risulta esistere uno standard. Mi pare che lo facessero alcuni HP 
di fascia alta, configurando uno "switch virtuale" che utilizza più 
switch fisici: a quel punto basta definire un trunk LACP inserendogli 
porte di due switch fisici diversi. Altrimenti, se la banda non è un 
problema, basta un semplice failover.


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: Failed to start Proxmox VE replication runner

2022-11-09 Per discussione Piviul

On 09/11/22 08:21, Diego Zuccato wrote:

[...]
Te lo chiedo perché avevo fatto un po' di prove anche con bond alb ma 
perdevo dei pacchetti. Mi sembra di ricordare però che la causa 
l'avevo imputata al fatto che avendo messo in bond alb le interfacce 
dedicate alla lan e siccome più vm le usavano con ip diversi nel caso 
di traffico contemporaneo di più vm hosts il routing dei pacchetti si 
incasinava... avevo archiviato quindi il bond alb ma in questo caso 
tutto il traffico è generato da un solo IP, dovrebbe funzionare... è 
plausibile no?
L'unico "problema" che ho rilevato è stato il flapping segnalato da 
ArpWatch e OpnSense perché vedono gli IP saltellare da un MAC all'altro.


io perdevo proprio dei pacchetti perché venivano ridirezionati 
all'ultimo ip che aveva usato il bond. È passato qualche anno ma mi 
sembra di ricordare proprio così...



Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma 
pochi switch permettono di gestire uno "switch virtuale" con bond LACP 
e connessioni a due switch fisici differenti.


questo è molto interessante... Quindi gli switch quale standard 
dovrebbero seguire per poter gestire uno "switch virtuale" per fare una 
bond LACP con switch differenti?


mille grazie

Piviul



Re: Failed to start Proxmox VE replication runner

2022-11-08 Per discussione Diego Zuccato

Il 08/11/2022 16:37, Piviul ha scritto:

mi sembrano considerazioni condivisibili... anche se poi uno deve fare 
anche i conti con le voci di spesa e avere un nodo in più o in meno non 
è proprio indifferente...
Proprio considerazioni di budget (in particolare relative ai consumi) 
dovrebbero portarci a sostituire i 9 "ruschi" attuali (3 per sala) con 3 
nuovi nodi.


...interessante; quindi si crea un bond ALB con 2 interfacce e poi si 
collegano a 2 switch diversi e dovrebbe funzionare? Ma gli switch devono 
avere qualche caratteristica particolare?

No. Tendenzialmente, più sono stupidi meglio è :)

Te lo chiedo perché avevo 
fatto un po' di prove anche con bond alb ma perdevo dei pacchetti. Mi 
sembra di ricordare però che la causa l'avevo imputata al fatto che 
avendo messo in bond alb le interfacce dedicate alla lan e siccome più 
vm le usavano con ip diversi nel caso di traffico contemporaneo di più 
vm hosts il routing dei pacchetti si incasinava... avevo archiviato 
quindi il bond alb ma in questo caso tutto il traffico è generato da un 
solo IP, dovrebbe funzionare... è plausibile no?
L'unico "problema" che ho rilevato è stato il flapping segnalato da 
ArpWatch e OpnSense perché vedono gli IP saltellare da un MAC all'altro.
Una soluzione ancora migliore sarebbe l'aggregazione con LACP, ma pochi 
switch permettono di gestire uno "switch virtuale" con bond LACP e 
connessioni a due switch fisici differenti.


Poi se posso ne approfitterei per chiederti se sei a conoscenza di un 
qualche tool per il monitoraggio del traffico nel bond alb e magari che 
sia in grado di inviare una notifica se una delle 2 interfacce non viene 
usata o ha problemi... Te lo chiedo perché se uno switch si incasina, 
come è successo a me, non te ne accorgi finché non muore anche l'altro...
Non uso nulla: ogni tanto do' un'occhiata al management degli switch e 
finora non ho avuto problemi tali da giustificare lo sforzo di 
integrarli nel monitoraggio. Ma credo convenga, nel caso, usare Nagios o 
simili.


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: Failed to start Proxmox VE replication runner

2022-11-08 Per discussione Piviul

On 08/11/22 06:33, Diego Zuccato wrote:

Ciao.

IMO i nodi devono essere (o "è meglio che siano") in numero dispari, 
per evitare possibili split-brain (con 2) e non perdere funzionalità 
inutilmente.


Con 3 nodi, puoi averne uno guasto senza problemi: gli altri 
mantengono il quorum (2) e possono lavorare normalmente.
Con 4 nodi il quorum passa a 3, ma se perdi 2 nodi non puoi fare nulla 
(senza ridurlo). Con 5 nodi il quorum rimane 3 e puoi perdere 2 nodi 
continuando a lavorare sui rimanenti.


mi sembrano considerazioni condivisibili... anche se poi uno deve fare 
anche i conti con le voci di spesa e avere un nodo in più o in meno non 
è proprio indifferente...



La rete del cluster puoi ridondarla senza particolari problemi. Io 
normalmente faccio girare tutto il traffico su un bond ALB di almeno 2 
interfacce. Il vantaggio è che le due interfacce possono essere 
collegate a switch diversi e anche a switch unmanaged.


...interessante; quindi si crea un bond ALB con 2 interfacce e poi si 
collegano a 2 switch diversi e dovrebbe funzionare? Ma gli switch devono 
avere qualche caratteristica particolare? Te lo chiedo perché avevo 
fatto un po' di prove anche con bond alb ma perdevo dei pacchetti. Mi 
sembra di ricordare però che la causa l'avevo imputata al fatto che 
avendo messo in bond alb le interfacce dedicate alla lan e siccome più 
vm le usavano con ip diversi nel caso di traffico contemporaneo di più 
vm hosts il routing dei pacchetti si incasinava... avevo archiviato 
quindi il bond alb ma in questo caso tutto il traffico è generato da un 
solo IP, dovrebbe funzionare... è plausibile no?


Poi se posso ne approfitterei per chiederti se sei a conoscenza di un 
qualche tool per il monitoraggio del traffico nel bond alb e magari che 
sia in grado di inviare una notifica se una delle 2 interfacce non viene 
usata o ha problemi... Te lo chiedo perché se uno switch si incasina, 
come è successo a me, non te ne accorgi finché non muore anche l'altro...


Grazie ancora

Piviul



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Diego Zuccato

Ciao.

IMO i nodi devono essere (o "è meglio che siano") in numero dispari, per 
evitare possibili split-brain (con 2) e non perdere funzionalità 
inutilmente.


Con 3 nodi, puoi averne uno guasto senza problemi: gli altri mantengono 
il quorum (2) e possono lavorare normalmente.
Con 4 nodi il quorum passa a 3, ma se perdi 2 nodi non puoi fare nulla 
(senza ridurlo). Con 5 nodi il quorum rimane 3 e puoi perdere 2 nodi 
continuando a lavorare sui rimanenti.


La rete del cluster puoi ridondarla senza particolari problemi. Io 
normalmente faccio girare tutto il traffico su un bond ALB di almeno 2 
interfacce. Il vantaggio è che le due interfacce possono essere 
collegate a switch diversi e anche a switch unmanaged.


Diego

Il 07/11/2022 16:29, Piviul ha scritto:

On 07/11/22 15:44, Daniele Piccoli wrote:

Ciao,
[...]
Non è un buon segno onestamente, se posso darti 3 consigli:

 - Magari non lo fai, ma evita di far girare traffico "pesante" sugli 
switch in cui comunica il cluster, tipo il traffico verso gli storage. 
Idealmente dovrebbe girarci solo il traffico del cluster


 - Considera la possibilità di ridondare la rete di cluster: 
https://pve.proxmox.com/wiki/Separate_Cluster_Network


ho già configurato proxmox in questo modo: ho uno switch e una rete per 
tutto il traffico PVE separato dal traffico LAN e dal traffico CEPH che 
ha un altro switch da 10Gb dedicato.



  - Aggiungi un 4° nodo al cluster, cosi da non perdere il quorum nel 
caso un nodo avesse un problema, ma anche banalmente per fare 
manutenzione/aggiornamenti senza fretta


Probabilmente i primi mesi del prossimo anno riuscirò ad aggiungere 
anche il 4° nodo anche se in questo caso non sarebbe cambiato nulla 
perché appunto è stato lo switch ad andare in zampanella quindi anche 
con un nodo in più avrebbe continuato a non dialogare essendo la rete di 
comunicazione dei PVE non funzionante.


Invece mi chiedevo: non sarebbe meglio ridondare gli switch? Si può 
fare? Non penso tanto a quello usato dalla rete di comunicazione del 
cluster proxmox che a quanto pare se smette di funzionare, certamente il 
cluster non funziona ma tutti i guests hosts e il traffico LAN continua 
a funzionare; penso soprattutto allo switch della rete ceph che se muore 
mi muoiono contemporaneamente tutti gli hosts virtuali...


Grazie Daniele!

Piviul



--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Piviul

On 07/11/22 15:44, Daniele Piccoli wrote:

Ciao,
[...]
Non è un buon segno onestamente, se posso darti 3 consigli:

 - Magari non lo fai, ma evita di far girare traffico "pesante" sugli 
switch in cui comunica il cluster, tipo il traffico verso gli storage. 
Idealmente dovrebbe girarci solo il traffico del cluster


 - Considera la possibilità di ridondare la rete di cluster: 
https://pve.proxmox.com/wiki/Separate_Cluster_Network


ho già configurato proxmox in questo modo: ho uno switch e una rete per 
tutto il traffico PVE separato dal traffico LAN e dal traffico CEPH che 
ha un altro switch da 10Gb dedicato.



  - Aggiungi un 4° nodo al cluster, cosi da non perdere il quorum nel 
caso un nodo avesse un problema, ma anche banalmente per fare 
manutenzione/aggiornamenti senza fretta


Probabilmente i primi mesi del prossimo anno riuscirò ad aggiungere 
anche il 4° nodo anche se in questo caso non sarebbe cambiato nulla 
perché appunto è stato lo switch ad andare in zampanella quindi anche 
con un nodo in più avrebbe continuato a non dialogare essendo la rete di 
comunicazione dei PVE non funzionante.


Invece mi chiedevo: non sarebbe meglio ridondare gli switch? Si può 
fare? Non penso tanto a quello usato dalla rete di comunicazione del 
cluster proxmox che a quanto pare se smette di funzionare, certamente il 
cluster non funziona ma tutti i guests hosts e il traffico LAN continua 
a funzionare; penso soprattutto allo switch della rete ceph che se muore 
mi muoiono contemporaneamente tutti gli hosts virtuali...


Grazie Daniele!

Piviul



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Daniele Piccoli

Ciao,

Il 07/11/22 11:56, Piviul ha scritto:

On 07/11/22 10:49, Diego Zuccato wrote:

Il 07/11/2022 08:23, Piviul ha scritto:

Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:

Lo hai riavviato ma *ha* problemi.
Infatti un nodo non viene visto.


più che altro vedeva solo se stesso


Nov  4 23:38:26 pve02 corosync[1703]: [KNET  ] link: host: 3 link: 0 
is down

Questa è un'ottima ragione.
Per caso hai cambiato una scheda di rete o modificato la 
configurazione? O anche solo fatto un aggiornamento del kernel?


no, era lo switch che si era incasinato, spegnendolo e riaccendendolo è 
tutto tornato a posto.


Non è un buon segno onestamente, se posso darti 3 consigli:

 - Magari non lo fai, ma evita di far girare traffico "pesante" sugli 
switch in cui comunica il cluster, tipo il traffico verso gli storage. 
Idealmente dovrebbe girarci solo il traffico del cluster


 - Considera la possibilità di ridondare la rete di cluster: 
https://pve.proxmox.com/wiki/Separate_Cluster_Network


 - Aggiungi un 4° nodo al cluster, cosi da non perdere il quorum nel 
caso un nodo avesse un problema, ma anche banalmente per fare 
manutenzione/aggiornamenti senza fretta


[cut]



Piviul



Ciao
Daniele



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Piviul

On 07/11/22 10:49, Diego Zuccato wrote:

Il 07/11/2022 08:23, Piviul ha scritto:

Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:

Lo hai riavviato ma *ha* problemi.
Infatti un nodo non viene visto.


più che altro vedeva solo se stesso


Nov  4 23:38:26 pve02 corosync[1703]: [KNET  ] link: host: 3 link: 0 
is down

Questa è un'ottima ragione.
Per caso hai cambiato una scheda di rete o modificato la 
configurazione? O anche solo fatto un aggiornamento del kernel?


no, era lo switch che si era incasinato, spegnendolo e riaccendendolo è 
tutto tornato a posto.



Cercando in rete ho visto che non sono il solo ad avere questo 
problema e tutti indirizzano ad impostare il quorum a uno con pvecm 
expected 1 ma sono un po' preoccupato prima di fare qualunque cosa 
vorrei esserne ipercerto non avendo nemmeno il backup delle macchine 
virtuali!
Portare a 1 il quorum in un cluster è lo step appena prima del 
riformattare e reinstallare...
Intendiamoci, puoi farlo *sul solo nodo problematico* e solo per il 
tempo minimo necessario a fare un backup delle VM (spente, su supporto 
esterno). Poi IMO ti conviene reinstallare da capo il nodo (con 
delnode da uno degli altri, poi ricordati di rimuovere le chiavi ssh 
in /etc/ssh/ssh_known_hosts).


avevo immaginato... più che riformattare pensavo poi di dover rimouvere 
ogni songolo nodo dal cluster per poi riaggiungerlo


Mille grazie, tutto è bene ciò che finisce bene

Piviul




Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Piviul

On 07/11/22 10:57, Marco Ciampa wrote:

On Mon, Nov 07, 2022 at 08:51:32AM +0100, Piviul wrote:

Scusate, essendo un problema piuttosto grave e urgente mi sono permesso di
scrivere anche alla mailing list pve-u...@lists.proxmox.com; so che il cross
posting non è una buona pratica ma nel caso di sviluppi sull'altro thread
cercherò di tenere aggiornato anche questo.

Controlla che un backup non si sia bloccato per occupazione dello spazio
sullo storage che spesso porta alla corruzione della macchina virtuale
che rimane lock-ata.


Si, infatti il tutto si è bloccato durante il backup per cui in effetti 
una macchina era lockata e l'ho un-lockata.


Ciao e grazie!

Piviul




Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Piviul
Mi sono accorto che la rete di comunicazione dei PVE non funzionava più, 
ho risolto spegnendo e riaccendendo lo switch di comunicazione


Grazie a tutti quanti, problema rientrato

Piviul

On 07/11/22 08:51, Piviul wrote:
Scusate, essendo un problema piuttosto grave e urgente mi sono 
permesso di scrivere anche alla mailing list 
pve-u...@lists.proxmox.com; so che il cross posting non è una buona 
pratica ma nel caso di sviluppi sull'altro thread cercherò di tenere 
aggiornato anche questo.


Piviul

On 07/11/22 08:23, Piviul wrote:

Ciao Marco, anzitutto grazie!

On 05/11/22 22:00, Marco Gaiarin wrote:

[...]
Se non hai quorum (stile: hai tre nodi, quorum a 2 (il default) e un 
nodo

fermo) è normale che le macchine non partano.


dunque, forse non sono stato chiaro... i 3 nodi vanno tutti e 3. Mi 
posso connettere ad ognuno dei 3 nodi anche tramite interfaccia web 
ma da un nodo non si vedono gli altri 2. È il cluster che ha dei 
problemi. Il servizio che non riesce a partire è il "Proxmox VE 
replication runner" (pvesr), fra le altre cose non ho alcuna replica 
impostata a memoria, utilizzo solo ceph e mi sono liberato di zfs. 
Tutte gli host virtuali funzionano bene non hanno problemi tranne che 
non funziona più il backup e non funzionando il cluster non posso 
nemmeno migrarli di nodo; inoltre se spengo una macchina poi non 
riesco più a riaccenderla.



'pvesr' è il servizio di replicazione degli storage ZFS; se non hai 
ZFS o
non usi la replicazione, quel'errore è ininfluente (e comunque nulla 
centra

con il quorum).

A naso hai corosync fermo su un nodo, e magai ti basta riavviare 
quello (o

riavviare corosync su quello); prova a lanciare:

pvecm status

su tutti i nodi e vedi che ti dice.


Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:


# pvecm status
Cluster information
---
Name: CSA-cluster1
Config Version:   3
Transport:    knet
Secure auth:  on

Quorum information
--
Date: Mon Nov  7 08:11:51 2022
Quorum provider:  corosync_votequorum
Nodes:    1
Node ID:  0x0001
Ring ID:  1.91e
Quorate:  No

Votequorum information
--
Expected votes:   3
Highest expected: 3
Total votes:  1
Quorum:   2 Activity blocked
Flags:

Membership information
--
    Nodeid  Votes Name
0x0001  1 192.168.255.1 (local)

In syslog è pieno di  messaggi tipo:

Nov  7 08:14:33 pve01 pveproxy[2699797]: Cluster not quorate - 
extending auth key lifetime!
Nov  7 08:14:35 pve01 pveproxy[2699797]: Cluster not quorate - 
extending auth key lifetime!


Inoltre Tutto è iniziato venerdì sera e in syslog ho trovato:

4 23:37:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:37:01 pve02 CRON[2145590]: (root) CMD (if test -x 
/usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi)
Nov  4 23:38:00 pve02 systemd[1]: Starting Proxmox VE replication 
runner...

Nov  4 23:38:01 pve02 systemd[1]: pvesr.service: Succeeded.
Nov  4 23:38:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] link: host: 3 link: 
0 is down
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 
(passive) best link: 0 (pri: 1)
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 has no 
active links
Nov  4 23:38:28 pve02 corosync[1703]:   [TOTEM ] Token has not been 
received in 2737 ms
Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] rx: host: 3 link: 0 
is up
Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] host: host: 3 
(passive) best link: 0 (pri: 1)

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync left[1]: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] A new membership 
(1.873) was formed. Members left: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] Failed to receive 
the leave message. failed: 3
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: members: 1/1626, 
2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: starting data 
syncronisation
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: members: 1/1626, 
2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: starting data 
syncronisation

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [MAIN  ] Completed service 
synchronization, ready to provide service.
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received sync 
request (epoch 1/1626/0009)
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: received sync 
request (epoch 1/1626/0009)

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received all states
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: leader is 1/1626
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: synced members: 
1/1626, 2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: 

Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Marco Ciampa
On Mon, Nov 07, 2022 at 08:51:32AM +0100, Piviul wrote:
> Scusate, essendo un problema piuttosto grave e urgente mi sono permesso di
> scrivere anche alla mailing list pve-u...@lists.proxmox.com; so che il cross
> posting non è una buona pratica ma nel caso di sviluppi sull'altro thread
> cercherò di tenere aggiornato anche questo.

Controlla che un backup non si sia bloccato per occupazione dello spazio
sullo storage che spesso porta alla corruzione della macchina virtuale
che rimane lock-ata.

Il lock lo vedi con:

qm list

e lo togli con:

qm unlock VMID

dove VMID è l'ID della macchina virtuale ottenuto tramite qm list.

--

Amike,
Marco Ciampa



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Diego Zuccato

Il 07/11/2022 08:23, Piviul ha scritto:

Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:

Lo hai riavviato ma *ha* problemi.
Infatti un nodo non viene visto.

Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] link: host: 3 link: 0 
is down

Questa è un'ottima ragione.
Per caso hai cambiato una scheda di rete o modificato la configurazione? 
O anche solo fatto un aggiornamento del kernel?


Cercando in rete ho visto che non sono il solo ad avere questo problema 
e tutti indirizzano ad impostare il quorum a uno con pvecm expected 1 ma 
sono un po' preoccupato prima di fare qualunque cosa vorrei esserne 
ipercerto non avendo nemmeno il backup delle macchine virtuali!
Portare a 1 il quorum in un cluster è lo step appena prima del 
riformattare e reinstallare...
Intendiamoci, puoi farlo *sul solo nodo problematico* e solo per il 
tempo minimo necessario a fare un backup delle VM (spente, su supporto 
esterno). Poi IMO ti conviene reinstallare da capo il nodo (con delnode 
da uno degli altri, poi ricordati di rimuovere le chiavi ssh in 
/etc/ssh/ssh_known_hosts).


--
Diego Zuccato
DIFA - Dip. di Fisica e Astronomia
Servizi Informatici
Alma Mater Studiorum - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786



Re: Failed to start Proxmox VE replication runner

2022-11-07 Per discussione Piviul
Scusate, essendo un problema piuttosto grave e urgente mi sono permesso 
di scrivere anche alla mailing list pve-u...@lists.proxmox.com; so che 
il cross posting non è una buona pratica ma nel caso di sviluppi 
sull'altro thread cercherò di tenere aggiornato anche questo.


Piviul

On 07/11/22 08:23, Piviul wrote:

Ciao Marco, anzitutto grazie!

On 05/11/22 22:00, Marco Gaiarin wrote:

[...]
Se non hai quorum (stile: hai tre nodi, quorum a 2 (il default) e un 
nodo

fermo) è normale che le macchine non partano.


dunque, forse non sono stato chiaro... i 3 nodi vanno tutti e 3. Mi 
posso connettere ad ognuno dei 3 nodi anche tramite interfaccia web ma 
da un nodo non si vedono gli altri 2. È il cluster che ha dei 
problemi. Il servizio che non riesce a partire è il "Proxmox VE 
replication runner" (pvesr), fra le altre cose non ho alcuna replica 
impostata a memoria, utilizzo solo ceph e mi sono liberato di zfs. 
Tutte gli host virtuali funzionano bene non hanno problemi tranne che 
non funziona più il backup e non funzionando il cluster non posso 
nemmeno migrarli di nodo; inoltre se spengo una macchina poi non 
riesco più a riaccenderla.



'pvesr' è il servizio di replicazione degli storage ZFS; se non hai 
ZFS o
non usi la replicazione, quel'errore è ininfluente (e comunque nulla 
centra

con il quorum).

A naso hai corosync fermo su un nodo, e magai ti basta riavviare 
quello (o

riavviare corosync su quello); prova a lanciare:

pvecm status

su tutti i nodi e vedi che ti dice.


Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:


# pvecm status
Cluster information
---
Name: CSA-cluster1
Config Version:   3
Transport:    knet
Secure auth:  on

Quorum information
--
Date: Mon Nov  7 08:11:51 2022
Quorum provider:  corosync_votequorum
Nodes:    1
Node ID:  0x0001
Ring ID:  1.91e
Quorate:  No

Votequorum information
--
Expected votes:   3
Highest expected: 3
Total votes:  1
Quorum:   2 Activity blocked
Flags:

Membership information
--
    Nodeid  Votes Name
0x0001  1 192.168.255.1 (local)

In syslog è pieno di  messaggi tipo:

Nov  7 08:14:33 pve01 pveproxy[2699797]: Cluster not quorate - 
extending auth key lifetime!
Nov  7 08:14:35 pve01 pveproxy[2699797]: Cluster not quorate - 
extending auth key lifetime!


Inoltre Tutto è iniziato venerdì sera e in syslog ho trovato:

4 23:37:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:37:01 pve02 CRON[2145590]: (root) CMD (if test -x 
/usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi)
Nov  4 23:38:00 pve02 systemd[1]: Starting Proxmox VE replication 
runner...

Nov  4 23:38:01 pve02 systemd[1]: pvesr.service: Succeeded.
Nov  4 23:38:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] link: host: 3 link: 0 
is down
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 
(passive) best link: 0 (pri: 1)
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 has no 
active links
Nov  4 23:38:28 pve02 corosync[1703]:   [TOTEM ] Token has not been 
received in 2737 ms
Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] rx: host: 3 link: 0 
is up
Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] host: host: 3 
(passive) best link: 0 (pri: 1)

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync left[1]: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] A new membership 
(1.873) was formed. Members left: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] Failed to receive the 
leave message. failed: 3
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: members: 1/1626, 
2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: starting data 
syncronisation
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: members: 1/1626, 
2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: starting data 
syncronisation

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [MAIN  ] Completed service 
synchronization, ready to provide service.
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received sync 
request (epoch 1/1626/0009)
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: received sync 
request (epoch 1/1626/0009)

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received all states
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: leader is 1/1626
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: synced members: 
1/1626, 2/1578

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: all data is up to date
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: dfsm_deliver_queue: 
queue length 2

Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: received all states
Nov  4 23:38:32 pve02 

Re: Failed to start Proxmox VE replication runner

2022-11-06 Per discussione Piviul

Ciao Marco, anzitutto grazie!

On 05/11/22 22:00, Marco Gaiarin wrote:

[...]
Se non hai quorum (stile: hai tre nodi, quorum a 2 (il default) e un nodo
fermo) è normale che le macchine non partano.


dunque, forse non sono stato chiaro... i 3 nodi vanno tutti e 3. Mi 
posso connettere ad ognuno dei 3 nodi anche tramite interfaccia web ma 
da un nodo non si vedono gli altri 2. È il cluster che ha dei problemi. 
Il servizio che non riesce a partire è il "Proxmox VE replication 
runner" (pvesr), fra le altre cose non ho alcuna replica impostata a 
memoria, utilizzo solo ceph e mi sono liberato di zfs. Tutte gli host 
virtuali funzionano bene non hanno problemi tranne che non funziona più 
il backup e non funzionando il cluster non posso nemmeno migrarli di 
nodo; inoltre se spengo una macchina poi non riesco più a riaccenderla.




'pvesr' è il servizio di replicazione degli storage ZFS; se non hai ZFS o
non usi la replicazione, quel'errore è ininfluente (e comunque nulla centra
con il quorum).

A naso hai corosync fermo su un nodo, e magai ti basta riavviare quello (o
riavviare corosync su quello); prova a lanciare:

pvecm status

su tutti i nodi e vedi che ti dice.


Corosync non ha problemi, l'ho riavviato su tutti e 3 i nodi e non ha 
dato problemi. Questo è l'output di pvecm status:


# pvecm status
Cluster information
---
Name: CSA-cluster1
Config Version:   3
Transport:    knet
Secure auth:  on

Quorum information
--
Date: Mon Nov  7 08:11:51 2022
Quorum provider:  corosync_votequorum
Nodes:    1
Node ID:  0x0001
Ring ID:  1.91e
Quorate:  No

Votequorum information
--
Expected votes:   3
Highest expected: 3
Total votes:  1
Quorum:   2 Activity blocked
Flags:

Membership information
--
    Nodeid  Votes Name
0x0001  1 192.168.255.1 (local)

In syslog è pieno di  messaggi tipo:

Nov  7 08:14:33 pve01 pveproxy[2699797]: Cluster not quorate - extending 
auth key lifetime!
Nov  7 08:14:35 pve01 pveproxy[2699797]: Cluster not quorate - extending 
auth key lifetime!


Inoltre Tutto è iniziato venerdì sera e in syslog ho trovato:

4 23:37:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:37:01 pve02 CRON[2145590]: (root) CMD (if test -x 
/usr/sbin/apticron; then /usr/sbin/apticron --cron; else true; fi)

Nov  4 23:38:00 pve02 systemd[1]: Starting Proxmox VE replication runner...
Nov  4 23:38:01 pve02 systemd[1]: pvesr.service: Succeeded.
Nov  4 23:38:01 pve02 systemd[1]: Started Proxmox VE replication runner.
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] link: host: 3 link: 0 
is down
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 (passive) 
best link: 0 (pri: 1)
Nov  4 23:38:26 pve02 corosync[1703]:   [KNET  ] host: host: 3 has no 
active links
Nov  4 23:38:28 pve02 corosync[1703]:   [TOTEM ] Token has not been 
received in 2737 ms

Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] rx: host: 3 link: 0 is up
Nov  4 23:38:30 pve02 corosync[1703]:   [KNET  ] host: host: 3 (passive) 
best link: 0 (pri: 1)

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Sync left[1]: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] A new membership 
(1.873) was formed. Members left: 3
Nov  4 23:38:32 pve02 corosync[1703]:   [TOTEM ] Failed to receive the 
leave message. failed: 3

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: members: 1/1626, 2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: starting data 
syncronisation

Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: members: 1/1626, 2/1578
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: starting data 
syncronisation

Nov  4 23:38:32 pve02 corosync[1703]:   [QUORUM] Members[2]: 1 2
Nov  4 23:38:32 pve02 corosync[1703]:   [MAIN  ] Completed service 
synchronization, ready to provide service.
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received sync request 
(epoch 1/1626/0009)
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: received sync 
request (epoch 1/1626/0009)

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: received all states
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: leader is 1/1626
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: synced members: 
1/1626, 2/1578

Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: all data is up to date
Nov  4 23:38:32 pve02 pmxcfs[1578]: [dcdb] notice: dfsm_deliver_queue: 
queue length 2

Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: received all states
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: all data is up to date
Nov  4 23:38:32 pve02 pmxcfs[1578]: [status] notice: dfsm_deliver_queue: 
queue length 46
Nov  4 23:38:34 pve02 corosync[1703]:   [KNET  ] link: host: 3 link: 0 
is down
Nov  4 23:38:34 pve02 corosync[1703]:   [KNET  ] host: host: 3 (passive) 
best link: 0 (pri: 1)

Re: Failed to start Proxmox VE replication runner

2022-11-05 Per discussione Marco Gaiarin
Mandi! Piviul
  In chel di` si favelave...

> Ciao a tutti, da ieri verso le 23:38 il mio cluster proxmox non funziona 
> più e nei logs trovo periodicamente qualcosa tipo:
[...]
> le macchine vurtuali vanno tutte ma non possono essere spente altrimenti 
> proxmox quando si cerca di fare lo start di una macchina spenta si 
> lamenta con il messaggio "cluster not ready - no quorum? (500)"
> Ora non ho il coraggio di riavviare i nodi, temo che poi le macchine non 
> partano più. A qualcuno è mai capitato? Qualcuno mi sa dare qualche dritta?

Una cosa alla volta.

Se non hai quorum (stile: hai tre nodi, quorum a 2 (il default) e un nodo
fermo) è normale che le macchine non partano.

'pvesr' è il servizio di replicazione degli storage ZFS; se non hai ZFS o
non usi la replicazione, quel'errore è ininfluente (e comunque nulla centra
con il quorum).

A naso hai corosync fermo su un nodo, e magai ti basta riavviare quello (o
riavviare corosync su quello); prova a lanciare:

pvecm status

su tutti i nodi e vedi che ti dice.

-- 
  Se Darl McBride [il presidente di SCO] ne fosse incaricato,
  probabilmente renderebbe anticostituzionale anche il matrimonio, poiché
  chiaramente attenua la normale natura commerciale dell'interazione umana
  ed è probabilmente un ostacolo importante alla crescita commerciale
  della prostituzione.  Linus Torvalds