Que ce soit pour créer de nouvelles alarmes dans le vCenter ou parce que certains messages d’alerte ne sont visible que dans les logs d’ESXi, nous avions autrefois recours à la page vCenter Events de Veeam pour trouver l’inspiration. Cette page n’étant plus mise à jour depuis fin 2011, nous avons chercher à produire un page similaire pour nos propres besoins et l’avons, depuis quelques temps, mise à dispo dans la rubrique “Links”. Voici la commande PowerCLI qui vous permettra de générer la votre depuis votre vCenter (et plugins) :

(Get-View EventManager).Description.EventInfo|select @{n="event";e={if ($_.key -match "^EventEx$|^ExtendedEvent$") {$_.FullFormat.split("|")[0]} else {$_.key}}},category,description,FullFormat|Out-GridView

Nous nous sommes très largement inspiré d’un post de Luc pour ce oneliner

Récemment, William à posté une liste similaire issue d’un fichier disponible en clair dans les librairies d’ESXi mais nous avons remarqué qu’il ne contenait pas les événements vob.* que nous pouvions trouver dans les logs. Après quelques recherches, nous avons fini par faire un coup de strings sur le binaire /usr/lib/vmware/vob/bin/vobd (issue d’un ESXi 5.5 1331820) pour en extraire les précieux messages. Nous avons ensuite “dédoublonné” la liste obtenue (vob.vmfs.heartbeat.timedout == esx.problem.vmfs.heartbeat.timedout par exemple) pour ne garder que le différentiel :

vob.net.fence.port.fail
vob.net.pg.uplink.transition.down
vob.net.pg.uplink.transition.up
vob.net.dvport.uplink.transition.down
vob.net.dvport.uplink.transition.up
vob.net.uplink.watchdog.timeout
vob.net.migrate.bindtovmk.failed
vob.net.portset.port.connect.fail
vob.net.lacp.uplink.peer.noresponse
vob.scsi.scsipath.add
vob.scsi.scsipath.remove
vob.scsi.scsipath.por
vob.scsi.scsipath.badpath.unsafepe
vob.scsi.scsipath.badpath.unreachpe
vob.scsi.scsipath.pathstate.dead
vob.scsi.scsipath.pathstate.off
vob.scsi.scsipath.pathstate.on
vob.scsi.scsipath.pathstate.standby
vob.iscsi.connection.started
vob.iscsi.connection.stopped
vob.iscsi.connection.error
vob.iscsi.target.async.event
vob.iscsi.session.recovery.timeout
vob.iscsi.target.permanently.removed
vob.iscsi.isns.discovery.error
vob.vmfs.lock.corruptondisk.v2
vob.user.dcui.factory.network.restored
vob.user.dcui.restarting.hostagents
vob.user.dcui.restore.factory.defaults
vob.user.dhclient.lease.offered.noexpiry
vob.user.coredump.unconfigured2
vob.user.coredump.capacity.insufficient
vob.user.scratch.partition.size.small
vob.user.scratch.partition.unconfigured
vob.user.dcui.reboot.host
vob.user.dcui.shutdown.host
vob.user.esxcli.host.reboot
vob.user.coredump.configured2
vob.cpu.mce.log
vob.cpu.nmi.ipi.vmkcs
vob.cpu.nmi.ipi.unknowncs
vob.cpu.nmi.ipi.halt
vob.cpu.nmi.ipi.savebt
vob.uw.core.dumped
vob.external.warning
vob.external.error
vob.external.info
vob.user.external.warning
vob.user.external.error
vob.user.external.info
vob.visorfs.tardisk.readonlyfile
vob.vsan.pdl.offline
vob.vsan.pdl.online
vob.vsan.net.gotip
vob.vsan.net.noip
vob.vsan.rdt.noip
vob.vsan.net.no.connectivity
vob.vsan.net.created
vob.vsan.net.reconfigured
vob.vsan.cmmds.disabled
vob.vsan.cmmds.unloaded
vob.vsan.cmmds.enabled
vob.vsan.lsom.diskerror

Pour les curieux, voici la liste originale.

Depuis leur apparition dans vSphere 4.0 en 2009 et jusqu’à aujourd’hui (malgré les nouvelles features exclusives), nous avons considéré les distributed switch comme des SPOF. L’idée de départ est très bonne mais la dépendance au vcenter nous paraissait trop importante, il était possible de lancer des actions irréversibles (sur le management network en particulier), de nombreuses kb vmware ont fait état de bugs assez gênant (surtout pour la v4.x) et nous avons toujours été inquiet de ne pouvoir presque rien faire en direct sur un ESXi en cas de problème réseau. VMware admet même le pire scénario (qui poussait les plus prudents d’entre nous à mixer standard/distributed lorsque le nombre de nic le permettait) dans  le “What’s New in vSphere 5.1 – Networking” :

However, in the VDS environment, where multiple hosts are connected to a distributed switch, any network failure or misconfiguration of the management port group can potentially disconnect all hosts from the vCenter Server system.
[...]
In vSphere 5.0, the only way for the user to recover from this situation is by going to individual hosts and building a VSS with a proper management network configuration.

vSphere 5.1 apporte, en plus d’une certaine maturité, toutes les fonctionnalités qui manquaient à DVS. L’une d’entre elles, nommé Host Networking Rollback, fera certainement changer d’avis les plus réticents (y compris nous-même). Pour faire court, cette feature “déjoue” automatiquement la dernière reconfiguration du stack réseau (standard ou distributed) qui aboutie à une déconnexion du vCenter :

Tout à fait logiquement, lorsque les ESXi recontactent le vCenter, le distributed switch annonce un “out of sync” du au rollback :

C’est là qu’une autre nouvelle feature (le Distributed Switch Rollback) rentre en scène et permet de restaurer la précédente configuration d’un distributed switch ou distributed portgroup. Attention, en cas de restart du vCenter, la dernière configuration est perdue.

When you use a VMware distributed virtual switch, each time you reconfigure the switch, the Server saves the switch configuration before applying the updates. If the vCenter Server is restarted, the saved configuration is not preserved and the method does not return a configuration specification.

Cette fonctionnalité n’étant accessible qu’avec le webclient, voici comment procéder en PowerCLI :

(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).ReconfigureDVPortgroup($(Get-VirtualPortGroup -Name TargetdvPortGroup|get-view).DVPortgroupRollback($()))

(Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).ReconfigureDvs((Get-VirtualSwitch -name TargetDistributedVirtualSwitch|get-view).DVSRollback($()))

Cette dernière action n’est d’ailleurs même pas possible en GUI, à moins d’avoir exporté la configuration du DVS dans un fichier.

Bonus : nous vous avons concocté un petit onliner pour créer une alarme afin d’être averti en cas rollback automatique sur les ESXi attachés à un distributed switch :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "vSphere Distributed Switch Rollback Event";Description = "Custom alarm to monitor vim.event.RollbackEvent Event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "vim.event.RollbackEvent";objectType = "HostSystem";status = "yellow"});)});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmare.local";Subject = "[vAlarm] {targetName} NetworkRollback Event - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false}))})});ActionFrequency = "1800"}))

Nous n’avons pas encore trouvé une solution correcte pour exporter la configuration des distributed switch/portgroup dans un fichier (le web client renvois un zip ressemblant à un vib), n’hésitez pas à nous remonter vos idées et/ou réactions sur le sujet.

Pour finir, il est maintenant possible de reconfigurer “automatiquement” la partie management network (standard ou distributed) via la DCUI :

Malheureusement il faut être sur la vm pour voir ce message, d’où l’idée d’un ami champion de badminton de faire une alarme pour remonter cet event !

Ni une, ni deux, un petit oneliner qui va créer la précieuse alarme :

if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -match "VM disks consolidation is needed"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "VM disks consolidation is needed";Description = "Custom alarm to monitor com.vmware.vc.VmDiskConsolidationNeeded event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "com.vmware.vc.VmDiskConsolidationNeeded";objectType = "VirtualMachine";status = "red"});(New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "com.vmware.vc.VmDiskConsolidatedEvent";objectType = "VirtualMachine";status = "green"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} VM disks consolidation is needed - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}

Comme d’hab, il faut remplacer “admin@vmare.local” par le mail qui vous convient et rajouter (ou remplacer) un envoi de trap snmp si besoin. Cette alarme s’auto-acquittera lorsque la consolidation sera réussie :

En exclusivité mondiale (si, si), nous vous livrons aujourd’hui les méthodes, longtemps gardées secrètes, pour créer cette précieuse alarme qui vous avertira lorsqu’un datastore NFS n’est plus accessible sur un ESX. Tout cela grâce à l’event “esx.problem.vmfs.nfs.server.disconnect” que nous avons trouvé dans la fameuse liste de veeam qui couvre vim 2.5 à 5.0

A la “mano” :

Avec un oneliner PowerCLI :

if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -match "Lost connection to NFS server"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Lost connection to NFS server";Description = "Custom alarm to monitor esx.problem.vmfs.nfs.server.disconnect event";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.EventAlarmExpression -Property @{eventType = "EventEx";EventTypeId = "esx.problem.vmfs.nfs.server.disconnect";objectType = "HostSystem";status = "red"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} nfs.server.disconnect - {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}

MAJ 31/05/2012 : Les stats de dropped packets n’étant pas dispo pour les VM sur vCenter 4.x, nous avons ajouté un script pour créer des alarmes sur les vmnic, pour les vswitch des ESX donc. Merci à puchy pour son feedback.

Si, comme nous, vous vous êtes rendu compte un peu tard que de nombreux packets réseau étaient droppés sur des VM Windows 2008 R2 avec l’adapteur e1000, vous serez intéressé par notre petit oneliner (what else ?) qui vous permettra de créer des alarmes dans votre vCenter pour vous en avertir. Mieux vaut un mail de votre vcenter (5.0+) que d’un user en colère, non ?

Voici une illustration de notre cas :

Et voici le oneliner qui va créer une alarme pour chaque “instance” de carte réseau existante de votre vCenter (yellow >1 ; red > 5 ; mailto:admin@vmware.local) :

foreach ($vnic in (Get-View -ViewType VirtualMachine|%{$_.Config.Hardware.Device|?{$_.DeviceInfo.label -match "Network adapter"}}|select Key -Unique|%{$_.Key})){if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -like "Virtual Machine dropped network packets (instance $vnic)"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Virtual Machine dropped network packets (instance $vnic)";Description = "Custom alarm to monitor dropped network packets (instance $vnic)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedTx"}).key;Instance = $vnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "VirtualMachine"});(New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedRx"}).key;Instance = $vnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "VirtualMachine"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} has dropped network packets ({newStatus} state)";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}}

Vous devez réexecuter ce script si vous créez une nouvelle vm dans votre vCenter (5.0+) qui possède plus de cartes réseau virtuelles que celle qui en possédait le plus lors de la précédente exécution. Chaque alarme sera identifiée par l’instance qui lui est affectée :

Pour vCenter 4.x+, voici le même script pour les vmnics des ESX :

foreach ($vmnic in (Get-View -ViewType HostSystem|%{$_.Config.Network.Pnic|%{$_.Device}}|Select-Object -Unique)){if (!((Get-View AlarmManager).GetAlarm((Get-Folder -NoRecursion |Get-View).MoRef)|?{(get-view $_).info.name -like "Host dropped network packets (instance $vmnic)"})){(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host dropped network packets (instance $vmnic)";Description = "Custom alarm to monitor Host dropped network packets (instance $vmnic)";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedTx"}).key;Instance = $vmnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "HostSystem"});(New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "net"}|?{$_.RollupType -match "summation"}|?{$_.NameInfo.key -match "droppedRx"}).key;Instance = $vmnic});Operator = "isAbove";Yellow = "1";YellowInterval = "300";Red = "5";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} has dropped network packets ({newStatus} state)";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $false}))})});ActionFrequency = "1800"}))}}

Sachez aussi qu’historiquement statiques, les pourcentages équivalent aux différents states sont “dynamique” depuis ESX 5 et VMware recommande de tuner le paramètre minFreePct sur ESX 4.1 au dessus de 64Go de ram (nous, on vous recommande 3% à partir de 32Go).

Le compteur n’est pas accessible pour faire une alarme dans le vcenter donc nous avons fait chauffer le PowerCLI pour vous en faire une belle qui brille dans la nuit et qui vous alerte dès que le compteur passe à 1 (=1 : warning, >1 : alert) :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host memory state";Description = "Custom alarm to monitor Host memory state high-soft-hard-low";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "mem"}|?{$_.nameinfo.key -match "state"}|?{$_.RollupType -match "latest"}).key;Instance = ""});Operator = "isAbove";Yellow = "1";YellowInterval = "20";Red = "2";RedInterval = "20";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} memory state is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

MAJ 19/04/2012 : Modification du script pour afficher nom du server et le status dans l’objet du mail

Le coup du PCPU Used vs PCPU Util c’est un classique de Krishna Raj (grand maître d’esxtop) aux VMworld pendant la session “esxtop for advanced users”. Il s’agit d’une situation où la consommation cpu “théorique” (basé sur la fréquence de base du cpu) est différente de la consommation ”réelle” (basée sur la fréquence courante du cpu). Les exemples de troubleshooting des sessions de Krishna sont lié à l’Hyperthreading et aux mécanismes qui permettent aux cpu de baisser leur fréquence pour économiser de l’énergie.

En fervents adeptes d’esxtop, nous avons tout de suite remarqué l’anomalie décrite par Krishna lors d’une séance de troubleshooting :

Le problème c’est que nous n’étions pas dans esxtop pour ça et, pire, aucune alarme ne nous était parvenue. Et pour cause, c’est le compteur “usage” qui est utilisé par vCenter et non pas “coreUtilization” :

Après investigation, il s’agissait d’une mauvaise configuration ACPI/C-State dans le BIOS et comme nous ne sommes pas infaillibles, nous nous avons pondu un petit oneliner PowerCLI pour créer une alarme qui se base sur le compteur coreUtilization :

(Get-View AlarmManager).CreateAlarm((Get-Folder -NoRecursion |Get-View).MoRef,(New-Object VMware.Vim.AlarmSpec -Property @{Name = "Host core usage";Description = "Custom alarm to monitor core Utilization";Enabled = $true;expression = (New-Object VMware.Vim.OrAlarmExpression -Property @{expression = @((New-Object VMware.Vim.MetricAlarmExpression -Property @{Metric = (New-Object VMware.Vim.PerfMetricId -Property @{CounterId = ((Get-View (Get-View ServiceINstance).Content.PerfManager).PerfCounter|?{$_.groupinfo.key -match "cpu"}|?{$_.nameinfo.key -match "coreUtilization"}|?{$_.RollupType -match "average"}).key;Instance = ""});Operator = "isAbove";Yellow = "7500";YellowInterval = "300";Red = "9000";RedInterval = "180";Type = "HostSystem"}))});Action=(New-Object VMware.Vim.GroupAlarmAction -Property @{Action= (New-Object VMware.Vim.AlarmTriggeringAction -Property @{Action = (New-Object VMware.Vim.SendEmailAction -Property @{ToList = "admin@vmware.local";Subject = "[vAlarm] {targetName} core usage is {newStatus}";CcList = "";Body = ""});TransitionSpecs = @((New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "green";FinalState = "yellow";Repeats = $false});(New-Object VMware.Vim.AlarmTriggeringActionTransitionSpec -Property @{StartState = "yellow";FinalState = "red";Repeats = $true}))})});ActionFrequency = "1800"}))

Les seuils sont les mêmes que pour l’alarme “Host CPU Usage”, à savoir 75/90, mais nous avons réduit le temps pour l’alerte (red) à 3min au lieu de 5.

Pour une raison obscure mais bien réelle, l’alarme “Virtual machine total disk latency” n’est pas fonctionnelle :

The default Virtual Center Alarm for Virtual Machine Total Disk Latency is currently not functioning on VMware vCenter Server 4.0 and VMware vCenter Server 4.1.

There is no workaround at this time.

Grâce au PowerCLI (et aux nombreux posts de Luc), il existe une alternative : le compteur disk.maxTotalLatency.latest

Highest latency value across all disks used by the host. Latency measures the time taken to process a SCSI command issued by the guest OS to the virtual machine. The kernel latency is the time VMkernel takes to process an IO request. The device latency is the time it takes the hardware to handle the request.

Nous avons créé un petit script pour l’occasion qui créer une alarme “custom” afin de détecter une latence trop élevé sur l’un des datastore (en mode block uniquement, par pour le NFS donc) d’un ESX :

Ce script s’utilise comme suit :

.\Set-MaxTotalLatencyAlarm.ps1 -YellowTresh 20 -RedTresh 40

YellowTresh et RedTresh représentent les seuils Warning/Alert de l’alarme (30/50 par défaut si non renseignés à la création de l’alarme).

Il sera nécessaire de supprimer/recréer l’alarme pour changer ces valeurs

Après c’est à vous de jouer pour trouver le datastore qui pose problème…

download