Windows 2008R2 : Booter sur un VHD
Une des nouveautés de Windows 2008R2 est le boot sur VHD. Pour rappel, le VHD est le format des disques virtuels dans l’environnement Microsoft (équivalent des vmdk chez VMware). Cette possibilité apporte une réponse à de nombreuses problématiques:
- V2P : Virtual to physical
- Tester une sauvegarde avant de la restaurer sur le système
- Déployer des plateformes multiboot
- ….
Dans notre cas, nous utilisons le boot from VHD afin de créer une image à froid du serveur.
Scénario:
Une image VHD est stockée sur la partition D: de notre serveur. Un opérateur lance un batch sous l’OS Windows 2008R2 natif. Le serveur redémarre alors sur le VHD qui n’est d’autre qu’un WINPE disposant d’outils de capture d’image : imagex et gimagex. Les disques C et D du serveur sont sauvegardés dans le répertoire D:\backup. A la fin du traitement, le serveur redémarre sous l’OS natif.
Mode Opératoire
Prérequis:
Installer le WAIK 3.0.
Disposer des pilotes du serveur à intégrer dans WinPE dans le répertoire D:\Drivers.
Disposer d’un serveur sous Windows 2008R2.
Etapes:
Création du WIM Winpe à l’aide de WAIK.
Configuration de cette WIM:
- Configuration des paramètres régionaux
- Ajout des pilotes du serveur à capturer
- Copie des outils supplémentaires
Sauvegarde de la WIM.
- Conversion de la WIM en VHD via diskpart.
Modification du boot du serveur.
Boot sur WINPE
Capture du serveur
Commandes:
Sur le serveur Windows 2008R2 disposant du WAIK.
Création de la wim de base
"C:\Program Files\Windows AIK\Tools\PETools\copype.cmd" amd64 D:\WINPE_BACKUP_WIM
Rem Montage de la boot.wim
imagex.exe /mountrw winpe.wim 1 mount
Rem Configuration des entrées/sorties en français
"C:\Program Files\Windows AIK\Tools\x86\Servicing\Dism.exe"/image:mount /Set-UserLocale:fr-FR
"C:\Program Files\Windows AIK\Tools\x86\Servicing\Dism.exe"/image:mount /Set-SysLocale:fr-FR
"C:\Program Files\Windows AIK\Tools\x86\Servicing\Dism.exe"/image:mount /Set-InputLocale:fr-FR
Rem Copie des utilitaires de gestion des WIM
xcopy "C:\Program Files\Windows AIK\Tools\amd64\*" mount\Windows\System32\
Rem Intégration des pilotes
"C:\Program Files\Windows AIK\Tools\amd64\Servicing\Dism.exe"/image:mount /Add-Driver /driver:"D:\Drivers" /Recurse /ForceUnsigned
REM Ici mettre les commandes de copie des tools dans mount\Windows\System32\
……
Rem Démontage et écriture dans la WIM
imagex.exe /unmount mount /commit
Création d’un VHD vide à l’aide de diskpart.
Create vdisk file=D:\WINPE_BACKUP_WIM\winpe.vhd maximum=800 type=fixed
Select vdisk file=D:\WINPE_BACKUP_WIM\winpe.vhd
attach vdisk
create partition primary
active
format quick label=WinPE
assign letter=z
Copie du contenu de la WIM dans le VHD
imagex /apply D:\WINPE_BACKUP_WIM\winpe.wim 1 z:
Détachement du VHD à l’aide de diskpart.
Select vdisk file=D:\WINPE_BACKUP_WIM\winpe.vhd
detach vdisk
Création d’une entrée de boot pour le VHD
set VHD_PATH=[d:]\WIMBACKUP\VHD\winpe.vhd
for /F "tokens=3 delims= " %%i in (‘bcdedit /create /d %DESC% /application osloader’) do set NEWGUID=%%i
bcdedit /set %NEWGUID% device vhd=%VHD_PATH%
bcdedit /set %NEWGUID% osdevice vhd=%VHD_PATH%
bcdedit /set %NEWGUID% path \windows\system32\winload.exe
bcdedit /set %NEWGUID% systemroot \windows
bcdedit /set %NEWGUID% detecthal yes
bcdedit /set %NEWGUID% recoveryenabled no
bcdedit /set %NEWGUID% winpe on
rem bcdedit /displayorder %NEWGUID% /addlast
echo %NEWGUID%> d:\WIMBACKUP\config\GUID.txt
exit 0
A noter le GUID de la nouvelle entrée est sauvegardé dans un fichier d:\WIMBACKUP\config\GUID.txt. Ce GUID servira lors de l’activation du boot sur VHD.
Activation du boot sur le VHD
set CONFIG_FILE=D:\WIMBACKUP\Config\guid.txt
FOR /F "tokens=1 delims=," %%G IN (%CONFIG_FILE%) DO set GUID=%%G
bcdedit /bootsequence %GUID% {current}
Cette commande permet de configurer seulement le prochain boot sur le VHD. La modification n’est pas permanente.
Capture du serveur
Une fois le boot sur VHD activé, il faut redémarrer le serveur. Celui-ci bootera alors sur l’environnement WINPE disposant des outils de captures.
Les commandes à lancées sont les suivantes :
imagex /capture c: d:\WIMBACKUP\backup\disqueC.wim "Disque C" /config D:\WIMBACKUP\Config\exclusion.ini
imagex /capture d: d:\WIMBACKUP\backup\disqueD.wim "Disque D" /config D:\WIMBACKUP\Config\exclusion.ini
Le fichier exclusion.ini ressemble à ceci. Il faut penser à exclure le répertoire de destination des WIM.
[ExclusionList]
D:\WIMBACKUP\Backup\*
D:\temp\*
[CompressionExclusionList]
*.7z
2 images WIM sont créées dans le répertoire d:\WIMBACKUP\backup\. Elles pourront être restaurées avec imagex /apply.
Il suffit de redémarrer le serveur pour que celui-ci redémarre sur l’OS natif.
ESXi : Configurer SNMP
Afin de monitorer les serveurs ESXi à l’aide de Nagios ou HP SIM, il faut configurer le service SNMP.
Voici les étapes:
Se connecter au serveur ESXi à monitorer via SSH ou console locale.
Modifier le fichier /etc/vmware/snmp.xml à l’aide de VI:
vi /etc/vmware/snmp.xml
Appuyer sur “i” pour passer en mode insertion.
Modifier le fichier comme ci-dessous :
<config><snmpSettings><enable>true</enable><communities>public</communities>
<targets>nom DNS du serveur@162/public</targets></snmpSettings></config>
true : permet d’activer le snmp
public : nom de la communauté
nom DNS du serveur@162/public : nom résolu du serveur devant recevoir les traps SNMP puis @ et le numéro de port et enfin / et le nom de la communauté
Fermer et sauvegarder le fichier :
Appuyer sur les touches “Echap”, “:”, “w”, “q”,”Entrée”.
Pour fermer sans sauvegarder :
Appuyer sur “Echap”, “:”, “q”, “!”,’Entrée”.
Redémarrer les services de gestion ESXi:
/sbin/services.sh restart
Redémarrage des services
Cette commande n’interrompt pas le fonctionnement des VM.
Pour tester l’activation du SNMP, il faut utiliser l’utilitaire SNMPWALK. Une version Windows est disponible à cette adresse: http://www.net-snmp.org/download.html
Une fois téléchargé et installé, lancer la commande suivante:
snmpwalk.exe -v 2c -c <nom de la communauté> <IP du serveur ESXi>
Exemple de résultat de l’utilitaire SNMPWALK
VCB : Restaurer un ou plusieurs fichiers à partir d’un VMDK.
Dans le cadre d’une sauvegarde FullVM avec VCB, les serveurs sont sauvegardés sous forme de VMDK. L’avantage de cette méthode est de pouvoir restaurer un serveur complet très rapidement.
Un problème se pose dans le cadre de la restauration d’un ou de plusieurs fichiers. Comment extraire du VMDK, un fichier?
Voici la procédure à suivre.
Pré-requis:
Disposer de l’utilitaire mountVM.exe sur un serveur. Cet utilitaire est intégré à VCB. Dans notre cas, nous utiliserons donc le serveur VCB pour extraire le fichier du vmdk.
Procédure:
Sur le serveur VCB, restaurer le VMDK.
Ouvrir une fenêtre de commande et saisir :
cd C:\Program Files (x86)\VMware\VMware Consolidated Backup Framework
mountvm.exe -d <chemin vers le vmdk > -cycleId <Chemin vers le répertoire de montage>
Le répertoire de montage ne doit pas exister car il sera créer et supprimer par la commande !!
Exemple de montage du disque C : du serveur ServeurX :
mountvm.exe –d k:\archives\ServeurX-fullVM\scsi0-0-0-ServeurX.vmdk -cycleId c:\mnt
Si la commande a fonctionné, le VMDK est monté dans le répertoire de destination.
Les fichiers peuvent être récupérés et recopiés sur le serveur cible.
Enfin il faut démonter le disque avec la commande :
mountvm.exe -u <chemin du répertoire de montage>
Exemple :
mountvm.exe -u c:\mnt
W2K8R2: Configurer le montage automatique des disques via unattend.xml
Lors de la première installation de Windows 2008R2 enterprise edition sur une machine virtuelle VMware (hardware 7), j’ai eu la surprise de découvrir que le disque 1 était offline. Jusqu’à présent, pour toutes mes installations, j’installais la version standard de Windows et je n’ai jamais rencontré ce problème. J’ai pourtant utilisé les mêmes tâches MDT et quasiment le même fichier unattend.xml.
En regardant le gestionnaire de disques (diskmgmt.msc), un message indique que le disque est “offline because of policy set by an administrator”. Le serveur n’étant pas intégré au domaine, on peut exclure les GPO.
Il semble que les disques virtuels VMware (niveau hardware 7) soient reconnus comme des disques SAN. Dans l’édition enterprise , en tant que disque SAN, celui-ci n’est pas monté automatiquement.
Pour corriger ce problème, il possible de modifier le fichier unattend.xml afin que, dés l’installation du serveur, le disque 1 soit en ligne.
Il suffit de rajouter dans la rubrique “OfflineServicing” (<settings pass="offlineServicing">) du fichier unattend.xml, le texte suivant:
<component name="Microsoft-Windows-PartitionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SanPolicy>1</SanPolicy>
</component>
Voici un lien listant toutes les valeurs possibles de SanPolicy.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb525577%28v=vs.85%29.aspx
Scripting Tips : Supprimer des snapshots via l’api Powershell de VMware
Les snapshots sont une des fonctionnalités les plus appréciées quand on commence à travailler sur des environnements virtuels. Ils permettent par exemple de faire retour arrière lors de mise en production.
Les snapshots sont aussi utilisés par les solutions de sauvegarde fournies par VMware : VCB et DataRecovery. Dans ce cadre là (couplé à VSS pour les serveurs Windows), ils permettent une sauvegarde à chaud des VM. En cas d’erreur pendant le processus de sauvegarde, il se peut que les snapshots créés ne soit pas supprimés.
Exemple de snapshots non supprimés
Le plus simple pour nettoyer son infrastructure est de créer un script supprimant tous ces snapshots.
Voici un exemple de code powershell pour supprimer tous les snapshots contenant les mots “VCB” ou “datarecovery”.
$ser = <Nom ou ip du serveur>
$serv = connect-viServer -server $ser -ErrorAction SilentlyContinue
Get-VM | Get-Snapshot | Where-Object {($_.name -like "*VCB*") –or ($_.name -like quot;*datarecovery*")}| Remove-Snapshot
Disconnect-VIServer -Server $serv -Confirm:$false
L’exécution de ce script entraine l’affichage d’une demande de confirmation.
Exemple d’écran de confirmation dans PowerGUI
Il est à noté que la commande remove-snapshot est bloquante. Les snapshots seront supprimés les uns après les autres. Une barre de progression indique l’avancement du traitement.
Exemple de barre de progression dans PowerGUI
vSphere 4 : Les mécanismes d’optimisation de la mémoire
Lors du dimensionnement d’une infrastructure virtuelle, la quantité de mémoire par hôte est une élément essentiel. La quantité de VM pouvant fonctionner par hôte est un élément important à prendre en compte dans le calcul du ROI d’une infrastructure virtuelle. Plus on va utiliser la mémoire plus le ROI sera rapide.
Un des avantages de VMware face à ses concurrents est la gestion des mémoire. L’éditeur a développé plusieurs mécanismes permettant d’attribuer plus de mémoires aux VM que n’en dispose l’hôte. Ce procédé est nommé Memory overcommit (ou overcommitment).
Le lexique
Tout d’abord, voici un rappel du lexique :
Active Guest Memory : Mémoire récemment utilisée par le système. Cette mémoire ne peut pas être réduite par le ballooning.
Consumed Host Memory : Quantité maximale de mémoire consommée depuis le démarrage de la VM. Cette valeur prend en compte la surcharge liée à la virtualisation (overhead).
Les seuils
Les techniques de réductions de la consommation de la mémoire se déclenchent en fonction de certains seuils.
Les seuils sont définis par défaut avec les valeurs suivantes:
- High : plus 6% de mémoire libre
- Soft : 4% de la mémoire libre
- Hard : 2% de la mémoire libre
- Low : 1% de la mémoire libre
| Seuils | Techniques |
| High | Aucune |
| Soft | Ballooning |
| Hard | Swapping, Ballooning |
| Low | Swapping |
Les techniques
Le TPS (transparent page sharing) : L’hyperviseur déduplique les pages mémoires identiques (particulièrement efficace en VDI). Cette technique est utilisée en permanence.
ex: 5Go sur de mémoire économisée sur un serveur disposant de 64Go de RAM et n’hébergeant que des serveurs Windows 2003.
Le ballooning : VMware créé un processus dans l’OS à l’aide des VMware Tools. Ce processus a pour but de provoquer un swap de l’OS. Le système d’exploitation swappe en priorité la mémoire inutilisée, préservant ainsi l’Active Guest Memory. La quantité de Consumed Host Memory est réduite pour tendre vers l’Active Guest Memory (+ l’overhead). Cette méthode permet de conserver de bonnes performances.
ex: 2048Mo de mémoire économisée. 1750Mo de mémoire ciblée par le ballon => phase de “dégonflage”.
La compression (à partir de vSphere 4.1) : L’hyperviseur compresse la mémoire à la volée. Cette technique entraine une charge CPU supplémentaire. Cette technique est utilisée en permanence.
ex: 278Mo de mémoire économisée grâce à la compression.
Le swapping : Dans ce cas là, le swapping est réalisé non pas par l’OS invité mais par l’hyperviseur. Celui-ci écrit aléatoirement des pages mémoires dans un fichier de swap (créer au démarrage de la VM). Cette technique est la plus pénalisante car si une page mémoire doit être accédée à partir du swap, une opération de lecture sur les disques a lieu .
Mais il est possible de tirer parti de cette technique en utilisant des disques SSD pour stocker les fichiers de swaps. Cette architecture est particulièrement intéressante dans le cas d’une infrastructure VDI.
ex: 398Mo de mémoire swappée (493Mo ciblée).
Les outils de monitoring
esxtop : Utilitaire en mode console. Pour le lancer, se connecter en SSH sur l’hôte à surveiller.
Puis saisir esxtop. Puis taper m pour passer en vue memory.
vSphere Client : Via l’onglet performance
Conclusion
Il ne faut pas avoir peur du memory overcommit (“surutilisation” de la mémoire) car les mécanismes mise en place par l’hyperviseur permettent de conserver des performances correctes évitant ainsi un effondrement brutal des VM.
Ces techniques sont particulièrement intéressantes dans une infrastructure VDI (TPS trés performant dans le cadre de 100 postes identiques sous Windows 7 par exemple).
Concernant les applications critiques aux comportement aléatoires (périodes charges inconnues par exemple), l’overcommit ne dois être utilisé que temporairement.
Je n’ai pas abordé la mise en place de limites et de priorités concernant la gestion de la mémoire car l’expérience montre que le coût de gestion de ces critères est très important par rapport au retour attendu.
Ces mécanismes associés à la mise en place d’un processus de capacity planning vous permettront de proposer une infrastructure virtuelle performante sans aléas.
Nouveautés de VMware Data Recovery 2.0
Avec la sortie de vSphere 5, VMware en profite pour sortir la version 2.0 de Data Recovery (VDR). Pour rappel VDR est une solution de sauvegarde des VM à chaud capable de faire de la déduplication. La licence VDR est fournit dés la version standard (depuis l’update 1 de d’ESXi 4.1) de vSphere.
VDR se présente sur sous la forme d’une appliance a déployer dans l’infrastructure et d’un plugin à intégrer au vSphere Client.
La précédente version (1.2) était la première étape pour remplacer VCB. Malgré ses qualités, le produit montre de nombreuses limites et problèmes de performance liés à sa jeunesse. Par exemple, pour sauvegarder sur un partage Windows (CIFS), il est recommandé que le volume de destination ne dépasse pas 500Go (sous peine de voir les performances s’effondrer). Si le contrôle d’intégrité quotidien tombe en erreur, il est impossible de sauvegarder ou de restaurer des données car le magasin de données est verrouillé.
VMware a réparé le tir grâce à VDR 2.0 dont voici les nouveautés :
- Possibilité de suspendre un job sans affecter les autres
- Possibilité de définir une fenêtre de maintenance
- Modifier la périodicité du contrôle d’intégrité
- Choix de la sauvegarde du swap des VM
- Génération d’un reporting par email
- Amélioration des performances de la déduplication via l’utilisation de nouveaux algorithmes
- Passage en 64bits de l’appliance VDR pour une meilleure utilisation des ressources
- Exclusion de la sauvegarde des swaps des VM Windows et Linux par défaut
- Correction de bugs : blocage sauvegarde CIFS, …
Pour l’instant VDR 2.0 n’est disponible que pour vSphere 5.0. En attendant de faire les premiers tests, il semble que , sur le papier, VMware est entendu les remarques des utilisateurs.
Pour plus d’informations concernant les nouveautés, je vous invite à consulter la documentation: http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-Data-Recovery-20-Technical-Whitepaper.pdf
Estimer le nombre de licences vSphere 5 nécessaires pour migrer une infrastructure existante : vSphere Licensing Advisor 1.0
La nouvelle mouture de vSphere sort aujourd’hui. Elle apporte avec elle de nombreuses évolutions techniques. (http://www.vmware.com/products/vsphere/upgrade-center/overview.html). Une autre évolution (pas forcément attendue avec impatience) arrive avec vSphere 5.0 : le nouveau système de gestion des licences.
Pour comprendre les changements, je vous invite à consulter le document officiel : http://www.vmware.com/files/pdf/vsphere_pricing.pdf.
Pour résumer :
- Il faut toujours 1 licence par CPU.
- L’édition Advanced disparait. Les licences vSphere 4 pourront être migrées en vSphere 5 enterprise.
- Le nombre de core par CPU n’est plus limité selon l’édition.
- Le nombre de vCPU par VM est limité par l’édition.
- Les nouvelles fonctionnalités ne sont disponibles que dans l’édition enterprise plus.
- Une licence donne droit à une quantité de vRAM (mémoire configurée) :
| License Type | Essentials | Essentials Plus | Standard | Enterprise | Enterprise Plus |
|---|---|---|---|---|---|
| vRAM Entitlement per License | 32GB | 32GB | 32GB | 64GB | 96GB |
Pour nous aider à nous retrouver dans toutes ces nouveautés, VMware met à notre disposition un outil nommé vSphere Licensing Advisor. (disponible sur cette page).
Cet outil se connecte sur l’infrastructure existante et estime la quantité de mémoire configurée utilisée et la quantité de mémoire configurée utilisable dans le cas du licensing vSphere 5.
Pour utiliser l’outil, saisir les infos de connexion aux VCenter.
L’utilitaire récupère les informations nécessaires.
Un rappel sur les règles de calcul est affiché.
Voici le résultat :
La colonne vRAM Used correspond à la quantité de mémoire configurée sur des VM démarrées (état PowerOn ).
La colonne vRAM capacity correspond à la quantité de mémoire configurable. C’est à dire la quantité maximale de mémoire que l’on peut configurer( différent de la quantité réellement consommée) à des VM démarrées. On peut assigner plus de vRAM à des VM mais celles-ci ne pourront pas être démarrées.
Dans notre cas, la quantité de mémoire configurable en vSphere 5 pour les VM est de 448 GO. Ce nombre correspond à 14 (nb licences vSphere 4) * 32 (quantité max de mémoire pour l’édition standard).
De ce pool de 448Go, 244Go sont utilisées. Cela signifie que la somme de la mémoire configurée pour toutes les VM démarrées est de 244Go.
La conclusion est que pour faire fonctionner l’ensemble des VM existantes dans mon infrastructure aucun achat n’est obligatoire. La migration des licences vSphere 4 en vSphere 5 permet de couvrir le double mon existant.
Par contre d’un point de vue technique mon infrastructure possèdent les ressources suivantes :
Je dispose de 471,64 Go de mémoire disponible. Or avec 14 licences vSphere 5, je ne peux disposer que de 448Go de vRAM. Si je souhaite exploiter au maximum mes ressources physiques, il faut que je rajoute au moins 1 licence standard. Dans le cas, où je souhaite faire de l’overcommit, il faudra que je rajoute encore des licences. Cela remet en cause les calculs de ROI réalisés à base de vSphere 4.
En conclusion, dans le cadre d’une migration vers vSphere 5, il est important d’estimer le coût du surplus de licence à acheter.
Le nouveau système ne remet pas en cause fondamentalement la rentabilité d’un projet de virtualisation mais il nous pousse à réfléchir quant à notre dépendance vis à vis des politiques tarifaires d’un éditeur. Le changement de solution de virtualisation n’est pas simple notamment pour les fournisseurs d’offre cloud IAS (infrastructure as a service). L’utilisation (ou au moins l’étude) d’une solution alternative à vSphere (Hyper-v, XenServer) peut permettre de se libérer en partie des aléas tarifaires de l’éditeur.
Les modules HP Virtual Connect
Les plus hautes densités de serveurs sont obtenues grâce aux serveurs Blade. Un châssis possédant un système d’alimentation et de refroidissement dispose de slots pour accueillir d’un côté des serveurs (device bays) et de l’autre des périphériques de connexions (interconnect bays).
Les alimentations et le refroidissement sont ainsi mutualisées.
Vue avant et arrière d’un châssis c7000.
La densité des serveurs est ainsi améliorée. Par exemple, dans un châssis HP C7000 de 10U, on peut insérer jusqu’à 16 serveurs proliant (gamme bl) monoface bicpu. Dans le cadre des clusters de calculs, on peut disposer de serveurs double side, disposant de 2 cartes mères; augmentant ainsi le nombre de serveurs à 32 pour 10u.
Cette densité présente un inconvénient de taille : le câblage. Si chaque serveur dispose de 4 ports réseaux et de 2 connexions fibres, il faut tirer 64 connexions réseaux et 32 fibres . Cela fait autant de port à acheter sur les switchs réseaux et SAN.
Pour répondre à cette problématique, HP propose la technologie Virtual Connect.
Pour résumé, les serveurs possèdent toujours autant d’attachements mais en sortie du châssis le nombre de ports est réduit. Les blades se partagent donc les liens.
La configuration est réalisée via une interface Web hébergé sur les modules Virtual Connect.
On définit des réseaux et des fabrics. Pour cela, on choisit un périphérique (VC Networks ou VC Fibre) d’interconnexion puis on choisit le ou les ports de sorties.
Définition d’un réseau
Définition d’une fabric
On créé ensuite un profil pour chaque serveur dans lequel on assigne les réseaux et les fabrics.
Création d’un profil
Avantages:
Moins de câblage.
Le port physique de sortie est dissocié du serveur. On peut déplacer un profil sur autre serveur en quelques clics.
Inconvénients:
Problème de responsabilité: Qui s’occupe des modules Virtual Connect? Les équipes réseaux ou les équipes systèmes.
Moins de câblages donc moins de bande passante disponible.
Je vous invite à consulter le site HP pour découvrir la gamme Virtual Connect avec notamment la technologie Flex-10.
Site HP
virtualsysadmin 