Repository et proxy par défault sur Veeam 6

Toujours dans les tests de Veeam 6, la nouvelle infrastructure que propose cette nouvelle version utilise la notion de proxy et de repository (que vous pouvez lire dans le What’s New de la v6 disponible ici :

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 »

Nouveau style pour le dude

Comme vous avez pu le remarquer, le dude a un nouveau thème (avec aussi un favicon et un logo :p) !

Ç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

Où est mon client sessionID ?

On est tombé sur quelque chose d’intéressant lors d’un test sur le développement d’un plugin Web pour vCenter. Pour le coup, on abandonne le C# pur vu que la méthode API C# est devenue obsolète comme en témoigne la documentation sur le VC-SDK disponible ici : http://www.vmware.com/support/developer/vc-sdk/vcplugin/

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 :

Préparation P2V : adresse IP

Lors d’une conversion d’un serveur physique vers une machine virtuelle (typiquement un P2V avec VMware Converter), un gros soucis est que toute la partie adressage IP est perdue (du à la réinitialisation de la couche TCP vu que pour le système c’est une nouvelle carte réseau).

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.

vSphere 5.0 Update 1 est disponible

Cette nuit VMware a publiée la première Update de la branche 5.# pour vCenter et ESXi.

vSphere vCenter

Pour vCenter, les build number correspondants sont :

vCenter Server 5.0 Update 1 | 15 March 2012 | Build 639890

vSphere Client 5.0 Update 1 | 15 March 2012 | Build 623373

Dans les choses sympa qui ont été ajoutées/corrigées, on trouve le support de la customisation guest pour les nouvelles versions des OS (notamment Windows 8 et Ubuntu 11.04/10).

La liste des correction étant vraiment longue, on vous invite comme d’habitude à lire le Release Note complet pour vCenter 5.0 Update 1 (très bonne source d’information, surtout pour les Known Issue à vérifier avant de se lancer dans une migration pour un bug pas encore corrigé) qui est disponible ici :

http://www.vmware.com/support/vsphere5/doc/vsp_vc50_u1_rel_notes.html

La mise à jour peut être téléchargée depuis : https://www.vmware.com/download/download.do?downloadGroup=VC50U1

vSphere ESXi

Pour ESXi, le build number correspondant est :

ESXi 5.0 Update 1 | 15 MAR 2012 | Build 623860

Ici, dans ce qu’on a noté de pas mal, il y a :

Tout comme pour vCenter, la liste des correction étant vraiment longue, on vous invite comme aussi à lire le Release Note complet pour ESXi 5.0 Update 1 qui est disponible ici :

http://www.vmware.com/support/vsphere5/doc/vsp_esxi50_u1_rel_notes.html

La mise à jour peut être téléchargée depuis : https://www.vmware.com/download/download.do?downloadGroup=ESXI50U1

Note : Pour toute les mises à jours, vous pouvez aller visiter le site vum.vmwa.re géré par hypervisor.fr, comme explioqué dans ce billet.