Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1606 connectés 

 

 

Proxmox c'est ?




Attention si vous cliquez sur "voir les résultats" vous ne pourrez plus voter

 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  208  209  210  211  212  213  214  215  216
Auteur Sujet :

[TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !

n°1492275
jeffk
Fluent in shitposting
Posté le 04-06-2024 à 20:57:13  profilanswer
 

Reprise du message précédent :

MilesTEG1 a écrit :


Ha oui la doc officielle .
Je l’ai parcourue rapidement, c’est pas très pratique de tout se taper en ligne de commande.
Ça devrait être intégré dans la GUI.

 

C'est pas possible, Proxmox Backup Client c'est justement pour backup des trucs custom vers ton PBS (sans notions de PVE).
Pour PVE, c'est dans PVE évidement :o

Message cité 1 fois
Message édité par jeffk le 04-06-2024 à 20:57:30
mood
Publicité
Posté le 04-06-2024 à 20:57:13  profilanswer
 

n°1492278
MilesTEG1
Posté le 04-06-2024 à 22:22:06  profilanswer
 

jeffk a écrit :


 
C'est pas possible, Proxmox Backup Client c'est justement pour backup des trucs custom vers ton PBS (sans notions de PVE).
Pour PVE, c'est dans PVE évidement :o


Ha ok j’avais pas saisi  :pt1cable:  
Et donc ça peut être chiffré aussi ?
 
M’enfin faut que les données soient sur un hôtes pouvant installer proxmox backup client.
Pas sûr que surin syno ça passe …


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492280
extenue1
Posté le 04-06-2024 à 22:55:29  profilanswer
 

Laisse tomber , c'est pas pour toi

n°1492281
MilesTEG1
Posté le 05-06-2024 à 08:28:36  profilanswer
 

extenue1 a écrit :

Laisse tomber , c'est pas pour toi


C’est bien ce que je me disais  :pt1cable:  
 
Pour moi il me faut une interface graphique d’un côté pour gérer les sauvegardes.
Du coup va me falloir tester layer7 pour pbs.
Faut que je dimensionne mes backups.
Mais je pense partir sur 2To.
 
Je reste chez kdrive encore un peu et puis je testerais Hetzner


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492300
ilium
Candeur et décadence
Posté le 06-06-2024 à 12:53:58  profilanswer
 

J'ai une question sur PBS que je souhaiterais ajouter à mon PVE.
 
Je voyais 2 options dans mon cas:
-le PVE avec une VM PBS et des disques de sauvegarde distants (NAS)
-un PBS avec le stockage backup le tout sur une seconde machine.
 
J'ai l'impression que PBS n'est pas conçu pour utiliser des disques distants (NFS, iSCSI) et cherche des disques locaux. Ca n'empêche évidemment pas de monter un NFS dans le shell mais je voulais savoir s'il y avait une option prévue directement dans l'interface et que j'aurais loupée.

Message cité 1 fois
Message édité par ilium le 06-06-2024 à 13:26:03
n°1492301
mqnu
Hu ?
Posté le 06-06-2024 à 14:38:28  profilanswer
 

ilium a écrit :

J'ai une question sur PBS que je souhaiterais ajouter à mon PVE.
 
Je voyais 2 options dans mon cas:
-le PVE avec une VM PBS et des disques de sauvegarde distants (NAS)
-un PBS avec le stockage backup le tout sur une seconde machine.
 
J'ai l'impression que PBS n'est pas conçu pour utiliser des disques distants (NFS, iSCSI) et cherche des disques locaux. Ca n'empêche évidemment pas de monter un NFS dans le shell mais je voulais savoir s'il y avait une option prévue directement dans l'interface et que j'aurais loupée.


 
En effet PBS n'est pas ultra fan de stockages distants, mais ça passe en les montants directement sur le système.
 
J'ai lancé il y a peu un service de backup pour PVE "dans le cloud", qui s'appuie sur PBS.
 
C'est tout frais ça vient de sortir, c'est un peu plus cher qu'une simple storagebox hetzner ou que l7 mais le serveur est managé, monitoré et on peut donner accès au stockage en ssh au cas par cas aux utilisateurs.
 
Les permiers utilisateurs semblent satisfaits, on bosse actuellement sur un dashboard Grafana pour remonter 2/3 métriques sur les backups.
 
Je sais pas si dans la chartre j'ai le droit de dropper un lien ici, mais si certains sont curieux je le laisserai ici ou en mp.


---------------
:o
n°1492304
MilesTEG1
Posté le 06-06-2024 à 15:25:17  profilanswer
 

mqnu a écrit :


 
En effet PBS n'est pas ultra fan de stockages distants, mais ça passe en les montants directement sur le système.
 
J'ai lancé il y a peu un service de backup pour PVE "dans le cloud", qui s'appuie sur PBS.
 
C'est tout frais ça vient de sortir, c'est un peu plus cher qu'une simple storagebox hetzner ou que l7 mais le serveur est managé, monitoré et on peut donner accès au stockage en ssh au cas par cas aux utilisateurs.
 
Les permiers utilisateurs semblent satisfaits, on bosse actuellement sur un dashboard Grafana pour remonter 2/3 métriques sur les backups.
 
Je sais pas si dans la chartre j'ai le droit de dropper un lien ici, mais si certains sont curieux je le laisserai ici ou en mp.


Je suis preneur du lien si tu veux bien  :jap:


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492305
mqnu
Hu ?
Posté le 06-06-2024 à 15:43:02  profilanswer
 

MilesTEG1 a écrit :


Je suis preneur du lien si tu veux bien  :jap:


 
En attendant d'autres avis, je t'ai envoyé un mp :)


---------------
:o
n°1492308
jeffk
Fluent in shitposting
Posté le 06-06-2024 à 19:23:37  profilanswer
 

Je veux bien le lien aussi on cherche des trucs pour backup les VMs des étudiants et de l'infra de la section (BTS SIO)

Message cité 1 fois
Message édité par jeffk le 06-06-2024 à 19:24:05
n°1492311
extenue1
Posté le 06-06-2024 à 21:36:55  profilanswer
 

Allez moi aussi je suis ouvert a tout  ;)

mood
Publicité
Posté le 06-06-2024 à 21:36:55  profilanswer
 

n°1492314
mqnu
Hu ?
Posté le 06-06-2024 à 23:28:28  profilanswer
 

jeffk a écrit :

Je veux bien le lien aussi on cherche des trucs pour backup les VMs des étudiants et de l'infra de la section (BTS SIO)

 
extenue1 a écrit :

Allez moi aussi je suis ouvert a tout ;)

 

Je vous ai envoyé un mp  :)


---------------
:o
n°1492320
ilium
Candeur et décadence
Posté le 07-06-2024 à 19:04:05  profilanswer
 

mqnu a écrit :


 
En effet PBS n'est pas ultra fan de stockages distants, mais ça passe en les montants directement sur le système.
 
J'ai lancé il y a peu un service de backup pour PVE "dans le cloud", qui s'appuie sur PBS.
 
C'est tout frais ça vient de sortir, c'est un peu plus cher qu'une simple storagebox hetzner ou que l7 mais le serveur est managé, monitoré et on peut donner accès au stockage en ssh au cas par cas aux utilisateurs.
 
Les permiers utilisateurs semblent satisfaits, on bosse actuellement sur un dashboard Grafana pour remonter 2/3 métriques sur les backups.
 
Je sais pas si dans la chartre j'ai le droit de dropper un lien ici, mais si certains sont curieux je le laisserai ici ou en mp.


 
Ok merci. Je suis preneur aussi. ;)
 
Par contre, j'en profite pour une autre question (de débutant sur PBS): les backups semblent être en push du PVE vers PBS après avoir déclaré le datastore PBS dans le PVE. Il y a moyen d'avoir du pull de PBS qui récupère sur PVE, un peu à la manière de Veeam/Altaro?
 
En terme de sécurité, les 2 options posent des questions mais dans mon cas, j'ai un PVE en ligne et un PBS qui serait à la maison et je préférerais que tout soit initié depuis la maison qui n'est pas exposée sur Internet (aucun accès entrant). En revanche et toujours si j'ai bien compris, les synchros entre plusieurs PBS se feraient en pull: c'est le PBS destination qui se connecte sur le(s) PBS source.
 
Donc si je résume ce que je crois avoir compris, les backups PVE se font forcément en push de PVE vers PBS et à l'inverse, les synchros entre PBS se font depuis la destination qui appelle les sources (pull). J'ai bon?

Message cité 1 fois
Message édité par ilium le 07-06-2024 à 19:05:23
n°1492332
ginjou
Enjoy Everything
Posté le 08-06-2024 à 21:16:24  profilanswer
 

Hello, étant complètement noob en sysadmin et serveurs, je me suis fait récemment une machine pour tester un peu proxmox et ça marche plutôt bien (pas grand chose: un lxc tail scale pour donner l'accès sans ouvrir au monde, un petit file browser pour faire un mini "cloud", docker avec forgejo pour avoir un git perso, ...).
 
Le truc c'est que j'ai fait ça sur une grosse machine (un ryzen 3600x avec grosse alim, des hdd et gros boitier) qui se tourne les pouces et qui consomme pas mal (50-60w idle), je voudrais donc migrer ça sur une mini machine type intel n100 pour baisser la conso et l'encombrement (j'ai vu plein de posts sur reddit ou des blogs de personnes qui ont tenté et arrivent à faire tourner sans trop de problème qq petites vm et une vingtaine de petits conteneurs).  
 
La question serait donc est-ce facile de backup le serveur actuel puis de le réinstaller sur la mini machine?  
 
Sinon, si jamais plus tard mon besoin évolue et que je veux plus de ram / puissance, est-ce que ça suffit de créer un cluster et ajouter une nouvelle mini machine de ce type en node? Ou alors il faudra paramêtrer d'autres trucs en plus?

n°1492334
mirtouf
Light is right !
Posté le 08-06-2024 à 23:44:34  profilanswer
 

Pas possible de transférer le stockage de l'ancienne vers la nouvelle machine ?


---------------
-~- Libérez Datoune ! -~- Camarade, toi aussi rejoins le FLD pour que la flamme de la Révolution ne s'éteigne pas ! -~- A VENDRE
n°1492336
ginjou
Enjoy Everything
Posté le 09-06-2024 à 14:47:15  profilanswer
 

Ah mais c'est possible? Ca ne risque pas de bugger à cause du hardware différent?

n°1492337
ilium
Candeur et décadence
Posté le 09-06-2024 à 16:31:36  profilanswer
 

Il y a des chances que ça passe sauf si tu as vraiment des choses exotiques.

n°1492340
depart
Posté le 09-06-2024 à 23:34:53  profilanswer
 

ilium a écrit :

 

Ok merci. Je suis preneur aussi. ;)

 

Par contre, j'en profite pour une autre question (de débutant sur PBS): les backups semblent être en push du PVE vers PBS après avoir déclaré le datastore PBS dans le PVE. Il y a moyen d'avoir du pull de PBS qui récupère sur PVE, un peu à la manière de Veeam/Altaro?

 

En terme de sécurité, les 2 options posent des questions mais dans mon cas, j'ai un PVE en ligne et un PBS qui serait à la maison et je préférerais que tout soit initié depuis la maison qui n'est pas exposée sur Internet (aucun accès entrant). En revanche et toujours si j'ai bien compris, les synchros entre plusieurs PBS se feraient en pull: c'est le PBS destination qui se connecte sur le(s) PBS source.

 

Donc si je résume ce que je crois avoir compris, les backups PVE se font forcément en push de PVE vers PBS et à l'inverse, les synchros entre PBS se font depuis la destination qui appelle les sources (pull). J'ai bon?


Firewal @home, ouvrir le pbs uniquement depuis l'ip du serveur proxmox.


Message édité par depart le 09-06-2024 à 23:35:33
n°1492344
ilium
Candeur et décadence
Posté le 10-06-2024 à 10:40:26  profilanswer
 

Je savais mais je ne souhaite pas d'où l'idée du pull plutôt que le push. Mais il semblerait que je n'ai pas le choix sauf à rajouter un intermédiaire et synchroniser le PBS externe avec un PBS interne qui se ferait en pull.

n°1492463
MilesTEG1
Posté le 17-06-2024 à 14:12:09  profilanswer
 

Salut, petite question sur les backup dans Proxmox :
 

SNoof a écrit :


ça dépend du mode de backup (suspend, snapshot, stop...) => https://pve.proxmox.com/wiki/Backup [...] ckup_modes


 
Merci :)
Du coup, c'est en mode snapshot, mais je lis ceci dans la doc :

Citation :


snapshot mode requires that all backed up volumes are on a storage that supports snapshots. Using the backup=no mount point option individual volumes can be excluded from the backup (and thus this requirement).


Mon stockage sur le NUC PVE est en Ext4 je crois, PVE a fait son sytème de partition à lui
https://i.imgur.com/tbFQmFm.png
 
Du coup, le mode snapshot fonctionne-t-il vraiment ?
 
 
 

d@kn1ko a écrit :


 
pas vu ce genre de phénomène


Ok, ça me rassure ;)
 
 
Sinon, question onduleur et serveur NUT.
J'ai un Eaton 3S 850 connecté en USB sur mon Synology, qui fait donc office de serveur  NUT.
J'ai configuré un autre NAS en tant qu'esclave ainsi que mes deux instances PVE sur deux NUC.
Ce matin j'ai dû couper l'arrivée électrique en amont de l'onduleur, ce qui a pris un peu de temps, du coup l'onduleur a épuisé sa batterie, et donc à lancer l'extinction du NAS.
J'ai configuré les NUC avec ce serveur UPS avec le fichier de configuration mis plus bas.
Sauf que les NAS se sont bien rallumé, pas de soucis, mais pas les deux NUC.
 
Comment puis faire pour que les deux NUC se rallument une fois le courant rétabli ?
 
 
 
 

# Network UPS Tools: example upsmon configuration
#
# This file contains passwords, so keep it secure.
 
# --------------------------------------------------------------------------
# RUN_AS_USER <userid>
#
# By default, upsmon splits into two processes.  One stays as root and
# waits to run the SHUTDOWNCMD.  The other one switches to another userid
# and does everything else.
#
# The default unprivileged user is set at compile-time with the option
#   'configure --with-user=...'
#
# You can override it with '-u <user>' when starting upsmon, or just
# define it here for convenience.
#
# Note: if you plan to use the reload feature, this file (upsmon.conf)
# must be readable by this user!  Since it contains passwords, DO NOT
# make it world-readable.  Also, do not make it writable by the upsmon
# user, since it creates an opportunity for an attack by changing the
# SHUTDOWNCMD to something malicious.
#
# For best results, you should create a new normal user like "nutmon",
# and make it a member of a "nut" group or similar.  Then specify it
# here and grant read access to the upsmon.conf for that group.
#
# This user should not have write access to upsmon.conf.
#
# RUN_AS_USER nut
 
RUN_AS_USER root
 
# --------------------------------------------------------------------------
# MONITOR <system> <powervalue> <username> <password> ("primary"|"secondary" )
#
# List systems you want to monitor.  Not all of these may supply power
# to the system running upsmon, but if you want to watch it, it has to
# be in this section.
#
# You must have at least one of these declared.
#
# <system> is a UPS identifier in the form <upsname>@<hostname>[:<port>]
# like ups@localhost, su700@mybox, etc.
#
# Examples:
#
#  - "su700@mybox" means a UPS called "su700" on a system called "mybox"
#
#  - "fenton@bigbox:5678" is a UPS called "fenton" on a system called
#    "bigbox" which runs upsd on port "5678".
#
# The UPS names like "su700" and "fenton" are set in your ups.conf
# in [brackets] which identify a section for a particular driver.
#
# If the ups.conf on host "doghouse" has a section called "snoopy", the
# identifier for it would be "snoopy@doghouse".
#
# <powervalue> is an integer - the number of power supplies that this UPS
# feeds on this system.  Most personal computers only have one power supply,
# so this value is normally set to 1, while most modern servers have at least
# two.  You need a pretty big or special box to have any other value here.
#
# You can also set this to 0 for a system that doesn't take any power
# from the MONITORed supply, which you still want to monitor (e.g. for an
# administrative workstation fed from a different circuit than the datacenter
# servers it monitors). Use <powervalue> if 0 when you want to hear about
# changes for a given UPS without shutting down when it goes critical.
#
# <username> and <password> must match an entry in that system's
# upsd.users.  If your username is "upsmon" and your password is
# "blah", the upsd.users would look like this:
#
# [upsmon]
#  password  = blah
#  upsmon primary  # (or secondary)
#
# "primary" means this system will shutdown last, allowing the secondary
# systems time to shutdown first.
#
# "secondary" means this system shuts down immediately when power goes
# critical and less than MINSUPPLIES power sources have reliable input feeds.
#
# The general assumption is that the "primary" system is the one with direct
# connection to an UPS (such as serial or USB cable), so the primary system
# runs the NUT driver and 'upsd' server locally and can manage the device,
# and it would often tell the UPS to completely power itself off as a step
# in power-race avoidance (see POWERDOWNFLAG for details).
#
# Also, since the primary system stays up the longest, it suffers higher risks
# of ungraceful shutdown if the estimation of remaining runtime (or of the
# time it takes to shut down this system) was guessed wrong. By consequence,
# the "secondary" systems typically monitor the power environment state
# through the 'upsd' processes running on the remote (often "primary" ) systems
# and do not directly interact with an UPS (no local NUT drivers are running
# on the secondary systems). As such, secondaries typically shut down as
# soon as there is a sufficiently long power outage, or a low-battery alert
# from the UPS, or a loss of connection to the primary while the power was
# last known to be missing.
#
# This assumption and configuration can also make sense for networked UPSes,
# where a rack full of servers might overload the communications capacity
# of the networked management card on the UPS - in this case you might either
# reduce the 'snmp-ups' or 'netxml-ups' driver polling rate, or dedicate a
# "primary" server and set up the rest as "secondary" systems.
#
# In case of such large setups as mentioned above, beware also that shutdown
# times of the rack done all at once can substantially differ from smaller
# scale experiments with single-server shutdowns, since systems can compete
# for shared storage and other limited resources as they go down (and also
# not everyone may safely shut down simultaneously - e.g. a NAS or DB server
# would better go down after all its clients). You would be well served by
# higher-end UPSes with manageable thresholds to declare a critical state.
#
# Examples:
#
# MONITOR myups@bigserver 1 upswired blah primary
# MONITOR su700@server.example.com 1 upsmon secretpass secondary
# MONITOR myups@localhost 1 upsmon pass primary # (or secondary)
 
# MONITOR ups@192.168.2.201 1 monuser secret slave
MONITOR ups@192.168.2.201 1 monuser secret secondary
 
 
# --------------------------------------------------------------------------
# MINSUPPLIES <num>
#
# Give the number of power supplies that must be receiving power to keep
# this system running.  Most systems have one power supply, so you would
# put "1" in this field.
#
# Large/expensive server type systems usually have more, and can run with
# a few missing.  Some of these can run with 2 out of 4, for example,
# so you'd set that to 2.  The idea is to keep the box running as long
# as possible, right?
#
# Obviously you have to put the redundant supplies on different UPS circuits
# for this to make sense!  See big-servers.txt in the docs subdirectory
# for more information and ideas on how to use this feature.
 
MINSUPPLIES 1
 
# --------------------------------------------------------------------------
# SHUTDOWNCMD "<command>"
#
# upsmon runs this command when the system needs to be brought down.
#
# This should work just about everywhere ... if it doesn't, well, change it,
# perhaps to a more complicated custom script.
#
# Note that while you experiment with the initial setup and want to test how
# your configuration reacts to power state changes and ultimately when power
# is reported to go critical, but do not want your system to actually turn
# off, consider setting the SHUTDOWNCMD temporarily to do something benign -
# such as posting a message with 'logger' or 'wall' or 'mailx'. Do be careful
# to plug the UPS back into the wall in a timely fashion.
 
SHUTDOWNCMD "/sbin/shutdown -h +0"
 
# --------------------------------------------------------------------------
# NOTIFYCMD <command>
#
# upsmon calls this to send messages when things happen
#
# This command is called with the full text of the message (from NOTIFYMSG)
# as one argument.
#
# The environment string NOTIFYTYPE will contain the type string of
# whatever caused this event to happen.
#
# The environment string UPSNAME will contain the name of the system/device
# that generated the change.
#
# Note that this is only called for NOTIFY events that have EXEC set with
# NOTIFYFLAG.  See NOTIFYFLAG below for more details.
#
# Making this some sort of shell script might not be a bad idea.
# Alternately you can use the upssched program as your NOTIFYCMD for some
# more complex setups (e.g. to ease handling of notification storms).
# For more information and ideas, see docs/scheduling.txt
#
# Example:
# NOTIFYCMD /bin/notifyme
 
NOTIFYCMD /usr/sbin/upssched
 
# --------------------------------------------------------------------------
# POLLFREQ <n>
#
# Polling frequency for normal activities, measured in seconds.
#
# Adjust this to keep upsmon from flooding your network, but don't make
# it too high or it may miss certain short-lived power events.
 
POLLFREQ 5
 
# --------------------------------------------------------------------------
# POLLFREQALERT <n>
#
# Polling frequency in seconds while UPS on battery.
#
# You can make this number lower than POLLFREQ, which will make updates
# faster when any UPS is running on battery.  This is a good way to tune
# network load if you have a lot of these things running.
#
# The default is 5 seconds for both this and POLLFREQ.
 
POLLFREQALERT 5
 
# --------------------------------------------------------------------------
# HOSTSYNC - How long upsmon will wait before giving up on another upsmon
#
# The primary upsmon process uses this number when waiting for secondary
# systems to disconnect once it has set the forced shutdown (FSD) flag.
# If they don't disconnect after this many seconds, it goes on without them.
#
# Similarly, upsmon secondary processes wait up to this interval for the
# primary upsmon to set FSD when an UPS they are monitoring goes critical -
# that is, on battery and low battery.  If the primary doesn't do its job,
# the secondaries will shut down anyway to avoid damage to the file systems.
#
# This "wait for FSD" is done to avoid races where the status changes
# to critical and back between polls by the primary.
 
HOSTSYNC 15
 
# --------------------------------------------------------------------------
# DEADTIME - Interval to wait before declaring a stale ups "dead"
#
# upsmon requires a UPS to provide status information every few seconds
# (see POLLFREQ and POLLFREQALERT) to keep things updated.  If the status
# fetch fails, the UPS is marked stale.  If it stays stale for more than
# DEADTIME seconds, the UPS is marked dead.
#
# A dead UPS that was last known to be on battery is assumed to have gone
# to a low battery condition.  This may force a shutdown if it is providing
# a critical amount of power to your system.
#
# Note: DEADTIME should be a multiple of POLLFREQ and POLLFREQALERT.
# Otherwise you'll have "dead" UPSes simply because upsmon isn't polling
# them quickly enough.  Rule of thumb: take the larger of the two
# POLLFREQ values, and multiply by 3.
 
DEADTIME 15
 
# --------------------------------------------------------------------------
# POWERDOWNFLAG - Flag file for forcing UPS shutdown on the primary system
#
# upsmon will create a file with this name in primary mode when it's time
# to shut down the load.  You should check for this file's existence in
# your shutdown scripts and run 'upsdrvctl shutdown' if it exists, to tell
# the UPS(es) to power off.
#
# See the config-notes.txt file in the docs subdirectory for more information.
# Refer to the section:
# [[UPS_shutdown]] "Configuring automatic shutdowns for low battery events"
# or refer to the online version.
 
POWERDOWNFLAG /etc/killpower
 
# --------------------------------------------------------------------------
# NOTIFYMSG - change messages sent by upsmon when certain events occur
#
# You can change the default messages to something else if you like.
#
# NOTIFYMSG <notify type> "message"
#
# NOTIFYMSG ONLINE "UPS %s on line power"
# NOTIFYMSG ONBATT "UPS %s on battery"
# NOTIFYMSG LOWBATT "UPS %s battery is low"
# NOTIFYMSG FSD  "UPS %s: forced shutdown in progress"
# NOTIFYMSG COMMOK "Communications with UPS %s established"
# NOTIFYMSG COMMBAD "Communications with UPS %s lost"
# NOTIFYMSG SHUTDOWN "Auto logout and shutdown proceeding"
# NOTIFYMSG REPLBATT "UPS %s battery needs to be replaced"
# NOTIFYMSG NOCOMM "UPS %s is unavailable"
# NOTIFYMSG NOPARENT "upsmon parent process died - shutdown impossible"
#
# Note that %s is replaced with the identifier of the UPS in question.
#
# Possible values for <notify type>:
#
# ONLINE   : UPS is back online
# ONBATT   : UPS is on battery
# LOWBATT  : UPS has a low battery (if also on battery, it's "critical" )
# FSD      : UPS is being shutdown by the primary (FSD = "Forced Shutdown" )
# COMMOK   : Communications established with the UPS
# COMMBAD  : Communications lost to the UPS
# SHUTDOWN : The system is being shutdown
# REPLBATT : The UPS battery is bad and needs to be replaced
# NOCOMM   : A UPS is unavailable (can't be contacted for monitoring)
# NOPARENT : The process that shuts down the system has died (shutdown impossible)
 
# --------------------------------------------------------------------------
# NOTIFYFLAG - change behavior of upsmon when NOTIFY events occur
#
# By default, upsmon sends walls (global messages to all logged in users)
# and writes to the syslog when things happen.  You can change this.
#
# NOTIFYFLAG <notify type> <flag>[+<flag>][+<flag>] ...
#
# NOTIFYFLAG ONLINE SYSLOG+WALL
# NOTIFYFLAG ONBATT SYSLOG+WALL
# NOTIFYFLAG LOWBATT SYSLOG+WALL
# NOTIFYFLAG FSD SYSLOG+WALL
# NOTIFYFLAG COMMOK SYSLOG+WALL
# NOTIFYFLAG COMMBAD SYSLOG+WALL
# NOTIFYFLAG SHUTDOWN SYSLOG+WALL
# NOTIFYFLAG REPLBATT SYSLOG+WALL
# NOTIFYFLAG NOCOMM SYSLOG+WALL
# NOTIFYFLAG NOPARENT SYSLOG+WALL
#
# Possible values for the flags:
#
# SYSLOG - Write the message in the syslog
# WALL   - Write the message to all users on the system
# EXEC   - Execute NOTIFYCMD (see above) with the message
# IGNORE - Don't do anything
#
# If you use IGNORE, don't use any other flags on the same line.
 
NOTIFYFLAG ONLINE EXEC
NOTIFYFLAG ONBATT EXEC
NOTIFYFLAG LOWBATT EXEC
NOTIFYFLAG NOCOMM EXEC
NOTIFYFLAG COMMBAD IGNORE  
NOTIFYFLAG COMMOK IGNORE
NOTIFYFLAG SHUTDOWN IGNORE
NOTIFYFLAG FSD EXEC
NOTIFYFLAG NOPARENT SYSLOG
 
# --------------------------------------------------------------------------
# RBWARNTIME - replace battery warning time in seconds
#
# upsmon will normally warn you about a battery that needs to be replaced
# every 43200 seconds, which is 12 hours.  It does this by triggering a
# NOTIFY_REPLBATT which is then handled by the usual notify structure
# you've defined above.
#
# If this number is not to your liking, override it here.
 
RBWARNTIME 43200
 
# --------------------------------------------------------------------------
# NOCOMMWARNTIME - no communications warning time in seconds
#
# upsmon will let you know through the usual notify system if it can't
# talk to any of the UPS entries that are defined in this file.  It will
# trigger a NOTIFY_NOCOMM by default every 300 seconds unless you
# change the interval with this directive.
 
NOCOMMWARNTIME 300
 
# --------------------------------------------------------------------------
# FINALDELAY - last sleep interval before shutting down the system
#
# On a primary, upsmon will wait this long after sending the NOTIFY_SHUTDOWN
# before executing your SHUTDOWNCMD.  If you need to do something in between
# those events, increase this number.  Remember, at this point your UPS is
# almost depleted, so don't make this too high.  If needed, on high-end UPS
# devices you can usually configure when the low-battery state is announced
# based on estimated remaining run-time or on charge level of the batteries.
#
# Alternatively, you can set this very low so you don't wait around when
# it's time to shut down.  Some UPSes don't give much warning for low
# battery and will require a value of 0 here for a safe shutdown.
#
# Note: If FINALDELAY on the secondary is greater than HOSTSYNC on the
# primary, the primary will give up waiting for that secondary system
# to disconnect.
 
FINALDELAY 5
 
# --------------------------------------------------------------------------
# CERTPATH - path to certificates (database directory or directory with CA's)
#
# When compiled with SSL support, you can enter the certificate path here.
#
# With NSS:
# Certificates are stored in a dedicated database (split into 3 files).
# Specify the path of the database directory.
#
# CERTPATH /etc/nut/cert/upsmon
#
# With OpenSSL:
# Directory containing CA certificates in PEM format, used to verify
# the server certificate presented by the upsd server. The files each
# contain one CA certificate. The files are looked up by the CA subject
# name hash value, which must hence be available.
#
# CERTPATH /usr/ssl/certs
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.
 
# --------------------------------------------------------------------------
# CERTIDENT - self certificate name and database password
# CERTIDENT <certificate name> <database password>
#
# When compiled with SSL support with NSS, you can specify the certificate
# name to retrieve from database to authenticate itself and the password
# required to access certificate related private key.
#
# CERTIDENT "my nut monitor" "MyPasSw0rD"
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.
 
# --------------------------------------------------------------------------
# CERTHOST - security properties for an host
# CERTHOST <hostname> <certificate name> <certverify> <forcessl>
#
# When compiled with SSL support with NSS, you can specify security directive
# for each server you can contact.
# Each entry maps server name with the expected certificate name and flags
# indicating if the server certificate is verified and if the connection
# must be secure.
#
# CERTHOST localhost "My nut server" 1 1
#
# See 'docs/security.txt' or the Security chapter of NUT user manual
# for more information on the SSL support in NUT.
 
# --------------------------------------------------------------------------
# CERTVERIFY - make upsmon verify all connections with certificates
# CERTVERIFY 1
#
# When compiled with SSL support, make upsmon verify all connections with
# certificates.
# Without this, there is no guarantee that the upsd is the right host.
# Enabling this greatly reduces the risk of man in the middle attacks.
# This effectively forces the use of SSL, so don't use this unless
# all of your upsd hosts are ready for SSL and have their certificates
# in order.
# When compiled with NSS support of SSL, can be overridden for host
# specified with a CERTHOST directive.
 
 
# --------------------------------------------------------------------------
# FORCESSL - force upsmon to use SSL
# FORCESSL 1
#
# When compiled with SSL, specify that a secured connection must be used
# to communicate with upsd.
# If you don't use 'CERTVERIFY 1', then this will at least make sure
# that nobody can sniff your sessions without a large effort.  Setting
# this will make upsmon drop connections if the remote upsd doesn't
# support SSL, so don't use it unless all of them have it running.
# When compiled with NSS support of SSL, can be overridden for host
# specified with a CERTHOST directive.
 
# --------------------------------------------------------------------------
# DEBUG_MIN - specify minimal debugging level for upsmon daemon
# e.g. DEBUG_MIN 6
#
# Optionally specify a minimum debug level for `upsmon` daemon, e.g. for
# troubleshooting a deployment, without impacting foreground or background
# running mode directly, and without need to edit init-scripts or service
# unit definitions. Note that command-line option `-D` can only increase
# this verbosity level.
#
# NOTE: if the running daemon receives a `reload` command, presence of the
# `DEBUG_MIN NUMBER` value in the configuration file can be used to tune
# debugging verbosity in the running service daemon (it is recommended to
# comment it away or set the minimum to explicit zero when done, to avoid
# huge journals and I/O system abuse). Keep in mind that for this run-time
# tuning, the `DEBUG_MIN` value *present* in *reloaded* configuration files
# is applied instantly and overrides any previously set value, from file
# or CLI options, regardless of older logging level being higher or lower
# than the newly found number; a missing (or commented away) value however
# does not change the previously active logging verbosity.


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492464
katkar
Posté le 17-06-2024 à 17:17:02  profilanswer
 

Je t'ai répondu sur le topic HA :o

n°1492475
depart
Posté le 17-06-2024 à 22:56:08  profilanswer
 

Pour les snapshots, oui FS spécifique requis (zfs typiquement).
J'avais dû répartir à zéro sur ma première installation à cause de ça.

n°1492477
MilesTEG1
Posté le 18-06-2024 à 06:19:28  profilanswer
 

katkar a écrit :

Je t'ai répondu sur le topic HA :o


J’ai vu merci  :jap:  
J’ai répondu  :ange:  

depart a écrit :

Pour les snapshots, oui FS spécifique requis (zfs typiquement).
J'avais dû répartir à zéro sur ma première installation à cause de ça.


Ha et si le snapshot ne fonctionne pas ça bascule automatiquement sur un autre mode ?
Comme je peux vérifier.  
Car mes sauvegardes se font bien. Elles sont restaurables sans soucis.


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492478
depart
Posté le 18-06-2024 à 06:43:36  profilanswer
 

MilesTEG1 a écrit :


J’ai vu merci :jap:
J’ai répondu :ange:

 
MilesTEG1 a écrit :


Ha et si le snapshot ne fonctionne pas ça bascule automatiquement sur un autre mode ?
Comme je peux vérifier.
Car mes sauvegardes se font bien. Elles sont restaurables sans soucis.


Tu peux regarder dans les logs, c'est marqué que le FS ne supporte pas le snapshot sans arrêter la VM donc il la stoppe le temps du backup ou de la réplication et la redémarre ensuite.

n°1492479
MilesTEG1
Posté le 18-06-2024 à 07:27:25  profilanswer
 

depart a écrit :


Tu peux regarder dans les logs, c'est marqué que le FS ne supporte pas le snapshot sans arrêter la VM donc il la stoppe le temps du backup ou de la réplication et la redémarre ensuite.


J’ai ça comme log de backup envoyé en e-mail après :

Details
 
VMID Name Status Time Size Filename
200 HAOS--NUC2 ok 1min 10s 32.001 GiB vm/200/2024-06-17T10:00:01Z
Total running time: 1min 10s
Total size: 32.001 GiB
Logs
 
vzdump 200 --mode snapshot --notification-mode notification-system --fleecing 0 --quiet 1 --storage PBS-VM-Asustor --notes-template '{{guestname}}'
 
 
200: 2024-06-17 12:00:01 INFO: Starting Backup of VM 200 (qemu)
200: 2024-06-17 12:00:01 INFO: status = running
200: 2024-06-17 12:00:01 INFO: VM Name: HAOS--NUC2
200: 2024-06-17 12:00:01 INFO: include disk 'scsi0' 'local-lvm:vm-200-disk-1' 32G
200: 2024-06-17 12:00:01 INFO: include disk 'efidisk0' 'local-lvm:vm-200-disk-0' 4M
200: 2024-06-17 12:00:01 INFO: backup mode: snapshot
200: 2024-06-17 12:00:01 INFO: ionice priority: 7
200: 2024-06-17 12:00:01 INFO: creating Proxmox Backup Server archive 'vm/200/2024-06-17T10:00:01Z'
200: 2024-06-17 12:00:01 INFO: issuing guest-agent 'fs-freeze' command
200: 2024-06-17 12:00:02 INFO: issuing guest-agent 'fs-thaw' command
200: 2024-06-17 12:00:02 INFO: started backup task '4faef136-f7f2-4350-af2b-c336b971a352'
200: 2024-06-17 12:00:02 INFO: resuming VM again
200: 2024-06-17 12:00:02 INFO: efidisk0: dirty-bitmap status: created new
200: 2024-06-17 12:00:02 INFO: scsi0: dirty-bitmap status: created new
200: 2024-06-17 12:00:05 INFO:   6% (2.1 GiB of 32.0 GiB) in 3s, read: 701.3 MiB/s, write: 217.3 MiB/s
200: 2024-06-17 12:00:08 INFO:   8% (2.9 GiB of 32.0 GiB) in 6s, read: 272.0 MiB/s, write: 173.3 MiB/s
200: 2024-06-17 12:00:11 INFO:  13% (4.3 GiB of 32.0 GiB) in 9s, read: 492.0 MiB/s, write: 220.0 MiB/s
200: 2024-06-17 12:00:14 INFO:  16% (5.4 GiB of 32.0 GiB) in 12s, read: 361.3 MiB/s, write: 157.3 MiB/s
200: 2024-06-17 12:00:17 INFO:  19% (6.4 GiB of 32.0 GiB) in 15s, read: 346.7 MiB/s, write: 106.7 MiB/s
200: 2024-06-17 12:00:20 INFO:  25% (8.0 GiB of 32.0 GiB) in 18s, read: 570.7 MiB/s, write: 157.3 MiB/s
200: 2024-06-17 12:00:23 INFO:  28% (9.2 GiB of 32.0 GiB) in 21s, read: 397.3 MiB/s, write: 109.3 MiB/s
200: 2024-06-17 12:00:26 INFO:  33% (10.6 GiB of 32.0 GiB) in 24s, read: 489.3 MiB/s, write: 154.7 MiB/s
200: 2024-06-17 12:00:29 INFO:  35% (11.2 GiB of 32.0 GiB) in 27s, read: 197.3 MiB/s, write: 108.0 MiB/s
200: 2024-06-17 12:00:32 INFO:  36% (11.7 GiB of 32.0 GiB) in 30s, read: 168.0 MiB/s, write: 81.3 MiB/s
200: 2024-06-17 12:00:35 INFO:  39% (12.7 GiB of 32.0 GiB) in 33s, read: 326.7 MiB/s, write: 168.0 MiB/s
200: 2024-06-17 12:00:38 INFO:  43% (13.8 GiB of 32.0 GiB) in 36s, read: 390.7 MiB/s, write: 152.0 MiB/s
200: 2024-06-17 12:00:41 INFO:  47% (15.2 GiB of 32.0 GiB) in 39s, read: 476.0 MiB/s, write: 222.7 MiB/s
200: 2024-06-17 12:00:44 INFO:  50% (16.2 GiB of 32.0 GiB) in 42s, read: 352.0 MiB/s, write: 80.0 MiB/s
200: 2024-06-17 12:00:47 INFO:  53% (17.1 GiB of 32.0 GiB) in 45s, read: 293.3 MiB/s, write: 112.0 MiB/s
200: 2024-06-17 12:00:50 INFO:  64% (20.8 GiB of 32.0 GiB) in 48s, read: 1.2 GiB/s, write: 33.3 MiB/s
200: 2024-06-17 12:00:53 INFO:  91% (29.1 GiB of 32.0 GiB) in 51s, read: 2.8 GiB/s, write: 94.7 MiB/s
200: 2024-06-17 12:00:56 INFO:  94% (30.2 GiB of 32.0 GiB) in 54s, read: 362.7 MiB/s, write: 194.7 MiB/s
200: 2024-06-17 12:00:59 INFO:  96% (31.0 GiB of 32.0 GiB) in 57s, read: 265.3 MiB/s, write: 74.7 MiB/s
200: 2024-06-17 12:01:02 INFO: 100% (32.0 GiB of 32.0 GiB) in 1m, read: 348.2 MiB/s, write: 52.0 MiB/s
200: 2024-06-17 12:01:02 INFO: Waiting for server to finish backup validation...
200: 2024-06-17 12:01:11 INFO: backup is sparse: 16.41 GiB (51%) total zero data
200: 2024-06-17 12:01:11 INFO: backup was done incrementally, reused 24.18 GiB (75%)
200: 2024-06-17 12:01:11 INFO: transferred 32.00 GiB in 69 seconds (474.9 MiB/s)
200: 2024-06-17 12:01:11 INFO: adding notes to backup
200: 2024-06-17 12:01:11 INFO: Finished Backup of VM 200 (00:01:10)


 
Verdict ?


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492480
fegre
Voleur professionnel
Posté le 18-06-2024 à 07:30:48  profilanswer
 

Pour moi c'est en Snapshot, en stop le mien ressemble à ça :

 

INFO: starting new backup job: vzdump --storage SSDSata --all 1 --prune-backups 'keep-daily=4,keep-weekly=2' --quiet 1 --mailnotification always --compress zstd --notes-template '{{guestname}}' --mode stop
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2024-06-18 03:00:08
INFO: status = running
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: plex
INFO: including mount point rootfs ('/') in backup
INFO: stopping virtual guest
INFO: creating vzdump archive '/mnt/SSDSata/dump/vzdump-lxc-100-2024_06_18-03_00_08.tar.zst'
INFO: Total bytes written: 5461575680 (5.1GiB, 155MiB/s)
INFO: archive file size: 3.36GB
INFO: adding notes to backup
INFO: prune older backups with retention: keep-daily=4, keep-weekly=2
INFO: removing backup 'SSDSata:backup/vzdump-lxc-100-2024_06_14-03_00_12.tar.zst'
INFO: pruned 1 backup(s) not covered by keep-retention policy
INFO: restarting vm
INFO: guest is online again after 58 seconds
INFO: Finished Backup of VM 100 (00:00:58)

 

A mon sens si ça plantait en snap, t'aurais les deux messages d'arrêt et de relance


Message édité par fegre le 18-06-2024 à 07:31:02
n°1492481
katkar
Posté le 18-06-2024 à 07:49:12  profilanswer
 

Finished Backup of VM 200
 
 :o

n°1492482
the_fireba​ll
I have fucking failed
Posté le 18-06-2024 à 08:29:46  profilanswer
 

Si tu fais du LVM c’est bon, LVM supporte les snapshots


---------------
Two thousand years of misery, of torture in my name, hypocrisy made paramount, paranoia the law, my name is called religion, sadistic, sacred whore.
n°1492483
MilesTEG1
Posté le 18-06-2024 à 09:07:56  profilanswer
 

the_fireball a écrit :

Si tu fais du LVM c’est bon, LVM supporte les snapshots


Oui le système est en lvm.
C’est possible du lvm en ext4fs ? Car je crois que c’est ce que j’ai mis à l’installation.


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492496
depart
Posté le 18-06-2024 à 11:57:41  profilanswer
 

MilesTEG1 a écrit :


J’ai ça comme log de backup envoyé en e-mail après :

Details
 
VMID Name Status Time Size Filename
200 HAOS--NUC2 ok 1min 10s 32.001 GiB vm/200/2024-06-17T10:00:01Z
Total running time: 1min 10s
Total size: 32.001 GiB
Logs
 
vzdump 200 --mode snapshot --notification-mode notification-system --fleecing 0 --quiet 1 --storage PBS-VM-Asustor --notes-template '{{guestname}}'
 
 
200: 2024-06-17 12:00:01 INFO: Starting Backup of VM 200 (qemu)
200: 2024-06-17 12:00:01 INFO: status = running
200: 2024-06-17 12:00:01 INFO: VM Name: HAOS--NUC2
200: 2024-06-17 12:00:01 INFO: include disk 'scsi0' 'local-lvm:vm-200-disk-1' 32G
200: 2024-06-17 12:00:01 INFO: include disk 'efidisk0' 'local-lvm:vm-200-disk-0' 4M
200: 2024-06-17 12:00:01 INFO: backup mode: snapshot
200: 2024-06-17 12:00:01 INFO: ionice priority: 7
200: 2024-06-17 12:00:01 INFO: creating Proxmox Backup Server archive 'vm/200/2024-06-17T10:00:01Z'
200: 2024-06-17 12:00:01 INFO: issuing guest-agent 'fs-freeze' command
200: 2024-06-17 12:00:02 INFO: issuing guest-agent 'fs-thaw' command
200: 2024-06-17 12:00:02 INFO: started backup task '4faef136-f7f2-4350-af2b-c336b971a352'
200: 2024-06-17 12:00:02 INFO: resuming VM again
200: 2024-06-17 12:00:02 INFO: efidisk0: dirty-bitmap status: created new
200: 2024-06-17 12:00:02 INFO: scsi0: dirty-bitmap status: created new
200: 2024-06-17 12:00:05 INFO:   6% (2.1 GiB of 32.0 GiB) in 3s, read: 701.3 MiB/s, write: 217.3 MiB/s
200: 2024-06-17 12:00:08 INFO:   8% (2.9 GiB of 32.0 GiB) in 6s, read: 272.0 MiB/s, write: 173.3 MiB/s
200: 2024-06-17 12:00:11 INFO:  13% (4.3 GiB of 32.0 GiB) in 9s, read: 492.0 MiB/s, write: 220.0 MiB/s
200: 2024-06-17 12:00:14 INFO:  16% (5.4 GiB of 32.0 GiB) in 12s, read: 361.3 MiB/s, write: 157.3 MiB/s
200: 2024-06-17 12:00:17 INFO:  19% (6.4 GiB of 32.0 GiB) in 15s, read: 346.7 MiB/s, write: 106.7 MiB/s
200: 2024-06-17 12:00:20 INFO:  25% (8.0 GiB of 32.0 GiB) in 18s, read: 570.7 MiB/s, write: 157.3 MiB/s
200: 2024-06-17 12:00:23 INFO:  28% (9.2 GiB of 32.0 GiB) in 21s, read: 397.3 MiB/s, write: 109.3 MiB/s
200: 2024-06-17 12:00:26 INFO:  33% (10.6 GiB of 32.0 GiB) in 24s, read: 489.3 MiB/s, write: 154.7 MiB/s
200: 2024-06-17 12:00:29 INFO:  35% (11.2 GiB of 32.0 GiB) in 27s, read: 197.3 MiB/s, write: 108.0 MiB/s
200: 2024-06-17 12:00:32 INFO:  36% (11.7 GiB of 32.0 GiB) in 30s, read: 168.0 MiB/s, write: 81.3 MiB/s
200: 2024-06-17 12:00:35 INFO:  39% (12.7 GiB of 32.0 GiB) in 33s, read: 326.7 MiB/s, write: 168.0 MiB/s
200: 2024-06-17 12:00:38 INFO:  43% (13.8 GiB of 32.0 GiB) in 36s, read: 390.7 MiB/s, write: 152.0 MiB/s
200: 2024-06-17 12:00:41 INFO:  47% (15.2 GiB of 32.0 GiB) in 39s, read: 476.0 MiB/s, write: 222.7 MiB/s
200: 2024-06-17 12:00:44 INFO:  50% (16.2 GiB of 32.0 GiB) in 42s, read: 352.0 MiB/s, write: 80.0 MiB/s
200: 2024-06-17 12:00:47 INFO:  53% (17.1 GiB of 32.0 GiB) in 45s, read: 293.3 MiB/s, write: 112.0 MiB/s
200: 2024-06-17 12:00:50 INFO:  64% (20.8 GiB of 32.0 GiB) in 48s, read: 1.2 GiB/s, write: 33.3 MiB/s
200: 2024-06-17 12:00:53 INFO:  91% (29.1 GiB of 32.0 GiB) in 51s, read: 2.8 GiB/s, write: 94.7 MiB/s
200: 2024-06-17 12:00:56 INFO:  94% (30.2 GiB of 32.0 GiB) in 54s, read: 362.7 MiB/s, write: 194.7 MiB/s
200: 2024-06-17 12:00:59 INFO:  96% (31.0 GiB of 32.0 GiB) in 57s, read: 265.3 MiB/s, write: 74.7 MiB/s
200: 2024-06-17 12:01:02 INFO: 100% (32.0 GiB of 32.0 GiB) in 1m, read: 348.2 MiB/s, write: 52.0 MiB/s
200: 2024-06-17 12:01:02 INFO: Waiting for server to finish backup validation...
200: 2024-06-17 12:01:11 INFO: backup is sparse: 16.41 GiB (51%) total zero data
200: 2024-06-17 12:01:11 INFO: backup was done incrementally, reused 24.18 GiB (75%)
200: 2024-06-17 12:01:11 INFO: transferred 32.00 GiB in 69 seconds (474.9 MiB/s)
200: 2024-06-17 12:01:11 INFO: adding notes to backup
200: 2024-06-17 12:01:11 INFO: Finished Backup of VM 200 (00:01:10)


 
Verdict ?


oui c'est bon, ta vm est sur un volume LVM qui supporte les snapshots.
 
Edit : mince j'avais oublié de rafraichir la page. [:graffin]


Message édité par depart le 18-06-2024 à 11:58:27
n°1492522
MilesTEG1
Posté le 18-06-2024 à 21:15:12  profilanswer
 

Bonsoir
J'ai une question probablement liée à Debian (j'utilise proxmox 8.2).
J'ai /dev/dri/card0 qui change après un reboot pour devenir /dev/dri/card1.
Après un autre reboot, ça revient à /dev/dri/card0.
Après encore un autre reboot, ça repasse à /dev/dri/card1, etc...
 
Bref c'est assez pénible car mon conteneur LXC est paramétré avec /dev/dri/card0 dans les ressources qu'il exploite.
Et quand ça passe à /dev/dri/card1 , mon LXC refuse de démarrer.
 
Sauriez-vous comment fixer l'iGPU à rester sur /dev/dri/card0 après les reboot ?
 
PS : ma machine est un NUC Geekom IT13, avec un Intel Core i9-13900H, et un iGPU Intel Iris Xe 1.50 GHz.
PPS : cross-topic avec le sujet Debian.
 
Merci d'avance.


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492525
depart
Posté le 18-06-2024 à 22:12:50  profilanswer
 

MilesTEG1 a écrit :

Bonsoir
J'ai une question probablement liée à Debian (j'utilise proxmox 8.2).
J'ai /dev/dri/card0 qui change après un reboot pour devenir /dev/dri/card1.
Après un autre reboot, ça revient à /dev/dri/card0.
Après encore un autre reboot, ça repasse à /dev/dri/card1, etc...

 

Bref c'est assez pénible car mon conteneur LXC est paramétré avec /dev/dri/card0 dans les ressources qu'il exploite.
Et quand ça passe à /dev/dri/card1 , mon LXC refuse de démarrer.

 

Sauriez-vous comment fixer l'iGPU à rester sur /dev/dri/card0 après les reboot ?

 

PS : ma machine est un NUC Geekom IT13, avec un Intel Core i9-13900H, et un iGPU Intel Iris Xe 1.50 GHz.
PPS : cross-topic avec le sujet Debian.

 

Merci d'avance.


C'est quoi dri ? Il n'y a pas moyen d'y accéder via un id unique comme pour les disques ?

n°1492535
MilesTEG1
Posté le 19-06-2024 à 10:42:11  profilanswer
 

depart a écrit :


C'est quoi dri ? Il n'y a pas moyen d'y accéder via un id unique comme pour les disques ?


/dev/dri c'est l'iGPU.
Dans le LXC, j'ai plex qui en a besoin ;)

 

Je ne sais pas comment avoir l'ID de ça. Et même si je l'avais, je ne suis pas sûr que plex puisse le comprendre.

Message cité 1 fois
Message édité par MilesTEG1 le 19-06-2024 à 10:42:50

---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492544
roondar
Posté le 19-06-2024 à 14:36:28  profilanswer
 

MilesTEG1 a écrit :


/dev/dri c'est l'iGPU.
Dans le LXC, j'ai plex qui en a besoin ;)  
 
Je ne sais pas comment avoir l'ID de ça. Et même si je l'avais, je ne suis pas sûr que plex puisse le comprendre.


 
Une piste : https://bbs.archlinux.org/viewtopic.php?id=288578

n°1492545
MilesTEG1
Posté le 19-06-2024 à 14:42:42  profilanswer
 


Oué sauf que c'est un CPU Intel que j'ai  :pt1cable:  
Et que ça change à chaque reboot de l'hôte proxmox.


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492546
hydrosaure
Posté le 19-06-2024 à 16:35:27  profilanswer
 

L'origine du problème doit être le même, un ordre de démarrage des services qui initialisent et gère l'affichage.
 
ça serait aussi intéressant de voir si le comportement est le même lors d'un reboot et lors d'un cold boot.

n°1492547
roondar
Posté le 19-06-2024 à 16:41:43  profilanswer
 

MilesTEG1 a écrit :


Oué sauf que c'est un CPU Intel que j'ai  :pt1cable:  
Et que ça change à chaque reboot de l'hôte proxmox.


Mais tu as regardé l'autre thread https://bbs.archlinux.org/viewtopic.php?id=287936 ?

n°1492558
ilium
Candeur et décadence
Posté le 19-06-2024 à 21:59:50  profilanswer
 

Quelqu'un a compris comment fonctionnait la rétention sur PBS ou a fait un plan de sauvegarde un peu complexe parce que j'ai un doute lorsque les dates se téléscopent: les weekly sont faites le dimanche, les monthly sont faites le dernier jour du mois et on comprend bien que ça va poser problème parce que le dernier jour du mois ne tombera pas souvent un dimanche.
 
Imaginons qu'on fasse une sauvegarde quotidienne à minuit et qu'on souhaite garder 8 semaines et 10 mois donc 1 an de sauvegardes au total. Après 2 mois, on a donc les 7 derniers dimanches plus le jour en cours (vérifié sur leur simulateur). Jusque là c'est simple.
 
Si c'est aujourd'hui, on a donc la sauvegarde d'aujourd'hui mercredi 19 juin, celle des dimanches 16 juin, 9 juin, 2 juin, 26 mai, 19 mai, 12 mai, 5 mai et la précédente était celle du 28 avril. Celle-ci ne sera pas effacée mais sera la première mensuelle à l'issue des 8 semaines car le système n'aura a priori pas conservé celle du 30 avril.
 
Dans ce cas relativement simple, cela signifie-t-il que les mensuelles seront en fait celle du dernier dimanche du mois et non celle du dernier jour du mois?
 
Je ne suis évidemment pas à quelques jours près, l'idée est d'avoir quelque chose de cohérent avec plus de granularité sur ce qui est récent et de moins en moins plus on s'éloigne dans le temps. Mais j'aimerais bien comprendre car on peut imaginer des scénarios plus compliqués et le but est de ne pas se retrouver avec des trous.
 
edit: Le simulateur: https://pbs.proxmox.com/docs/prune-simulator/index.html mais il aurait un bug car il me sort quand même des mensuelles le dernier jour du mois sauf que je ne vois pas comment c'est possible si elle a été purgée entre temps.
 
edit 2: J'ai oublié la question subsidiaire: la rétention sur le PVE et les prune jobs côté PBS, ce sont 2 process différents mais avec la même finalité? Il est donc inutile de faire les 2? J'imagine qu'en terme de sécurité, c'est mieux de cocher keep all côté PVE et de faire le nettoyage côté PBS.
 
Last but not least: chez Proxmox, ils disaient aussi qu'il n'y avait pas moyen d'accéder aux backups depuis PVE et qu'elles sont donc protégées mais imaginons qu'on a 30 jours de retention sur un job, si on modifie la valeur à 0 côté PVE, ne prend-on pas le risque de tout virer ce qui a été conservé jusqu'à présent justement?
 
Dernière question sans objet: on a accès à ses backups donc on peut les supprimer dans tous les cas. Si on veut de l'immutable ou s'en approcher, il faut gérer les droits utilisateurs et/ou prévoir la synchro du PBS avec les bons paramètres.


Message édité par ilium le 20-06-2024 à 12:44:37
n°1492832
Shaad
Posté le 01-07-2024 à 11:41:50  profilanswer
 

:hello:  
 
Première petite déconvenue en 4 ans de Proxmox : suite à ma dernière mise à jour du host, mon Proxmox ne démarre plus.
J'ai découvert (avec joie) le mode de démarrage avancé de Proxmox. J'ai pu choisir de booter sur une version précédente et ça fonctionne impec.
Lorsque je lance un upgrade full j'ai différentes erreurs qui remontent sur la compilation du kernel 5.5.8-2-pve de mémoire.
J'ai découvert hier soir qu'on pouvait 'pin' le kernel par défaut avec lequel on voulait booter proxmox, donc j'ai choisi le kernel précédent et maintenant mes reboots se passent bien.
 
Savez-vous comment je pourrais rollback complètement mon serveur à la dernière version fonctionnelle, avant de relancer un upgrade full en espérant que celui-ci se passe mieux svp ?  :)  
 
J'essaierai de regarder ce soir dans les erreurs si des choses me parlent, mais à la première lecture rapide hier soir c'était surtout beaucoup de chinois !  :o  
 
Merci  :jap:  

n°1492833
desp
Posté le 01-07-2024 à 11:46:11  profilanswer
 

Shaad a écrit :

:hello:  
 
Première petite déconvenue en 4 ans de Proxmox : suite à ma dernière mise à jour du host, mon Proxmox ne démarre plus.
J'ai découvert (avec joie) le mode de démarrage avancé de Proxmox. J'ai pu choisir de booter sur une version précédente et ça fonctionne impec.
Lorsque je lance un upgrade full j'ai différentes erreurs qui remontent sur la compilation du kernel 5.5.8-2-pve de mémoire.
J'ai découvert hier soir qu'on pouvait 'pin' le kernel par défaut avec lequel on voulait booter proxmox, donc j'ai choisi le kernel précédent et maintenant mes reboots se passent bien.
 
Savez-vous comment je pourrais rollback complètement mon serveur à la dernière version fonctionnelle, avant de relancer un upgrade full en espérant que celui-ci se passe mieux svp ?  :)  
 
J'essaierai de regarder ce soir dans les erreurs si des choses me parlent, mais à la première lecture rapide hier soir c'était surtout beaucoup de chinois !  :o  
 
Merci  :jap:  


Je peux pas te répondre mais merci pour ton message, j’allais faire la MAJ des 76 paquets a l’arrache….

n°1492834
MilesTEG1
Posté le 01-07-2024 à 11:57:58  profilanswer
 

Shaad a écrit :

:hello:  
 
Première petite déconvenue en 4 ans de Proxmox : suite à ma dernière mise à jour du host, mon Proxmox ne démarre plus.
J'ai découvert (avec joie) le mode de démarrage avancé de Proxmox. J'ai pu choisir de booter sur une version précédente et ça fonctionne impec.
Lorsque je lance un upgrade full j'ai différentes erreurs qui remontent sur la compilation du kernel 5.5.8-2-pve de mémoire.
J'ai découvert hier soir qu'on pouvait 'pin' le kernel par défaut avec lequel on voulait booter proxmox, donc j'ai choisi le kernel précédent et maintenant mes reboots se passent bien.
 
Savez-vous comment je pourrais rollback complètement mon serveur à la dernière version fonctionnelle, avant de relancer un upgrade full en espérant que celui-ci se passe mieux svp ?  :)  
 
J'essaierai de regarder ce soir dans les erreurs si des choses me parlent, mais à la première lecture rapide hier soir c'était surtout beaucoup de chinois !  :o  
 
Merci  :jap:  


Salut Shaad,
Tu es sur quelle version de proxmox ?
Car les noyaux que je vois être mis à jour sont des 6.8.x je crois .
 
Sinon tu backup tout et tu formattes puis tu restaure  :o


---------------
Mes ventes : [FeedBack] http://forum.hardware.fr/hfr/Achat [...] 4599_1.htm
n°1492843
ilium
Candeur et décadence
Posté le 01-07-2024 à 17:09:47  profilanswer
 

Shaad a écrit :

:hello:  
 
Première petite déconvenue en 4 ans de Proxmox : suite à ma dernière mise à jour du host, mon Proxmox ne démarre plus.
J'ai découvert (avec joie) le mode de démarrage avancé de Proxmox. J'ai pu choisir de booter sur une version précédente et ça fonctionne impec.
Lorsque je lance un upgrade full j'ai différentes erreurs qui remontent sur la compilation du kernel 5.5.8-2-pve de mémoire.
J'ai découvert hier soir qu'on pouvait 'pin' le kernel par défaut avec lequel on voulait booter proxmox, donc j'ai choisi le kernel précédent et maintenant mes reboots se passent bien.
 
Savez-vous comment je pourrais rollback complètement mon serveur à la dernière version fonctionnelle, avant de relancer un upgrade full en espérant que celui-ci se passe mieux svp ?  :)  
 
J'essaierai de regarder ce soir dans les erreurs si des choses me parlent, mais à la première lecture rapide hier soir c'était surtout beaucoup de chinois !  :o  
 
Merci  :jap:  


 
Il y a des bugs sur les derniers kernel, faut regarder les numéros de version exacts mais j'ai du bloquer un 6.8 moi aussi.
J'éviterais un rollback complet, très difficile et casse gueule dans tous les cas et me contenterais de verrouiller sur la version de kernel qui fonctionne.

Message cité 1 fois
Message édité par ilium le 01-07-2024 à 17:10:31
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  208  209  210  211  212  213  214  215  216

Aller à :
Ajouter une réponse
 

Sujets relatifs
Choix Hyperviseur pour Xeon [Box de test]Routage vm Proxmox
Questionnement sur un hyperviseur[Topikunik] Personnalisation des interfaces graphiques
Plus de sujets relatifs à : [TOPIKUNIK] Proxmox, une solution de virtualisation kellébien !


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR