Dans les informations demandées, il y avait du simple (driver, modèle de la carte, …) et du plus compliqué (version de firmware de chaque carte).

Une bonne partie des informations étaient disponibles en PowerCLI dans la partie Config.StorageDevice.HostBusAdapter d’un objet de type HostSystem :

Cependant, pour récupérer la version du firmware de la carte, ce fut plus tendu … Après pas mal de recherche (infructueuse) dans les objets et propriétés, on est tombé sur cette KB VMware : Identifying the firmware of a Qlogic or Emulex FC HBA et de la note en fin de page qui explique le pourquoi du comment :

Donc pour le coup, on a pas le choix, on est obligé de passer par SSH et récupérer les infos en commandes. Comme on ne voulait pas faire 2 scripts distincts, on a utilisé plink.exe (exécutable fournit avec puTTy qui permet d’exécuter des commandes à travers une session SSH en automatique) en l’appelant via le script PowerCLI.

Voici un exemple d’informations récupérées sur une carte EMULEX :

~ # head -9 /proc/scsi/lpfc820/7
Emulex LightPulse Fibre Channel SCSI driver 8.2.1.30.1-58vmw
IBM 42C2071 4Gb 2-Port PCIe FC HBA for System x on PCI bus 0000:1e device 00 irq 200 port 0
BoardNum: 0
Firmware Version: 2.82A3 (Z3F2.82A3)
Portname: XXX   Nodename: XXX

SLI Rev: 3
   NPIV Unsupported by Fabric
   RPIs max 512  RPIs used 1

Voici un exemple d’informations récupérées sur une carte QLOGIC :

~ # head -8 /proc/scsi/qla2xxx/9
QLogic PCI to Fibre Channel Host Adapter for QLE2460:
       FC Firmware version 5.02.00 (496), Driver version 831.k

Host Device Name vmhba5

BIOS version 1.28
FCODE version 1.24
EFI version 1.08

Voici donc un script PowerCLI qui va récupérer les informations suivantes :

• Host Name
• ESXi Product Version
• Hba Device
• Hba World Wide Name
• Hba Driver
• Hba Model
• Hba Firmware Version
• Hardware Model

Le script prend 4 paramètres :

• PlinkPath : Chemin vers l’exécutable plink.exe pour le lancement des commandes SSH
• Username : Nom de compte utilisé pour la connexion SSH
• Password : Mot de passe du compte utilisé pour la connexion SSH
• CSVPath : [OPTIONNEL] Chemin pour un export vers un fichier csv. Si ce paramètre n’est pas renseigné, le résultat sera affiché.

.\hba-infos.ps1 -PlinkPath 'C:\Program Files (x86)\PuTTY\plink.exe' -Username root -Password VMwareRox
.\hba-infos.ps1 -PlinkPath 'C:\Program Files (x86)\PuTTY\plink.exe' -Username root -Password VMwareRox -CSVPath C:\HBA-infos.csv

Click here to view the video on YouTube.

Si vous avez renseigné le paramètre CSVPath vous aurez un fichier csv qui sera facilement exploitable sous Excel :

Le problème vient juste du fait qu’il n’y a pas pour l’instant d’outil de synchronisation pour la partie vSphere. On a donc décider de faire le notre afin de nous faciliter la tâche (en PowerCLI bien sûr !).

Voici donc un script PowerCLI que vous pouvez utiliser pour générer 2 fichiers *.csv (un pour les serveurs Hosts ESXi et un pour les machines virtuelles), avec 2 paramètres :

• HostCSVFile : chemin d’accès pour le fichier csv d’export des hôtes
• VMCSVFile : chemin d’accès pour le fichier csv d’export des machines virtuelles

Les 2 paramètres sont indépendants, vous pouvez donc les utiliser unitairement (pour exporter uniquement les hôtes ESXi ou les machines virtuelles) ou ensemble (pour exporter les 2)

.\ESX4VRD.ps1 -HostCSVFile C:\Host.csv
.\ESX4VRD.ps1 -VMCSVFile C:\VM.csv
.\ESX4VRD.ps1 -HostCSVFile C:\Host.csv -VMCSVFile C:\VM.csv

Click here to view the video on YouTube.

Ensuite, il suffit d’importer les fichiers .csv dans visionApp pour retrouver la même arborescence que dans le vCenter :

La version finale est attendue pour le milieu de Mai, et ce brouillon est censé permettre à tout le monde de faire un premier retour sur son contenu :

This is the public draft of the vSphere 5.0 Security Hardening Guide.  It is being posted to this Community in order to provide early access to interested parties, and to gather feedback.  The final version will be made available approximately in the middle of May.

Si vous avez l’habitude de lire ces guides (très bonne source d’informations d’ailleurs, on vous conseille de parcourir les précédents si vous ne l’avez pas déjà fait), cette fois ce sera un fichier Excel avec 5 onglets (chacun renfermant les paramètres correspondants) plutôt qu’un traditionnel PDF :

1. Intro
2. VM
3. ESXi
4. Network
5. vCenter

Pour le coup, le passage au fichier Excel est assez pratique pour classer/trier, mais on regrette un peu le format PDF pour une bonne lecture sur l’iPad sur le canapé :p

En même temps, il y a eu un fichier de publié sur les différences entre les versions 4.1 et 5.0, toujours au format Excel afin de mieux voir ce qui a évolué (très pratique) :

Les 2 guides sont disponibles ici :

• vSphere 5.0 Hardening Guide – Public Draft
• vSphere Hardening Guide: 4.1 and 5.0 comparison – Rev B

Afin d’éviter que tous les tâches de vMotion ne partent en sucette, il peut peut être intéressant à un moment donné de désactiver l’équilibrage de charge automatique effectué par DRS.

Pour ce faire, un petit OneLiner en PowerCLI fera bien l’affaire :

$modifiedClusters = Get-Cluster | ?{ $_.DrsAutomationLevel -eq "FullyAutomated" } | Set-Cluster -DrsAutomationLevel PartiallyAutomated -Confirm:$false

Et si vous voulez remettre les paramètres des clusters modifiés en automatique :

$modifiedClusters | Set-Cluster -DrsAutomationLevel FullyAutomated -Confirm:$false

Pour le coup, cela me fait énormément plaisir, et je voulais vraiment remercier (entre autres) tous les lecteurs assidus du dude, John Troyer, Alex Maier et notre hypervisor national qui y est pour beaucoup !

Nous avons rencontré un problème lors du passage de cette mise à jour sur un homelab. En fait la mise à jour c’est déroulée sans problème, tout fonctionnait correctement, sauf qu’on a vu apparaître sur le serveur syslog une quantité de message d’information du serveur SQL :

On avoue être tombé dessus un peu par hasard vu que les message sont en INFO, mais bon … En vérifiant sur le serveur SQL directement dans les journaux d’évènements, on retrouve ces messages dans la partie Application Events :

Ce qui est assez bizarre, c’était que le service vCenter tournait déjà avec un compte de service Active Directory, et qu’ici le message d’erreur portait sur le nom du serveur DOMAIN\VC01$ …

En faisant quelques tests afin de comprendre mieux qui générait ces messages (merci au SQL Profiler d’ailleurs), on c’est rendu compte que c’était le service TOMCAT (service Windows : VMware VirtualCenter Management Webservices) qui était responsable de ces accès refusés.

Une fois identifié, on a pu mettre le service avec le même compte de service que celui qui faisait déjà tourner vCenter et après un redémarrage du service, plus aucun message d’erreur d’information :

Pour le coup, on est retourné dans la Release Note de l’update afin de voir si on trouvait une explication à ce changement, mais pour l’instant, rien …

http://www.veeam.com/veeam_backup_6_0_whats_new_wn.pdf

Backup proxy servers. A single Veeam backup server can now control multiple backup proxy servers
acting as data movers. Unlike a full-blown backup server, proxy servers do not require Microsoft SQL
Server and consist of just a few lightweight components that install in seconds. This wizard-driven
process allows for no-hassle scaling of your installation by leveraging your existing Windows servers.
v6’s new distributed architecture and “automated-everything” approach simplify deployment
and maintenance of ROBO and large installations of Veeam Backup & Replication.
Backup repositories. v6 introduces the concept of backup repositories (also known as media servers),
which decouple backup target settings from backup jobs and backup proxy servers. This new backup
infrastructure design enables jobs to be dynamically assigned to proxy servers based on availability
and workload.

Cette partie est accessible depuis la console :

Durant l’installation, Veeam va déclarer un proxy et un repository par défaut. Cependant, les paramètres utilisés ne peuvent pas forcement correspondre à ce que vous souhaitez (par exemple le repository par défaut pointe vers C:\backup) :

Le problème est que vous ne pouvez pas supprimer ce repository directement en GUI (si jamais vous êtes perfectionniste et que vous ne voulez plus voir quelque chose que vous n’utilisez pas).

Voici une méthode (en Powershell avec les modules Veeam chargés) qui permet de supprimer les proxy et repository par défaut créés lors de l’installation :

# Disable the default installation-created proxy
Disable-VBRViProxy -Proxy (Get-VBRViProxy -Name "VMware Backup Proxy")

# Delete the default installation-created repository
(Get-VBRBackupRepository -name "Default Backup Repository").Delete()

Bien sur cela n’est pas obligatoire et est purement « esthétique »

Ça faisait un moment que ça traînait, il me restait quelques réglages et customisation CSS a finir, mais voilà une chose de faite.

Le nouveau thème est HTML5, et CSS3, ce qui permet par exemple d’avoir un thème dit « mobile-first », à savoir que l’affichage du site s’adaptera à la résolution, donc sera adapté aux smartphone, tablette, etc…

Par exemple, le site vu depuis un iPhone et un iPad (sans aucun plugin, full CSS < moins lourd) :

Voilà, on espère que le nouveau thème vous plaira, il reste encore quelques derniers petits réglages à faire (passer le logo en vectoriel, 2-3 réglages CSS, …), mais bon, on s’approche du but :p

This plug-in style is deprecated. In the future, the C# API will not be used by VMware products

En se basant sur la documentation (documentation valable pour vSphere 4.1 et 5.0) pour les plugins pour vCenter disponible sur http://www.vmware.com/support/developer/vc-sdk/vcplugin/vSphere_Plugin_4_1_Technote.pdf , on a fait quelques tests afin de mieux cerner le fonctionnement de cette architecture.

Pour le principe, rien de plus simple, lorsqu’on accède à un plugin depuis le client vSphere, une URL lui est transmise avec tout plein de paramètres que l’on peut réutiliser dans le plugin, comme par exemple :

• sessionId = identifiant permettant de réutiliser le jeton de sécurité de l’utilisateur courant pour l’exécution d’action
• moref = permet d’identifier l’objet sélectionné lors de l’activation du plugin
• serviceUrl = accès aux WebServices du vCenter, typiquement https://serverFQDN/sdk

Pour notre exemple, on voulait juste afficher le contenu de toutes les variables transmises au plugin afin de voir ce que l’on pouvait faire lorsqu’on s’est rendu compte de quelque chose.

Voici juste le plugin de base utilisé pour l’exemple, il est composé du fichier de définition XML pour le client vSphere ainsi que d’un fichier ASP.NET et de son code C# :

<scriptConfiguration version="4.0">
	<key>vmdude</key>
	<description>vmdude Sample vSphere Client Plug-in</description>
	<name>vmdude Plug-in</name>
	<vendor>vmdude.fr</vendor>
	<multiVCsupported>false</multiVCsupported>
	<extension parent="InventoryView.VirtualMachine">
		<title locale="en">vmdude debug</title>
		<url display="window">http://localhost/index.aspx</url>
	</extension>
</scriptConfiguration>

Ce fichier xml doit être mis dans le dossier Plugins du viclient, typiquement dans

C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Plugins

La partie <extension parent= »InventoryView.VirtualMachine »> détermine l’endroit ou le plugin sera actif, ici ce sera un onglet supplémentaire lors de la sélection d’une VM :

Lors de l’activation du plugin, la page http://localhost/index.aspx sera appelée, celle-ci ne faisant qu’afficher les valeurs de certains paramètres :

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="index.aspx.cs" Inherits="vmdudedebug.index" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <script type="text/javascript">
        function refresh() {
            window.location.reload();
        }
    </script>
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <p>URL : <asp:label id="txt_URL" runat="server" /></p>
        <p>MoRef : <asp:label id="txt_moref" runat="server" /></p>
        <p>Type : <asp:label id="txt_type" runat="server" /></p>
        <p>Value : <asp:label id="txt_value" runat="server" /></p>
        <p>sessionId : <asp:label id="txt_sessionId" runat="server" /></p>
        <p>serverGuid : <asp:label id="txt_serverGuid" runat="server" /></p>
        <p>locale : <asp:label id="txt_locale" runat="server" /></p>
        <p>webServicesSessionId : <asp:label id="txt_wsSessionId" runat="server" /></p>
        <p>serviceUrl : <asp:label id="txt_serviceUrl" runat="server" /></p>
    </div>
    <button onclick='refresh();'>Refresh Da Page !</button>
    </form>
</body>
</html>

Et le code C# de cette page (qui ne fait que décomposer l’URL reçue et renseigner les différentes valeurs) :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace vmdudedebug
{
    public partial class index : System.Web.UI.Page
    {
        public static string MOREF = "moref";
        public static string SESSION_ID = "sessionId";
        public static string SERVER_GUID = "serverGuid";
        public static string SERVICE_URL = "serviceUrl";
        public static string LOCALE = "locale";
        public static string WS_SESSION_ID = "webServicesSessionId";
        public static char[] splitter = { ':' };

        protected void Page_Load(object sender, EventArgs e)
        {
            Uri SvcURL = new Uri(Request.Url.ToString());
            string MoRefArg = HttpUtility.ParseQueryString(SvcURL.Query).Get(MOREF);
            string typeMoRef = MoRefArg.Split(splitter)[0];
            string valueMoRef = MoRefArg.Split(splitter)[1];
            string session_ID = HttpUtility.ParseQueryString(SvcURL.Query).Get(SESSION_ID);
            string server_GUID = HttpUtility.ParseQueryString(SvcURL.Query).Get(SERVER_GUID);
            string serviceUrl = HttpUtility.ParseQueryString(SvcURL.Query).Get(SERVICE_URL);
            string locale = HttpUtility.ParseQueryString(SvcURL.Query).Get(LOCALE);
            string webServicesSessionId = HttpUtility.ParseQueryString(SvcURL.Query).Get(WS_SESSION_ID);

            txt_URL.Text = SvcURL.ToString();
            txt_moref.Text = MoRefArg;
            txt_type.Text = typeMoRef;
            txt_sessionId.Text = session_ID;
            txt_serverGuid.Text = server_GUID;
            txt_value.Text = valueMoRef;
            txt_locale.Text = locale;
            txt_serviceUrl.Text = serviceUrl;
            txt_wsSessionId.Text = webServicesSessionId;
        }
    }
}

Le problème que l’on a eu (puisque c’est quand même ça le but du billet) est que certaines valeurs n’étaient pas retransmise.

La règle du RTFM s’appliquant partout, c’est toujours dans la documentation sur les plugins que l’on trouve l’explication :

supportNonSecureCommunication > Optional. For non‐secure HTTP connections between the vSphere Client and and the plug‐in Web server that is identified by the url element of an extension element. See the description of the url element below. When the vSphere Client establishes a secure connection to a plug‐in Web server, the Client will pass sessionId and webServicesSessionId values in the HTTPS request. If the extension element specifies a standard HTTP connection, by default the vSphere Client does not pass the session identifiers to the plug‐in server. To include session identifiers in a standard HTTP request, use the following statement in your configuration file.
<supportNonSecureCommunication>true</supportNonSecureCommunication>

Pour que les éléments sessionId et webServicesSessionId soient communiqués via l’URL, il faut rajouter <supportNonSecureCommunication>true</supportNonSecureCommunication> au fichier XML de définition du plugin, et là ça marche !

<scriptConfiguration version="4.0">
	<key>vmdude</key>
	<description>vmdude Sample vSphere Client Plug-in</description>
	<name>vmdude Plug-in</name>
	<vendor>vmdude.fr</vendor>
	<multiVCsupported>false</multiVCsupported>
	<extension parent="InventoryView.VirtualMachine">
		<title locale="en">vmdude debug</title>
		<url display="window">http://localhost/index.aspx</url>
		<supportNonSecureCommunication>true</supportNonSecureCommunication>
	</extension>
</scriptConfiguration>

Moralité, on le dira jamais assez :

Pour éviter cela, on a pris l’habitude d’effectuer certaines opérations juste avant la conversion (ainsi que juste après, comme vous pouvez le lire dans notre précédent billet : Suppression des périphériques cachés).

On exécute la commande suivante sur les serveurs que l’on souhaite convertir :

netsh interface ip dump >> C:\netSettingsDump.txt

Voici par exemple le code généré depuis une machine de test :

# ----------------------------------
# IPv4 Configuration
# ----------------------------------
pushd interface ipv4

reset
set global icmpredirects=enabled
add route prefix=0.0.0.0/0 interface="Local Area Connection" nexthop=192.168.0.253 publish=Yes
add address name="Local Area Connection" address=192.168.0.152 mask=255.255.255.0

popd
# End of IPv4 configuration

Une fois convertie, lors de l’opération de « purge » de la VM convertie, on exécute la commande suivante afin de rétablir toute la configuration réseau :

netsh -f C:\netSettingsDump.txt

Note : Il faut juste bien penser à mettre le même nom au niveau des interfaces que celles qui se trouvaient sur le serveur physique pour que la reconfiguration marche correctement.