Créer un « Profil » pour vos futurs machines virtuelles

aka: « Spécifications de personnalisation de la VM »

Avant propos :

Kesako que les Profils de VM, aka « Spécifications de personnalisation de la VM » ?
Cela permet de déployer des machines virtuelles avec ou sans template, plus rapidement (via clone). Le profil de VM va vous permettre de configurer une bonne partie de votre Windows comme :
– La joindre au domaine
– la nommer
– Activer Windows
– Mettre un fichier sysprep généré par vos soins …
– etc …

Bref, une fois créé, le profil va vous simplifier la vie ! et en plus c’est super simple !

Prérequis :

  • Un template Windows ou un Windows « clonable »
  • VMware Tools doit être installée sur la machine virtuelle qu’on va cloner ou sur le template
  • un ESX en version 3.5 ou plus (lol)
  • Pour les Linux, il vous faut PERL en plus des VMware Tools

Création du profil de VM :

Depuis le « Menu » en haut dans votre vCenter en 6.7 – HTML5 (oui j’me la pète grave !) , cliquez sur « Stratégies et Profils »

Sélectionnez « Spécifications de personnalisation de la VM » puis « Nouvelle »

Renseignez un « Nom » pour votre profil puis une « Description », votre vCenter (si vous en avez plusieurs) et l’OS cible. Dans notre cas, nous allons sélectionnez « Windows » sans un fichier sysprep. Cliquez sur « NEXT »

Renseignez le propriétaire puis cliquez sur « NEXT »

Au prochain écran, vous aurez la possibilité de donner un nom d’hôte à votre machine en fonction de votre nom de VM (option1) ou alors entrez un nom lors du déploiement (option 2) ou forcer un nom d’hôte avec un numéro incrémental . Dans notre cas, nous allons choisir la première option.

Renseignez la CLEF du produit : (vous pouvez ne pas renseigner de clef, augmenter le nombres d’activation)

Renseignez le mot de passe Administrateur de la VM. (il n’y aura pas de compte « Administrator » de créé en plus, mais bien l’activation du compte local « Administrateur » pour les Français comme nous). Vous avez aussi la possibilité de ne rien mettre.

Sélectionnez le bon fuseau horaire.

La prochaine fenêtre permet d’exécuter des commandes Windows (tel que DISM ou netsh etc..) Si vous souhaitez customiser vos Windows. Cliquez sur NEXT.

La meilleure configuration disponible reste celle du réseau. Lorsque vous allez déployer votre VM, nous aurons la possibilité de faire apparaître un « prompt » qui va vous demander de rentrer l’adresse IP du futur serveur. Ca fera une chose en moins à faire après l’installation de Windows.
Pour activer cette fonctionnalité, il faut cliquer sur les trois petits points à coté de la NIC puis « Modifier »


Renseignez le masque et Passerelle (2) , cochez aussi la case « Inviter l’utilisateur à donner …..  » (1) :

Toujours dans la même fenêtre, allez dans l’onglet « DNS », renseignez les champs DNS favori et alternative , puis cliquez sur « OK »:

Vos modification seront prises en compte dans la précédente fenêtre comme ci dessous , vous pouvez cliquer sur « OK »

Et pour finir, la meilleure fonctionnalité, joindre la VM dans le domaine. Renseigner le domaine, et le compte qui servira à joindre la VM au domaine, puis cliquez sur « NEXT »

L’écran final est un récap de la configuration renseignée. Vous pouvez cliquer sur FINISH.

Votre profil apparaîtra comme ci dessous :

Comment l’utiliser ?

« article en cours de rédaction »

Créer des VM en MASSE via script !!

Avant propos :

Ce script est « fait maison » et avec le cœur. Oui, il n’est pas parfait et oui, il y a surement des optimisations à faire, mais il fonctionne et surtout j’y ai passé du temps dessus…
Je suis ouvert à toute proposition d’amélioration, dans le respect bien-sur ! sinon allez vous faire … 🙂

Version :
V1 – Diffusion 10/04/2019

Prérequis :

  • PowerCLI sur le serveur ou PC allant lancer le script
  • Un compte ayant les droits de création de machine virtuelle
  • Un profil de machine virtuelle (vous savez, le « truc » que personne n’utilise dans le vCenter nommé « Gestionnaire de spécification de personnalisation » )
  • Un Template parfait (voir mon autre article « Comment créer une machine virtuelle)

Que va faire le script ?

  1. Se connecter au vCenter
  2. Chercher si les machines virtuelles existent déjà
  3. Créer X machines virtuelles via un template et un profil de VM sur un host aléatoire en fonction du nombre de Host disponible (mention spéciale aux personnes n’ayant pas le DRS de configuré :p )
  4. Vous informer de l’avancement des tâches de création
  5. Les démarrer après création afin que le profil de VM s’applique.

J’insiste sur le fait que le Profil de VM doit être créé et configuré. C’est simple à faire depuis le vCenter, et c’est un gain de temps considérable pour la configuration des machines virtuelles après création.

Pour rappel : le Profil de VM permet de configurer la machine virtuelle dès le premier démarrage de celle-ci. On peut configurer le hostname, la licence, la configuration réseau, joindre la VM au domaine etc ….. !

Le Script :

j’ai commenté suffisamment le script pour qu’il soit facile à lire et modifier. Dans cette exemple ci dessous, je l’applique à un environnement VDI (ce qui explique le nom des VM) mais cela fonctionne aussi dans un environnement standard…)

Les variables :

Les variables à modifier OBLIGATOIREMENT sont :


$vcenterXBI ##le nom d'hôte ou IP du VCENTER
$datastoreXBI ##Variable pour le Datastore de destination de l'ensemble des futurs VMs
$nbreHoteXBI ##Nombre d'hote ESX dans le cluster
$modeleXBI ##Le modèle de base (template obligatoire)
$poolVMXBI ##Nom du pool de ressource, pas obligatoire, vous pouvez supprimer si jamais
$personnalisationXBI ##Fichier de personnalisation créé depuis le vcenter (vous savez le fameux "Gestionnaire de spécification de personnalisation"
$nomVMXBI ##Nom des futurs VM, le {0} corresponds au numéro, exemple "maison{0}" va créer maison1, maison2 etc...

Le script complet :


Clear
Add-PSSnapIn VMware.VimAutomation.Core  #powercli
####### VARIABLES #######
$vcenterXBI = "nom du vcenter"                               ##le nom d'hôte ou IP du VCENTER
$userXBI = Read-Host -Prompt "Nom d'utilisateur"             ##Prompt pour l'utilisateur
$passwordXBI = Read-Host -Prompt "mot de passe"              ##Prompt pour le mot de passe
$datastoreXBI = "vsanDatastore"                              ##Variable pour le Datastore de destination de l'ensemble des futurs VMs
$nbreHoteXBI = "4"                                           ##Nombre d'hote ESX dans le cluster
$modeleXBI = "VDI-2k12-GOLD"                                  ##Le modèle de base (template)
$nombreVMXBI = Read-Host -Prompt "Nombre de VM à cloner ?"   ##Prompt pour le nombre de VM à créer
$poolVMXBI = "VDI-2K12"                                        ##Nom du pool de ressource, pas obligatoire, vous pouvez supprimer si jamais
$personnalisationXBI = 'Windows2k8-VDI'                      ##Fichier de personnalisation créé depuis le vcenter
$nomVMXBI = "VDI-TEST-{0}"                                   ##Nom des futurs VM, le {0} corresponds au numéro, exemple "maison{0}" va créer maison1, maison2 etc...  
###### FIN DES VARIABLES #######

Connect-VIServer -Server $vcenterXBI -User $userXBI -Password $passwordXBI
$spec = Get-OSCustomizationSpec -Name $personnalisationXBI

function creation {
    1..$nombreVMXBI | foreach{
        $vmNom = $nomVMXBI -f $_
        $vm = Get-VM -Name $vmNom
            if ($vm) {
                "{0} exists" -f $vmNom
                Write-Host "Machines existent déjà" -ForegroundColor Red
                exit
                Disconnect-VIServer -Confirm:$false
                     }
            else {
                $numHost = get-random -Maximum $nbreHoteXBI         ##genere un nombre         
                $esx = (Get-VMHost)[$numHost]                    ##selectionnne un hote en fonction du nombre au dessus
                $esx | New-VM -Name $vmNom -Template $modeleXBI -Datastore $datastoreXBI -OSCustomizationSpec $spec -ResourcePool $poolVMXBI -RunASync
                 }
}
}
Clear
function log {
              Do {
              Clear
              Get-Task | Where-Object { $_.name -eq "CloneVM_Task" -and $_.State -eq "Running"} | Format-Table
              sleep 10
              Clear
}
              until ((Get-Task | Where-Object { $_.name -eq "CloneVM_Task" -and $_.State -eq "Running"}) -eq $Null)}

function StartdesVM {
    1..$nombreVMXBI | foreach{
                          $vmNom = $nomVMXBI -f $_ 
                          Start-VM -VM $vmNom
                          sleep 3
                          }
}

creation #fonction de creation des VM
log #fonction de log interractif
StartdesVM #demarrage des VM

Write-Host "Machines virtuelles crées et démarrées, merci de patienter le temps que le profil de VM s'applique !" -ForegroundColor Yellow
Disconnect-VIServer -Confirm:$false

Résultat :

J’ai lancé la création de trois machines virtuelles :

Pendant la création des VM :

A la fin de l’exécution du script :

Sur mon pool de ressource dans le vCenter :


Utiliser BITS pour le téléchargement des mises à jour Windows7 et DOsvc pour Windows 10

Petit Rappel :

Les services :

BITS ou « Background Intelligent Transfer Service », introduit sur Windows Vista, a pour but de brider le téléchargement en arrière plan des mises à jour Windows.

BITS

DOsvc ou « Delivery Optimisation », introduit sur Windows 10 Build 1511, est une véritable mer***** …… désolé. C’est le « remplaçant » de BITS. Il est « CENSÉ » faire la même chose sauf que, même configuré sur un Windows 10 (Build 1511), et bien c’était pas aussi bien que BITS. Et c’était surement dû au fait que, sur les anciens builds de Windows 10, la limite maximale d’utilisation pour DOsvc était exprimée en pourcentage……. % de la bande passante maximale d’une carte en gigabit… vous comprenez ?
DOsvc est utilisé par le Windows Store, et est capable de faire du « pear caching » comme son homologue BITS.

DOsvc « Delivery Optimisation « 

« Pourquoi faire simple, quand on peut faire compliqué »

Les modes de « Delivery Optimisation » :

Il existe différent « mode » pour DOSVC qu’il est possible de configurer via GPO :
HTTP (0) : téléchargement sans cache depuis un WSUS ou Windows Update avec les services Cloud (donc internet) en plus.
LAN (1) : La même chose que le premier sauf qu’en plus, le PC va chercher des petits copains DOsvc sur le LAN pour récupérer les mises à jour.
Groupe (2) : Permets de faire des groupes de PC via un ID, chaque groupe est indépendant de l’autre. Les PC d’un groupe échangeront leurs caches pour télécharger les mises à jour. Pour moi c’est totalement inutile car cela vient en plus de « Site et service active Directory » et du découpage en sous-réseau …
Internet (3) : Utilise DOsvc uniquement vers des sources internet.
Simple (99) : Un mode « offline » , désactive les services Cloud et la mise en cache.
Contournement (100) : Permet de ne pas utiliser DOsvc mais BITS à la place. Personnellement, je trouve cela comme un aveu de Microsoft sur DOsvc (C’est de la m**de, on le sait, on vous propose d’utiliser BITS)……

« La mode passe, le style reste. »

Comprendre ce qu’il se passe lorsqu’un PC à besoin d’une mise à jour :

Que se passe t’il lorsqu’un PC à besoin d’une mise à jour et qu’il y a un WSUS ?

  1. Le PC se connecte au WSUS
  2. Le PC envoi un rapport des mises à jour installées
  3. Le WSUS compare les mises à jour disponibles par rapport aux mises à jour installées (via le rapport envoyé par le PC) et renvoi la liste des mises à jour dites « Applicables »
  4. Le PC affiche « X » mises à jour à installer.
  5. En fonction de la configuration de son service Windows Update, le PC initialisera ou non le téléchargement et l’installation. Comprenez par-là que, c’est le PC qui télécharge et non le WSUS qui pousse les données. C’est le PC qui initie le téléchargement auprès du WSUS et non l’inverse. BITS doit être configuré coté PC et non coté WSUS (dans ce cas là précisément).

Objectif :

Limiter la bande passante utilisée pour les téléchargement en arrière plan. Les services BITS et DOsvc sont là pour ça.

Nous allons configurer, via GPO, ces deux services en fonction des PC.
Sachez que même si BITS est configuré sur Windows 10, DOsvc sera utilisé par défaut.

Lets go :

Nous allons configurer une seule GPO pour les postes en Windows 10 et Windows 7. La configuration de BITS pour les PC en Windows 7 n’affectera pas les postes en Windows 10 et la configuration de DOsvc n’affectera pas les postes en Windows 7. Donc pas besoin de multiplier les GPO.

Configuration de BITS pour les PC en Windows 7 :

RAPPEL : La configuration de BITS se fait sur les ordinateurs et non sur le WSUS. La GPO doit donc s’appliquer sur les ordinateurs et non le WSUS. !!

1) Éditez votre GPO WSUS (ou créez en une)

2) Allez dans « Configuration Ordinateur / Modèles d’administration / Réseau / Service de transfert intelligent en arrière-plan (BITS)« 

3) Double cliquez sur « Limiter la bande passante réseau maximale pour le transferts BITS en arrière-plan »

4) Cochez « Activé » puis configurez à votre guise. Attention, la valeur est exprimée en kilobit et non en koctet . Pensez à diviser par 8 la valeur que vous mettez pour obtenir la valeur en koctet.

Ne soyez pas gourmand, dans mon exemple 80 kilobit suffisent pour que les PC récupèrent leurs mises à jour. Prenez en compte le fait que, les PC vont télécharger toute la journée (ou la nuit). Vous pouvez augmenter la valeur si vous souhaitez que les postes récupèrent plus rapidement les mises à jour.
La case « Utiliser toute la bande passante inutilisée disponible » indique à BITS de télécharger sans limite hors des périodes définies au dessus. J’ai décocher la case pour forcer BITS à télécharger tout le temps à 80 kilobit.

BITS est configuré (configuration rapide car pas de BranchCache, mais ce n’est pas le sujet).

Configuration de « DOsvc » pour les PC en Windows 10 :

!! Attention, vous devez avoir les derniers ADMX de disponible pour Windows 10 dans votre sysvol\PolicyDefinition sinon vous n’aurez pas toutes les dernières fonctionnalités de DOsvc !!
REF : https://support.microsoft.com/fr-fr/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra

Nous allons utiliser le mode « Simple » (99) pour le service d’Optimisation de la Distribution.
– Pas de connexion au Cloud Microsoft Update
– Pas d’échange entre « peers »

1) Éditez votre GPO WSUS (ou créez en une)

2) Allez dans « Configuration Ordinateur / Modèles d’administration / Composant Windows / Optimisation de la distribution »

3) Les deux options principales à configurer sont :
– Mode de téléchargement
– Bande passante de téléchargement maximale (Ko/s)

4) Éditez la configuration de « Mode de téléchargement », et sélectionnez « Activé » et le mode « Simple » (99), Appliquer, fermer.

Éditez la configuration de « Bande passante de téléchargement maximale (Ko/s) », et sélectionnez « Activé » , rentrez une valeur (dans mon exemple 10).

DOsvc est maintenant configuré. La configuration prendra effet au prochain redémarrage de l’ordinateur.

Test / Résultat :

Il faut savoir être patient (surtout avec Windows Update).

!! Sur les PC ayant BITS de configuré, ne forcez pas la recherche des mises à jour coté ordinateurs. L’action manuelle de cliquer sur « Rechercher/installer/télécharger les mises à jour » enclenchera le téléchargement en mode « Foreground » et non « Background » . Le téléchargement en « Foreground » ne prends pas compte la limitation BITS.
Si vous souhaitez effectuer un test, laissez le PC rechercher et installer les mises à jour seul.

https://social.technet.microsoft.com/Forums/windowsserver/en-US/6390ca30-2734-4b83-a581-2b208498a1fc/resolved-bits-dosvc-wsus-and-windows-10-1703?forum=winserverwsus

Vérification sur le WSUS :

On peut facilement vérifier les résultats de cette configuration via le « Moniteur de ressources » depuis le WSUS, onglet Réseau. Vous trouverez une multitude de PC connectés au WSUS, qui téléchargent à vitesse fixe.

Ci dessous un rapport des ordinateurs à jour en agence. BITS / DOsvc étant configurés depuis 2 semaines. Les postes se mettent à jour à l’arrêt chaque soir. Il y a eu un delta à rattraper tout de même.

Vérification sur un PC :

Vous pouvez vérifier de la même manière que sur le WSUS via le « Moniteur de ressources ». Mais aussi en Powershell, les « jobs » de BITS et de DOsvc.

Pour Bits :

Get-BitsTransfer -AllUsers
Résultat de la commande sur un poste en Windows 10 n’ayant pas Bits de configuré.

Pour DOsvc :

Get-DeliveryOptimizationStatus | ft
Résultat de la commande sur un poste en Windows 10. Dans ce cas là, vous pouvez voir que tout les fichiers sont complètements téléchargés (FileSie -> TotalBytesDownloaded)
On remarque aussi que le téléchargement se fait uniquement en HTTP et non via le peercaching (homologue Windows10) ce qui prouve que le mode « Simple » (99) est configuré et utilisé.

2 GPO 1 OU : Distinguer les ordinateurs du siège et des agences via la Gateway

Cas Pratique :

Sous ce titre aguicheur se cache en réalité un problème que de nombreux administrateurs ont déjà rencontré.

1) Mes ordinateurs ne sont pas triés par site
2) « Site et service Active Directory » est configuré par défaut (ne rigolez pas, c’est TRÈS souvent le cas, 3 sociétés, 3 fois le cas)
3) ils sont rangés dans une seule et même Unité d’Organisation.

Objectif :

Je souhaite appliquer une configuration WSUS (ou autre) particulière pour les postes du siège et une autre configuration pour les postes des agences/bureaux.
Principalement, on fait cela lorsqu’on veut utiliser BITS/DoSVC pour le téléchargement des mises à jour.
Ne pas brider le téléchargement au siège (réseau 10GB etc…)
Brider en agence (car MPLS, réseau WAN faible etc…)

Les solutions disponibles :

1) Configurer « Site et service Active Directory » et appliquer la GPO par SITE. Nécessite beaucoup de temps et d’étude avant d’y mettre en place, mais c’est la plus propre…
2) Ranger les PC dans les « OU » spécifiques et appliquer la GPO sur l’OU voulu. C’est long, chiant à faire (rien de valorisant à déplacer des objets de l’Active Directory….), chiant à garder en vie (j’entends par là, déplacer les PC en fonction des mouvements du personnels etc…..)
3) Filtre WMI via la Gateway des PC (la plus simple, pour les fainéants comme moi :p)

La Solution : Filtre WMI

Cette solution consiste à créer et lié un filtre WMI à une GPO afin de filtre en fonction du besoin. Un peu à la manière d’un groupe lié à une GPO.
Exemple de GPO ayant un filtrage par WMI :

Pour les malins : ne faite pas attention au blocage d’héritage, l’AD est en réorganisation, c’est donc normal.

Lets do it :

Création d’un filtre WMI.

Ouvrez « Gestion de Stratégie de Groupe« , allez tout en bas, sur le dossier nommé « Filtres WMI » et faites un clic droit dessus puis « Nouveau…« 

Nommez et décrivez votre futur filtre WMI, puis cliquez sur « Ajouter »

La requête pour les PC du Siège :

Select Mask,Destination,NextHop from Win32_IP4RouteTable WHERE ((Mask='0.0.0.0' AND Destination='0.0.0.0') AND (NextHop='VOTRE GATEWAY DU SIEGE ICI'))

La requête pour les PC des agences :

Select Mask,Destination,NextHop from Win32_IP4RouteTable WHERE ((Mask='0.0.0.0' AND Destination='0.0.0.0') AND (NextHop<>'VOTRE GATEWAY DU SIEGE ICI'))

NB : Vous n’avez qu’a modifier « VOTRE GATEWAY DU SIEGE ICI » et rien d’autre.

Et oui, il y a bien une différence entre les deux requêtes. Elle se situe ici :
« AND (NextHop<> » = différent de
« AND (NextHop= » = égale

Pour faire simple :
– Si la Gateway est égale à celle du siège, alors le PC est au siège
– Si la Gateway est différente de cette du siège, alors le PC est en agence (ou ailleurs)

Collez la requête que vous souhaitez ici, puis validez.

Cliquez sur « Enregistrer », votre requête WMI est prête. Vous pourrez alors la sélectionner dans votre GPO comme dans l’exemple ci dessous » :

Qu’est ce que cela donne lors d’un GPRESULT ?

Ceci :

Mon PC est actuellement au siège. La valeur est Vrai.

Mes GPO (à droite) sont appliquées ou non en fonction de la valeur Faux/Vrai du filtre WMI (à gauche). Si « faux » la GPO ne s’applique pas, si « Vrai », la GPO s’applique.
C’est aussi simple que cela.

Créer une machine virtuelle CORRECTEMENT !

Avant Propos :

Je te vois venir ! Tu vas chercher la petite bête pour pouvoir mettre un commentaire « sabrant » sur ce tuto, mais sache que c’est marqué « CORRECTEMENT » et pas « PARFAITEMENT » (on s’en rapproche quand même un peu)…. 🙂

Pourquoi faire un tuto sur une chose si simple à faire ?

Trop souvent, on néglige des paramètres lors de la création des machines virtuelles. Trop souvent, on a tendance à en mettre trop, trop de CPU, trop de RAM, trop de trop etc… #overcommitment 
Et trop souvent, on se dit : « Ah ! J’aurai du activer ceci , ou cela etc… »

Le Choix du contrôleur « Virtual SCSI » :

  • Par défaut, le contrôleur choisi est « LSI Logic SAS ».Effectivement, c’est le contrôleur recommandé par Microsoft lorsqu’on installe un Windows Server 2008 ou supérieur… (obligatoire si Microsoft MSCS)
  • PVSCSI , technologie VMware, dédié et optimisé pour la virtualisation. Si votre VM va consommer des Iops (Bases de donnée etc), ou si votre stockage est performant, utilisez le.

Mon point de vue :
Si MSCS, j’utilise LSI Logic SAS.
Sinon, j’utilise PVSCSI.

Quelle est l’intérêt du PVSCSI par rapport au LSI Logic SAS ?

Les plus :
– Consomme moins de CPU par IO (moins de cycle CPU en cas d’un Workload élevé)
– Conseillé pour les serveurs qui vont consommer beaucoup d’IOPS.
– Technologie de contrôleur dédiée à la virtualisation
– C’est une technologie VMware <3

Les moins :
– N’est pas supporté par Microsoft MSCS ….
– Pas de driver natif dans Windows, obligé de passer par ceux de VMware.

Le CPU : « Best Practice »

Les règles :
– Créer une machine virtuelle avec 1 vCPU, vous pourrez en rajouter en fonction du besoin.
– Ne « sur approvisionnez » pas la machine virtuelle, vous risquez de dégrader les performances des autres machines virtuelles.
– De manière générale, les HOST ESX gèrent très bien le « sur approvisionnement » mais il ne faut pas non plus en abuser.
Le mieux est de calculer l’ensemble des vCPU alloués par rapport aux vCPU disponibles et équilibrer le tout.
Le ratio de « sur approvisionnement » est de 1 pour 1 jusqu’à un maximum de 3 pour 1, passez au dessus, c’est vraiment pas bon.
Exemple : 24vCPU alloués sur 24 vCPU disponibles = OK / 48vCPU alloués sur 24 vCPU disponibles = OK /
72vCPU alloués sur 24 vCPU disponibles = NON OK

BONUS :

Calculer la ressource disponible d’un HOST :
pCPU = nombres de cœurs physiques
vCPU = nombre de cœurs virtuels

Calculer le nombre de cœurs physiques pCPU :
Nombre de Processeurs Physiques (sockets) * Nombre de cœurs physiques = pCPU
Exemple : Mon ESX dispose de 2 sockets (processeurs physiques), chaque socket dispose de 6 cœurs alors :
2 * 6 = 12 pCPU

Calculer le nombre de cœurs virtuels vCPU (Hyperthreading) :
Nombre de pCPU * 2 = vCPU
Exemple :
Mon ESX à 12 pCPU et dispose de l’Hyperthreading alors :
12 * 2 = 24 vCPU

NOTA BENE : l’Hyperthreading ne double pas le nombre de vCPU, c’est plus complexe que cela.
l’Hyperthreading agit sur chaque cœur physique en leur permettant d’avoir deux « threads », un actif et un en « queue/attente » d’exécution permettant l’enchaînement de calcul à chaque cycle plutôt que d’attendre l’instruction d’un autre calcul à la fin d’un cycle complet.

Création de la Machine Virtuelle :

La VM va être créée et modifiée uniquement via l’interface Web en FLASH. Etant en version 6.0, l’HTML5 Aka « FlatDesignDegueux » n’est pas disponible.

Vous venez de lancer l’assistant de création de machine virtuelle. A la fin, vous pouvez éditer le matériel avant de finaliser la création.

Onglet : Matériel Virtuel

Le CPU :

NB : 2 sockets car pré-requis technique d’une application lors de la capture d’écran.

Possibilité de régler la « Parts » en « haute » si la machine doit être prioritaire vis-à-vis de la consommation des ressources CPU par rapport aux autres VM (SharedCPU). Plus la part est haute, plus elle est « prioritaire ». Cette valeur est aussi applicable sur un pool de ressource.

La Mémoire :

4GB, toujours suivant les pré-requis de mon application.

Le contrôleur SCSI :

Suppression du lecteur de disquette :

Carte Réseau en VMXNET3 :

Onglet : Options VM

Forcer le boot sur le BIOS virtuel afin d’effectuer quelques opérations :

Nous allons bloquer la possibilité de débrancher les périphériques de stockage et réseau :

Ce que nous voulons éviter…

Cliquez sur « Modifier la configuration » :

Ajouter une ligne : devices.hotplug false

NOTA BENE : la ligne « devices.hotplug false » n’empêche pas l’ajout de RAM / CPU et disque à chaud sur la machine virtuelle.

A ce stade, vous pouvez valider la création de la machine virtuelle.

Modification dans le BIOS :

Démarrez la machine virtuelle afin d’arriver au BIOS, allez dans le menu « Advanced » via les flèches directionnelles du clavier :

Ensuite : allez dans « I/O Device Configuration » (touche Entrer):

Passez tout en « Disabled »

Pensez à sauvegarder avant de quitter le BIOS 😉 :
« Exit Saving Changes »

Éteindre la Machine Virtuelle.

Éditez la VM pour ajouter un ISO de Windows dans le lecteur virtuel (pensez à cocher la case « Connecter lors de la mise sous tension »).

Sélectionnez votre ISO Windows Server 2012 ou 2016 ou 2019 ou 2021 etc … :p

Etape Supplémentaire pour le PVSCSI :

Démarrer votre VM, lancer le Setup d’installation etc….. :

Lors de la sélection de l’emplacement d’installation de Windows, il n’y aucun disque de visible. Celui ci n’est pas visible car l’image de boot de Windows ne contient pas les drivers pour les contrôleurs PVSCSI.

Retournez sur le vCenter, Éditez votre VM actuellement allumée, puis allez changer de DVD de Windows pour mettre les VMWare Tools à la place du DVD Windows Server.

Retournez sur votre VM et cliquez sur « Load drivers » ou « chargez un driver »

Puis « Browse » ou « Parcourir »

Allez chercher le driver dans l’ISO des VMware Tools :

Vous devriez  voir le driver « PVSCSI Controller » apparaître comme ci-dessous :

Votre disque dur va apparaître comme par magie !

Le message d’erreur indique juste qu’il faut « réinsérer » le disque d’installation de Windows Server (remplacer le disque des VMware Tools via celui de Windows sans éteindre la machine virtuelle). Vous pouvez cliquer sur «refresh», le message va disparaître.
Vous pouvez continuer votre installation de Windows.

Fin :

A la fin de l’installation pensez à faire ceci :
– Installer les VMware Tools (obligatoire car le driver des VMXNET3 ne sont pas inclus dans Windows)
– Supprimer le lecteur de DVD

Votre Machine Virtuelle est prête. Windows peut être configuré.


Superviser l’utilisation de la bande passante d’une Machine Virtuelle

Objectif :

Avoir une alarme du vCenter (via Email ou Notification) lorsqu’une machine virtuelle devient un peu trop bavarde sur le réseau. La sonde va « regarder » l’utilisation réseau de la carte virtuelle que se soit en sortie ou en entrée et lancer une alarme en fonction d’un seuil qu’on aura définie.

Pré requis :

  • Accès au vCenter (version flash)
  • Une machine virtuelle

Lets go !

1) Connectez vous au vCenter, puis allez dans la vue « VM et modèle » sélectionnez une Machine virtuelle. Dans mon cas j’ai sélectionné notre serveur WSUS.

2) Allez dans l’onglet « Gérer » puis « Définitions des Alarmes »

3) Cliquez sur le petit « + » vert 4) Renseignez un nom d’alarme, une description. Laissez les autres options sélectionnées puis cliquez sur « suivant ».

5) Cliquez sur le « + » vert pour ajouter une condition.

6) Sélectionnez la condition « Utilisation du réseau VM » puis définissez un seuil d’alarme pour l’avertissement puis pour la condition critique. ATTENTION : C’est un seul en Ko/s ! Personnellement, j’ai définie un seuil à 7000Ko/s et 12000Ko/s sur une durée de 5 minutes, mais c’est en fonction de votre besoin.

7) Cliquez sur le « + » vert pour ajouter une action

8) Sélectionnez l’action « Envoyer un e-mail de notification », puis renseignez l’email dans la colonne « configuration » .
Vous pourriez très bien en choisir une autre comme « Eteindre la VM » etc… Vous pouvez aussi ajouter plusieurs actions… etc.

9) Cliquez sur « Terminer » . Votre Alarme est prête !

Sachez que vous pouvez créer ce genre d’alarme sur un répertoire de machine virtuelle pour superviser l’ensemble des VM de ce dossier.
Exemple ci dessous avec le répertoire « Database »