Raccourcis clavier (mac) dans une session à distance de type windows

Dans ce billet (qui va nous servir de post-it 😉 ) nous allons énumérer les principaux raccourcis clavier Mac (certains de ces raccourcis sont compatibles sur clavier windows) au sein d’une session à distance sur un os de type windows.

Commande	Raccourci clavier
ctrl-alt-del	ctrl + +
Imprimer	ctrl + p
Affichage du menu démarrer	⌘
Afficher l’explorateur	⌘ + e
Démarrer-Exécuter	⌘ + r
Verrouiller la session	⌘ + l
Basculer la langue sur le clavier	ctrl + maj
Copier	ctrl + c
Couper	ctrl + x
Coller	ctrl +v
Tout sélectionner	ctrl + a
Annuler	ctrl + z
Rétablir	ctrl + y
Ouvrir une nouvelle fenêtre	ou ctrl + n
Actualisé	fn + F5 (ou ctrl + r)
Réduire toute les fenêtres	⌘ + d
Passer d’une fenêtre à une autre	+ tab
zoomer/dé-zoomer	ctrl + roulette souris
Touche F1 à F12	fn + touche F1 etc…
symbole {	+ (
symbole }	+ )
symbole [	ctrl + + (
symbole ]	ctrl + + )
symbole \	ctrl + + !
symbole \|	ctrl + + §

Console Horizon : Incorrect credentials were entered

Cela faisait longtemps qu’on n’avait pas rencontré le fameux “bug ou feature”. C’est chose faite avec cette erreur rencontrée sur la Console Horizon VIEW (VMware Horizon 2111.1) que nous a partagé un de nos collègues sysadmin. Lorsque nous essayons de nous authentifier sur la console Horizon VIEW, juste après le timeout de session de la Console, nous obtenons systématiquement l’erreur :

Incorrect credentials were entered

*Afin de by-passer cette erreur un refresh de la page d’authentification suffit 😉*

En regardant dans les logs du Connection Server (C:\ProgramData\VMware\VDM\logs\debug-yyyy-mm-dd-xxxxxx.txt) on observe plusieurs erreurs de type “[RestApiAuthFilter] Authentication failed” :

<ajp-nio-127.0.0.1-8009-exec-4> [RestApiAuthFilter] Authentication failed, Unexpected fault: encrypt: Cannot decrypt: Key not supplied

On comprend que le call de l’API “RestApiAuthFilter” est à l’origine de notre erreur d’authentification et que ce dernier n’a pas de ticket valide pour exécuter la requête (c’est pour cela que le refresh de la page d’authentification permet de résoudre le problème).

Allez dans le *Menu Settings- Global Settings et cliquez sur le bouton modify afin de pouvoir modifier le time-out de session API*

Une fois la modification enregistrée, cette dernière est prise en compte immédiatement. Le problème d’authentification après le timeout de session de console n’apparait plus (sauf au delà du timeout de session API 🙂 ).

Comme nous sommes curieux, nous avons testé cette feature avec la version VMware Horizon 2212.

*Y a du mieux avec la 2212, désormais on nous demande de refresh la page 🙂*

Après “quelques” échanges (qui ont duré quatre semaines) avec le support VMware la réponse finale tombe (et honnêtement on ne l’avait pas vu) “RTFM” : https://docs.vmware.com/en/VMware-Horizon/8-2111.1/rn/vmware-horizon-8-21111-release-notes/index.html

2852439: When administrators try to access the Horizon console without closing the browser or opening a new session in another tab or reloading the page after leaving the interface idle on the Login Page for an extended period of time (longer than the value for Global Settings Timeout), they are not able to login even with correct credentials.

Workaround: Open a new session in another tab or reload the login page.

Vous avouerez cette feature est vraiment super sympa 🙂 .

Horizon VIEW 2212 : Impossible de charger les domains sur la console d’administration

Sur une infra Horizon VIEW 2212 fraîchement installée, nous avons rencontré l’erreur ci-dessous, sur la page d’authentification de la console d’administration.

Page failed to load. Please refresh the browser to reload the page.

Outre l’erreur nous n’avons plus de Domains, sûrement une Feature 🙂

L’erreur se produit en utilisant l’IP ou un alias DNS du Connection Serveur, dans l’url de la page de la console d’administration Horizon VIEW (en localhost ou via le nom DNS du Connection Server le problème ne se posait pas).

Au départ, on pensait à un problème d’Origin checking qu’on avait déjà traité dans le billet Horizon 7.10 error : warning Echec de la connexion, au final le problème venait du CORS (Cross-Origin Ressource Sharing), même si dans notre cas nous ne sommes pas derrière un LB, le problème reste identique 🙂 . Comme VMware fait bien les choses, la KB85801 permet de résoudre facilement cette erreur via la modification (et ou la création) du fichier “locked.properties” (situé dans c:\program files\vmware\VMware View\Server\sslgateway\conf\).

Rajoutez “portalHost=” avec l’entrée qui vous intéresse (dans notre cas l’IP du Connection Serveur), puis redémarrez le service “Composant VMware Horizon View Security Gateway”

Playbook Ansible : renouveler le certificat aut0-signé d’une Cisco IMC

Depuis un certain temps, nous rencontrons des “problèmes” d’expiration de certificat (auto-signé) de CIMC sur des C220 M4. Renouveler le certificat auto-signé d’une CIMC est très simple, vous pouvez le faire via la GUI de la CIMC, en CLI ou via le Playbook que nous venons de mettre en place. L’avantage du Playbook est qu’il va récupérer les informations de l’ancien certificat afin de les reporter sur le nouveau certificat, puis il va afficher les informations du nouveau certificat afin de s’assurer que le nouveau certificat a bien une nouvelle date d’expiration, et bien sûr c’est plus rapide et on peut se faire une petite boucle histoire de le faire sur plusieurs CIMC 😉 .

Juste avant Noël, donc on peut légitiment espérer un vrai certificat sous le sapin pour le 25 au matin 🙂

- hosts: localhost
  
  tasks:      
    
    # Read current certificate
    - name: Read Current Certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveDn  inHierarchical="false" dn="sys/cert-mgmt/curr-cert">
          </configResolveDn>
      retries: 10
      delay: 5
      register: current_certif
      until: current_certif is not failed

    - debug:
        msg: "{{ current_certif }}"

    - name: create variables from current_certif
      set_fact:
        var_commonName: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName }}"
        var_countryCode: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.countryCode }}"
        var_organization: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organization }}"
        var_organizationalUnit: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organizationalUnit }}"
        var_locality: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.locality }}"
        var_state: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.state }}"
        var_validFrom: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validFrom }}"
        var_validTo: "{{ current_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validTo }}"
        var_signatureAlgorithm: "SHA384"
        var_selfSigned: "yes"

    - debug:
        msg: 
          - "{{ var_commonName }}"
          - "{{ var_countryCode }}"
          - "{{ var_organization }}"
          - "{{ var_organizationalUnit }}"
          - "{{ var_locality }}"
          - "{{ var_state }}"
          - "{{ var_validFrom }}"
          - "{{ var_validTo }}"


     # Generate selfSigned Certificate
    - name: Generate selfSigned Certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        timeout: 180
        content: |
            <configConfMo dn="sys/cert-mgmt/gen-csr-req" inHierarchical="false">
            <inConfig>
            <generateCertificateSigningRequest commonName="{{ var_commonName }}" 
              organization="{{ var_organization }}" 
              organizationalUnit="{{ var_organizationalUnit }}" locality="{{ var_locality }}" 
              state="{{ var_state }}" countryCode="United States" 
              dn="sys/cert-mgmt/gen-csr-req" selfSigned="yes"/>
            </inConfig>
            </configConfMo>
      retries: 10
      delay: 5
      register: generate_certif
      until: generate_certif is not failed


    # Read the new certificate
    - name: Read the new certificate
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveDn  inHierarchical="false" dn="sys/cert-mgmt/curr-cert">
          </configResolveDn>
      retries: 30
      delay: 5
      register: new_certif
      until: (new_certif is not failed) and (new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName == var_commonName)

    - debug:
        msg: "{{ new_certif }}"

    - name: create variables for new_certif
      set_fact:
        var_commonName: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.commonName }}"
        var_countryCode: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.countryCode }}"
        var_organization: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organization }}"
        var_organizationalUnit: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.organizationalUnit }}"
        var_locality: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.locality }}"
        var_state: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.state }}"
        var_validFrom: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validFrom }}"
        var_validTo: "{{ new_certif.configResolveDn.children[0].outConfig.children[0].currentCertificate.attributes.validTo }}"

    - debug:
        msg: 
          - "{{ var_commonName }}"
          - "{{ var_countryCode }}"
          - "{{ var_organization }}"
          - "{{ var_organizationalUnit }}"
          - "{{ var_locality }}"
          - "{{ var_state }}"
          - "{{ var_validFrom }}"
          - "{{ var_validTo }}"

Une fois le Playbook passé la CIMC a un nouveau certificat auto-signé avec les anciennes valeurs.

Playbook Ansible : paramétrer l’état des disques dans une CIMC

Dans ce Playbook nous allons configurer l’état des disques d’un serveur CISCO M5 en “Unconfigured-good” (via une CIMC), afin de les préparer pour la création d’un Virtual Drive (voir notre précedent billet “Playbook Ansible : créer un Virtual Drive dans une CIMC“).

Les tasks du Playbook :

Check Power Status : récupère l’état du serveur (on/off ) envoie le résultat dans la variable “SrvPwStatus“, si le serveur est “power off” alors le playbook s’arrête.
Check IMC uri : vérifie que l’url de la CIMC du serveur répond bien via un retour HTTP 200, si ce n’est pas le cas le Playblook s’arrête.
Search Status and ID storageLocalDisk 0 and 1 : récupère le status des disques (JBOD/unconfigured-good) ainsi que l’ID de chaque disques. Le status des disques est envoyé dans les variables SearchStatusDisk0/SearchStatusDisk1, l’ID des disques est envoyé dans les variables SearchIdDisk0/SearchIdDisk0
Search dn Storage Controller: permet de récupérer le dn du Storage Controller . Cette task est exécuté si un des disques à sa variable SearchStatusDisk0/SearchStatusDisk1 égal la variable StatusDiskJbod (“JBOD”)
Configure Disk 0 : Configure le disk0 en “make-unconfigured-good“
uniquement si la variable SearchStatusDisk0 est égale à StatusDiskJbod (“JBOD”)
Configure Disk 1 : Configure le disk1 en “make-unconfigured-good“
uniquement si la variable SearchStatusDisk1 est égale à StatusDiskJbod (“JBOD”)

hosts: localhost

  vars:
    imc_hostname: 100.83.36.141
    imc_password: 
    imc_username: admin
    StatusDiskJbod: JBOD
    StatusDiskUnconfGood: unconfigured-good
    

  tasks:

    - name: Check Power Status
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="false" classId="computeRackUnit"/>      
      register: CIMCPower
    - set_fact:
        SrvPwStatus: "{{ CIMCPower.configResolveClass.children[0].outConfigs.children[0].computeRackUnit.attributes.operPower }} "
    - debug:
        msg: "{{ SrvPwStatus }}"
      failed_when: '"on" not in SrvPwStatus'


    - name: Check IMC uri
      uri:
        url: https://{{ imc_hostname }}
        validate_certs: no
        status_code: 200
      register: result
    - debug:
        msg: "{{result}}"
      failed_when: result.status != 200
        

    - name: Search Status and ID storageLocalDisk 0 and 1
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="true" classId="storageLocalDisk"/>
      register: storageLocalDisk
    - set_fact:
        SearchStatusDisk0: "{{ storageLocalDisk.configResolveClass.children[0].outConfigs.children[0].storageLocalDisk.attributes.pdState }}"
        SearchStatusDisk1: "{{ storageLocalDisk.configResolveClass.children[0].outConfigs.children[1].storageLocalDisk.attributes.pdState }}"
        SearchIdDisk0: "{{ 'pd-' + storageLocalDisk.configResolveClass.children[0].outConfigs.children[0].storageLocalDisk.attributes.id }}"
        SearchIdDisk1: "{{ 'pd-' + storageLocalDisk.configResolveClass.children[0].outConfigs.children[1].storageLocalDisk.attributes.id }}"
    - debug:
        msg: 
          - "{{ SearchStatusDisk0 }}"
          - "{{ SearchStatusDisk1 }}"
          - "{{ SearchIdDisk0 }}"
          - "{{ SearchIdDisk1 }}"


    - name: Search dn Storage Controller
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="true" classId="storageController"/>
      register: StorageController
      when: SearchStatusDisk0 == StatusDiskJbod  or SearchStatusDisk1 == StatusDiskJbod
    - set_fact:
        SearchDnRaid: "{{ StorageController.configResolveClass.children[0].outConfigs.children[0].storageController.attributes.dn }}"
      when: SearchStatusDisk0 == StatusDiskJbod or SearchStatusDisk1 == StatusDiskJbod
    - debug:
        msg: "{{ SearchDnRaid }}"
      when: SearchStatusDisk0 == StatusDiskJbod or SearchStatusDisk1 == StatusDiskJbod


    - name: Configure Disk 0
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configConfMo dn='{{SearchDnRaid}}/{{ SearchIdDisk0 }}'>
          <inConfig>
          <storageLocalDisk adminAction='make-{{StatusDiskUnconfGood}}'></storageLocalDisk>
          </inConfig>
          </configConfMo>
      retries: 3
      delay: 1
      when: SearchStatusDisk0 == StatusDiskJbod

    - name: Configure Disk 1
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configConfMo dn='{{SearchDnRaid}}/{{ SearchIdDisk1 }}'>
          <inConfig>
          <storageLocalDisk adminAction='make-{{StatusDiskUnconfGood}}'></storageLocalDisk>
          </inConfig>
          </configConfMo>
      retries: 3
      when: SearchStatusDisk1 == StatusDiskJbod

Dans la CIMC nous avons quatre disques configurés en JBOD

Il ne reste plus qu’à lancer le Playbook pour configurer les deux premiers disques en “unconfigured-good”.

La task **Check Power Status** a bien vu le server “on”, le Playbook passe donc à la task suivante (dans le cas contraire le Playbook s’arrête)

La task **Check IMC uri** récupère un “status 200”, le Playbook passe donc aux tasks qui configurent les disques (dans le cas contraire le Playbook s’arrête)

Nos deux disques sont désormais configurés en “Unconfigured-good”

Playbook Ansible : créer un Virtual Drive dans une CIMC

Suite à un projet d’automatisation de déploiement de serveurs CISCO nous allons essayer de vous faire partager au fil du temps des Playbooks Ansible (essentiellement sur la partie CIMC dans un premier temps). Le playbook du jour permet la création d’un virtual drive dans une CIMC d’un serveur CISCO C220 M5 .

- hosts: localhost


  vars:
    imc_hostname: ""
    imc_password: ""
    imc_username: "admin"

  tasks:

    - name: Search Disk Size
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="true" classId="storageLocalDisk"/>
      register: CIMC
    - set_fact:
        ddsize: "{{ CIMC.configResolveClass.children[0].outConfigs.children[0].storageLocalDisk.attributes.coercedSize }}"
    - debug:
        msg: "{{ ddsize }}"

    
    - name: Search dn Storage Controller
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configResolveClass inHierarchical="true" classId="storageController"/>
      register: StorageController
    - set_fact:
        SearchDnRaid: "{{ StorageController.configResolveClass.children[0].outConfigs.children[0].storageController.attributes.dn }}"
    - debug:
        msg: "{{ SearchDnRaid }}"

    
    - name: Create Virtual Drive
      community.general.imc_rest:
        hostname: '{{ imc_hostname }}'
        username: '{{ imc_username }}'
        password: '{{ imc_password }}'
        validate_certs: no
        content: |
          <configConfMo dn='{{SearchDnRaid}}/virtual-drive-create'> 
          <inConfig> 
          <storageVirtualDriveCreatorUsingUnusedPhysicalDrive virtualDriveName='vdTest' raidLevel='1' size="{{ddsize}}" driveGroup='[1,2]' writePolicy='Write Through' adminState='trigger'/>
          </inConfig>
          </configConfMo>

Dans la task “Search Disk Size” on récupère la taille du premier disque qui nous servira à la création du RAID dans la task “Create Virtual Drive”. La task “Search dn Storage Controller” permet de récupérer le dn du Controller afin de pouvoir la récupérer dans la task “Create Virtual Drive” (si vous avez des Controller différents notamment)

dans le Playbook on voit bien la taille des disques remontés et le dn qui seront utiles pour la création du Virtual Drive

Le Virtual Drive est bien créé une fois le Playbook terminé

Quelques lien sur les APi (REST/XML) CISCO IMC :

VMmark 3.1.1 erreur lors du lancement de notre premier “Tile”

Dernièrement nous avons testé VMmark 3.1.1 (pour rappel VMmark permet de bencher et mesurer l‘évolution des plates-formes virtuelles) afin de bencher des serveurs DELL (PowerEdge R7515). On vous passe les étapes douloureuses (nous ferons un billet sur l’installation de VMmark 3.1.1 très prochainement) de l’installation et la configuration. Une fois l’installation terminée on lance notre premier Tile et là une belle erreur (ce n’est pas comme si c’était la première en plus…) mais celle-là aurait pu être évitée (genre RTFM) : “Error : machine = client0: Invalid Trust Level (3).

La seule info qui nous intéresse dans le message d’erreur est “Client0”, comme tout bon Sysadmin on fait un ping de notre fameux “Client0”, comme nous n’avons pas de retour, direction le vCenter.

Sans IP elle ne risque pas de répondre notre CLIENT0 🙂

En allant plus loin on constate que l’IP du CLIENT0 (192.168.1.2) a été attribué à la VM DeployVM0 (le conflit d’IP explique notre message d’erreur). Direction le fichier VMmark3.properties (situé dans /root/VMmark3 de la VM “PrimeClient”) afin de voir si on n’a pas un problème de configuration sur la VM “Client0” ou DeployVM0. Après une recherche dans le fichier VMmark3.properties on comprend d’où vient le problème, le deploy/DeployVMinfo est égal à DeployVM0:192.168.2 soit l’IP de de notre VM “CLIENT0”.

Il ne reste plus qu’à mettre la bonne IP

Quand on lit le commentaire “Specifies the name and IP address of the deployed VMs. Ex DeployVM0:192.168.1.245,DeployVM1:192.168.1.246” on se dit qu’on a raté quelques chose 🙂 .

Une fois l’IP de la VM “DeployVM0” passer sur 192.168.1.245 notre Tile est passé sans encombre

ESXi : Host TPM attestation alarm

Sur plusieurs hosts PowerEdge R7515 nous avons constaté après l’installation d’ESXi 7.0.2 (17867351) une erreur TPM sur un de nos vCenter de test (notre fameux POC VCF) :

Host TPM attestation alarm

L’erreur se produisant uniquement sur des PowerEdge R7515 il semblerait que nous ayons oublié de paramétrer correctement la partie TPM dans la config de nos serveurs DELL 🙂 . Direction l’ IDRAC pour vérifier ça.

Aller dans le BIOS (F2)
BIOS Settings-System Security

Dans un premier temps on fait un clear avant de paramétrer la suite

Cliquer sur Clear (confirmer en cliquant sur le bouton Ok lors de l’affichage du popup).
Cliquer sur TPM Advanced Setting.

Cliquez sur **SHA256** (voilà pourquoi on avait l’erreur)

Cliquer sur Reset To Green (et dans notre cas on pourra relancer l’upgrade de ce Workload Domain dans VCF 🙂 )

VCF : Premier BriengUp

Dans le cadre d’un POC VCF 4.3.0 (VMware Cloud Foundation) nous avons rencontré une erreur (ou plutôt nous avons retenu celle-là 🙂 ) lors de l’installation du Cloud Builder. Lors de l’étape “Validate Configuration” tout se passait bien jusqu’à l’apparition d’un Failed associé à l’erreur “Error connecting to ESXi host xxxx. SSL certificate common name doesn’t match ESXi FQDN” sur les quatre host de notre POC.

C’est sur que si le Cloud Builder ne peut pas se connecter aux ESXi ça va être dur pour la suite 🙂

Le message d’erreur “Error connecting to ESXi host xxxx. SSL certificate common name doesn’t match ESXi FQDN” est explicite, le certificat par défaut des ESXi ne convient pas au Cloud Builder pour se connecter aux ESXi, du coup impossible pour Cloud Builder d’aller plus loin. En relisant les pré-requis on s’aperçoit que depuis la version 4.2 de VCF, il faut que le certificat de l’ESXi soit au format host.FQDN (et corresponde bien sûr à ce qui est rentré dans votre fichier de configuration Cloud Builder).

Comme indiqué par VMware les étapes pour régénérer le certificat sont très simples :

Connectez-vous en SSH sur chaque hôte ESXi.
Lancez la commande “esxcli system hostname get” et vérifiez que Host est bien au format Host.FQDN dans la section “Fully Qualified Domain Name: “, si c’est bien le cas passez directement à l’étape 6.
Lancez la commande “vi etc/hosts” puis ajouter votre Host.FQDN et enregistrer (touche “echap” puis “:wq!”.
Lancez la commande “esxcfg-advcfg -s Host_FQDN /Misc/hostname” (remplacer Host_FQDN par le nom de votre host et son FQDN).
Lancez la commande “reboot”
Lancez la commande “/sbin/generate-certificates“puis validez
Lancez la commande “/etc/init.d/hostd restart && /etc/init.d/vpxa restart“

Il ne vous reste qu’à faire un “retry” dans le Cloud Builder 😉 .

Et voilà 🙂 la suite dans un prochain billet (on vous promet c’est fun)

IMC Supervisor : déploiement firmware impossible

Déployer un firmware via IMC Surpervisor est très simple encore faut-il que cela fonctionne, et c’est toujours quand on n’a pas le temps que cela se complique 🙂 . Sur Une IMC Supervisor (ver : 2.2.0.0) nous devions déployer un firmware sur un Serveur Cisco M5, mais le menu “Firmware Upgrade” en avait décidé autrement. En effet lorsque l’onglet “Firmware Upgrade” s’affichait, la liste des serveurs (tout du moins le bouton +) ne s’affichait pas, seule une barre de progression qui tournait sans fin nous tenait compagnie.

Sur la page Rack Groups, onglet “Rack Servers” on remarque une ligne avec des éléments manquants (seule le Last Inventory Update) apparaît.

Avec l’information “Last Inventory Update” nous allons regarder dans la page Physical Account (onglet “Racks Accounts”) si nous trouvons quelque chose.

Bingo on retrouve notre serveur, cette fois avec toutes ses informations

Nous avons supprimé ce serveur afin de vérifier que c’était bien la cause de notre problème (dans le menu “Firmware Upgrade”), puis nous sommes allés tester le menu “Firmware Upgrade”.