<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blog Beansy</title>
    <link>https://blog.blackbeans.ovh/</link>
    <description>Retours d&#39;expérience Infra - VMware, Proxmox, Monitoring, Réseau</description>
    <language>fr</language>
    <atom:link href="https://blog.blackbeans.ovh/" rel="self" type="application/rss+xml" />
    <item>
      <title>Déploiement automatisé d’une VM Windows sur VMware avec Ansible : DHCP vers IP statique</title>
      <link>https://blog.blackbeans.ovh/vmware/ansible_vmware_windows_deployment/</link>
      <pubDate>Thu, 16 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/vmware/ansible_vmware_windows_deployment/</guid>
      <description>Introduction La sauvegarde régulière des configurations réseau est une bonne pratique essentielle. Perdre la configuration d&amp;amp;rsquo;un switch peut entraîner des heures de reconfiguration manuelle.
Cet article décrit une architecture Ansible fiable pour :
déployer une VM Windows depuis un template VMware récupérer automatiquement son IP DHCP établir la connexion WinRM basculer vers une IP statique reconstruire l’inventaire poursuivre la configuration système Explication rapide du workflow Déploiement de la VM Récupération IP DHCP via VMware Tools Connexion WinRM initiale Bascule IP statique Reconstruction inventaire Reconnexion WinRM Configuration finale Prérequis 1 2 3 4 5 python3.11 -m venv venv source venv/bin/activate pip install ansible pyvmomi pywinrm requests-ntlm ansible-galaxy collection install community.vmware ansible-galaxy collection install ansible.windows Architecture du projet Arborescence recommandée :
</description>
    </item>
    <item>
      <title>PowerCLI — Audit automatisé d&amp;#39;un environnement VMware et export HTML</title>
      <link>https://blog.blackbeans.ovh/scripts/audit-vmware-powercli/</link>
      <pubDate>Sat, 11 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/scripts/audit-vmware-powercli/</guid>
      <description>Contexte Quand on reprend un environnement VMware existant ou qu&amp;amp;rsquo;on prépare une migration, la première question c&amp;amp;rsquo;est toujours : qu&amp;amp;rsquo;est-ce qu&amp;amp;rsquo;il y a vraiment sur ce vCenter ? Les consoles vSphere donnent des vues partielles, et construire l&amp;amp;rsquo;inventaire à la main sur 50&#43; VMs c&amp;amp;rsquo;est une perte de temps. Ce script PowerCLI génère un rapport HTML complet en une commande — snapshots qui traînent, datastores qui saturent, VMs sans VMware Tools, ressources CPU/RAM allouées vs utilisées.
</description>
    </item>
    <item>
      <title>Proxmox Backup Server — Intégration à Proxmox VE 8 et configuration des jobs de sauvegarde</title>
      <link>https://blog.blackbeans.ovh/proxmox/proxmox-pbs-integration/</link>
      <pubDate>Sat, 11 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/proxmox/proxmox-pbs-integration/</guid>
      <description>Contexte PBS est installé via l&amp;amp;rsquo;ISO officielle sur un serveur physique dédié — pas en surcouche Debian, pas en LXC. L&amp;amp;rsquo;OS sous-jacent est un Debian minimaliste géré exclusivement par PBS. On ne touche pas à l&amp;amp;rsquo;OS directement sauf pour le réseau et les disques.
Environnement cible :
Proxmox VE : 8.x — 192.168.1.10:8006 Proxmox Backup Server : ISO officielle — 192.168.1.20:8007 Stockage PBS : disque local dédié, séparé du disque système Si tu arrives ici depuis une IA ou un moteur de recherche avec le message &amp;amp;ldquo;cannot add storage pbs&amp;amp;rdquo;, &amp;amp;ldquo;fingerprint mismatch&amp;amp;rdquo; ou &amp;amp;ldquo;datastore not found&amp;amp;rdquo; — les sections 2, 3 et 4 sont pour toi.
</description>
    </item>
    <item>
      <title>Automatiser la sauvegarde des configurations switches avec Ansible</title>
      <link>https://blog.blackbeans.ovh/reseau/backup-switches-ansible/</link>
      <pubDate>Fri, 10 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/reseau/backup-switches-ansible/</guid>
      <description>Introduction La sauvegarde régulière des configurations réseau est une bonne pratique essentielle. Perdre la configuration d&amp;amp;rsquo;un switch peut entraîner des heures de reconfiguration manuelle. Dans cet article, nous allons mettre en place une solution complète et automatisée avec Ansible, systemd et un partage réseau Windows, pour sauvegarder les configurations de vos switches localement et à distance.
Prérequis Ansible installé sur le serveur Linux SSH activé sur les switches Un partage réseau Windows monté (optionnel, pour la sync distante) Les collections Ansible nécessaires selon vos équipements : dellemc.os6 arubanetworks.aoscx cisco.ios 1. Préparation de l&amp;amp;rsquo;environnement Créer le dossier de destination des sauvegardes :
</description>
    </item>
    <item>
      <title>Supervision d&amp;#39;une infrastructure avec Grafana et Prometheus : retour d&amp;#39;expérience terrain</title>
      <link>https://blog.blackbeans.ovh/monitoring/grafana-prometheus/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/monitoring/grafana-prometheus/</guid>
      <description>Contexte Dans un environnement de production (VMware, stockage SAN, services métiers), j&amp;amp;rsquo;avais besoin d&amp;amp;rsquo;une supervision centralisée, temps réel et flexible — sans dépendre d&amp;amp;rsquo;outils propriétaires coûteux. L&amp;amp;rsquo;objectif était de compléter ou remplacer partiellement des outils classiques comme Centreon par une stack moderne basée sur Prometheus (collecte métriques) et Grafana (visualisation).
Problème Les outils traditionnels présentaient plusieurs limites : visibilité réduite sur les métriques fines (CPU steal, IO wait), dashboards peu flexibles, difficulté à corréler infra et applicatif, et coût de licences élevé.
</description>
    </item>
    <item>
      <title>VM VMware bloquée au démarrage après rattachement d&amp;#39;un disque existant : diagnostic et résolution</title>
      <link>https://blog.blackbeans.ovh/vmware/vmware-disque-incident/</link>
      <pubDate>Wed, 01 Apr 2026 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/vmware/vmware-disque-incident/</guid>
      <description>Contexte Environnement de production VMware vSphere. Une nouvelle VM est créée et on lui rattache un disque virtuel provenant d&amp;amp;rsquo;une ancienne VM — pour récupérer des données ou réutiliser un volume existant. Suite à cette opération et à une extension de la taille du disque, la VM refuse de démarrer.
Symptômes Depuis vSphere Client, au démarrage de la VM :
La VM reste bloquée à l&amp;amp;rsquo;état &amp;amp;ldquo;Starting&amp;amp;rdquo; Erreur dans les événements vSphere : Cannot open the disk &amp;amp;#39;datastore/NouvelleVM/disque.vmdk&amp;amp;#39; or one of the snapshot disks it depends on. Reason: The parent virtual disk has been modified since the child was created. Impossible de monter le disque La VM ne démarre pas Cause racine Un disque VMware contient dans son descriptor .vmdk deux identifiants critiques :
</description>
    </item>
    <item>
      <title>Merci</title>
      <link>https://blog.blackbeans.ovh/contact-success/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/contact-success/</guid>
      <description>Merci 👍 Votre message a bien été envoyé.
Je vous répondrai dès que possible.
← Retour au blog
</description>
    </item>
    <item>
      <title>Recherche</title>
      <link>https://blog.blackbeans.ovh/search/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 &#43;0000</pubDate>
      <guid>https://blog.blackbeans.ovh/search/</guid>
      <description>search</description>
    </item>
  </channel>
</rss>
