Playbook Ansible : ajouter un “Uplink profile” dans NSX-T

Dans NSX-T l’ajout d’un “Uplink Profil” est on ne peut plus simple via la GUI (quand celle-ci rĂ©pond correctement 🙂 ), de notre cĂŽtĂ© on prĂ©fĂšre (et de loin…) passer par les REST APIs, ces derniĂšres sont plus sures et plus rapides surtout si on souhaite automatiser certaine actions. 

Vous l’avez remarquer on est dans un labs from scatch 🙂

Le playbook ci-dessous permet de créer un Uplink Profile, sans tag, avec un vlan en 102 et une mtu en 1600 dans un manager NSX-T (version 3.2.3.1.0).

Dans le playbook nous rĂ©cupĂ©rons le nom et l’id du “Profile Uplink” afin de pouvoir les rĂ©utiliser plus tard si par exemple vous souhaitez aller plus loin dans vos actions (ajout d’un “Transport Node Profile par exemple etc…). Vous remarquerez que nous avons mis un block et un rescue afin de gĂ©rer proprement d’Ă©ventuelle(s) erreur(s),  si vous le souhaitez vous pouvez ajouter  des actions dans la partie rescue (comme une gestion de log par exemple 😉 ).

- hosts: localhost


  vars:
      nsx_manager: "Your_NSX-T-MANAGER"
      nsx_username: "admin"
      nsx_password: "PWD_admin"
      uplinkProfil_name: "Uplink_Profil01"
      mtuvar: "1600"
      vlanvar: "102"
  
          
  tasks:

    - name: Create a Uplink Profile
      block:
        - name: Create a Hostswitch Profile on NSX manager
          uri:
            url: "https://{{ nsx_manager }}/api/v1/host-switch-profiles"
            force_basic_auth: yes
            validate_certs: no
            headers:
              Accept: "application/json"
              Content-Type: "application/json"
            user: "{{ nsx_username }}"
            password: "{{ nsx_password }}"
            method: POST
            body: | 
              {
              "resource_type": "UplinkHostSwitchProfile",
              "display_name": "{{uplinkProfil_name}}",
              "mtu": "{{mtuvar}}",
              "teaming": {
                  "standby_list": [
                    {
                        "uplink_name": "uplink-2",
                        "uplink_type": "PNIC"
                    }
                  ],
                  "active_list": [
                    {
                        "uplink_name": "uplink-1",
                        "uplink_type": "PNIC"
                    }
                  ],
                  "policy": "FAILOVER_ORDER"
                },
                "transport_vlan": "{{vlanvar}}"
              }
            status_code: "201"
            body_format: json
          register: nsx_hostswitch


        - name: Display ID "Create a Hostswitch Profile"
          debug:
            msg: 
              - "display_name : {{ nsx_hostswitch.json.display_name }}"
              - "ID : {{ nsx_hostswitch.json.id }}"

          when: nsx_hostswitch.json.id is defined

      rescue:
        - name: Display error
          debug:
            msg: "Uplink Profile on {{ nsx_manager }} is not created"
Une fois le playblook terminĂ©, il nous reste plus qu’Ă  vĂ©rifier ce que ça donne dans notre Manager
Nous avons bien notre nouveau “Uplink Profile”

Post to Twitter

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. 

CommandeRaccourci clavier
ctrl-alt-delctrl + +
Imprimerctrl + p
Affichage du menu dĂ©marrer⌘
Afficher l’explorateur⌘ + e
DĂ©marrer-ExĂ©cuter⌘ + r
Verrouiller la session⌘ + l
Basculer la langue sur le clavierctrl + maj
Copierctrl + c
Couperctrl + x
Collerctrl +v
Tout sélectionnerctrl + a
Annulerctrl + z
RĂ©tablirctrl + y
Ouvrir une nouvelle fenĂȘtreou 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é-zoomerctrl + roulette souris
Touche F1 Ă  F12fn + touche F1 etc…
symbole { + (
symbole } + )
symbole [ctrl + + (
symbole ]ctrl + + )
symbole \ctrl + + !
symbole |ctrl + + §

Post to Twitter

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 🙂 .

Post to Twitter

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”
On retrouve bien nos Domains 😉

Post to Twitter

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.

On est reparti pour 5 ans 🙂

Post to Twitter

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”
    C’est tout bon cĂŽtĂ© CIMC

    Post to Twitter

    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)

    Notre CIMC sans Virtual Drive
    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  :

    Post to Twitter

    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).

    Ca commence pas bien notre affaire 🙂

    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

    Post to Twitter

    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
    1. Cliquer sur  Clear (confirmer en cliquant sur le bouton Ok  lors de l’affichage du popup).
    2. Cliquer sur TPM Advanced Setting.
    Cliquez sur SHA256 (voilĂ  pourquoi on avait l’erreur)
    Cliquez sur le bouton Yes
    Cliquez sur bouton Ok
    Cliquez sur le bouton Back
    Cliquez sur le bouton Finish
    Cliquer sur le bouton Finish
    Cliquez sur le bouton Yes
    Cliquer sur Reset To Green (et dans notre cas on pourra relancer l’upgrade de ce Workload Domain dans VCF 🙂 )

    Post to Twitter

    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).

    RTFM 🙂 c’est ici

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

    1. Connectez-vous en SSH sur chaque hĂŽte ESXi.
    2. 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.
    3. Lancez la commande “vi etc/hosts” puis ajouter votre Host.FQDN et enregistrer (touche “echap” puis “:wq!”.
    4. Lancez la commande “esxcfg-advcfg -s Host_FQDN /Misc/hostname” (remplacer Host_FQDN par le nom de votre host et son FQDN).
    5. Lancez la commande “reboot” 
    6. Lancez la commande “/sbin/generate-certificates“puis validez
    7. 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)

      Post to Twitter