Partagez l'article

Connexion






Mot de passe oublié ?
Identifiant oublié ?
Pas encore inscrit ? Créer un compte

Up-coming events

There are no up-coming events

Management des environnements virtuels

Cette section regroupe les informations sur les solutions de management des environnements virtualisés. Proposez vos articles ou de nouvelles catégories pour cette section.



Automatiser la migration de vos machines virtuelles avec SCVMM 2008R2 (Part 1-2) PDF Imprimer Envoyer
Note des utilisateurs: / 3
MauvaisTrès bien 

System Center Virtual Machine Manager 2008 R2 (SCVMM) – Automatiser la migration de vos machines virtuelle (Part 1-2)

Source Technet par Cédric Bravo.

SCVMM 2008R2 est un outil fantastique qui permet la gestion des fermes de serveurs de virtualisation ainsi que les machines virtuelles associées.

Il facilite la gestion des fermes de serveurs Hyper-V, Virtual Server, Vmware VI3 et notamment la prise en charge des environnements de clusters de virtualisation.

 


 

Basé sur Powershell, l’installation de la console d’administration de SCVMM 2008 R2 ajoute plus de 130 Command Let Additionnels dédiés à la gestion des machines virtuelles.

 


Très simples à prendre en main, ces nouveaux command let permettent de réaliser des scénarios  d’automatisation complexes.

 

Scénario : Automatiser la migration de vos machines virtuelles d’un cluster à un autre

Dans le cadre d’une migration depuis un Cluster Hyper-V 2008 R1 vers un nouveau cluster Hyper-V 2008 R2, vous souhaitez automatiser le déplacement de vos machines virtuelles.

Le processus de migration est long et fastidieux. Les contraintes sont fortes et il est souvent nécessaire de procéder en horaires non ouvrés pour assurer le transfert de vos machines virtuelles.

Heureusement, PowerShell et les différents Cmdlet de SCVMM 2008 R2 permettent d’automatiser ces tâches efficacement en quelques lignes.

 

Se connecter au serveur SCVMM.

Pour exécuter des commandes SCVMM, il est nécessaire d’établir une connexion au serveur à l’aide du Cmd-Let « Get-SCVMMServer »

La connexion au serveur SCVMM est un pré requis systématique à toute commande SCVMM.

PS>get-VMMServer "Myserver"

 


Une fois la connexion invoquée, celle-ci est valable pendant toute la session Powershell.

 

Identifier les machines que vous souhaitez migrer.

Avant de réaliser votre script de migration il est nécessaire d’identifier la liste des machines virtuelle à déplacer.

Dans le cadre d’une migration depuis un serveur Hyper-V R1 vers hyper-V R2, vérifier les points suivants :

·         Retirer les images ISO montées dans le lecteur CDROM de la machine virtuelle.

·         Supprimer tous les points de restauration. Pour compléter la fusion des disques différentiels utilisés par les points de restauration, vous devez stopper la machine virtuelle et attendre que la fusion soit complétée.

Note : l’état d’avancement de la fusion des disques n’est pas disponible dans SCVMM, vous devez consulter la console Hyper-V.

Une fois votre liste constituée et vos machines vérifiées, vous pouvez concevoir votre script de migration. Dans un premier temps, nous allons concevoir un script capable de migrer un seule machine, puis, dans la deuxième partie de cet article, nous l’adapterons pour qu’il soit en mesure de migrer toutes les machines définie dans notre fichier.

Pour réaliser cette opération,  nous avons besoin de passer par les étapes suivantes.

 

Etape 1 : Créer un GUID de Job SCVMM

Dans le monde du scripting, les commandes sont exécutées lignes par lignes de manière séquentielle.

SCVMM possède un système de commande « asynchrone », c'est-à-dire qu’il est possible de récupérer la main directement après la prise en compte d’une commande, celle-ci étant mise dans une file de tâches à exécuter en arrière plan, les « Jobs SCVMM ». Certaines commandes SCVMM nécessitent d’êtres groupées au sein d’un même job pour fonctionner. SCVMM assure de manière transparente l’ordonnancement de ces tâches.

Dans SCVMM, chaque job est caractérisé par un identifiant unique, le GUID, pour assigner des tâches à un job, il suffit de lui assigner un identifiant unique.

Pour créer ce GUID, il est nécessaire d’utiliser la classe Dot Net  [System::Guid]

P>$NewJobGroup = [System.Guid]::NewGuid()

 

Etape 2 : Stopper la machine virtuelle.

Lors d’une migration d’un cluster Hyper-V  à un autre, la machine doit être stoppée (en effet la migration live n’est disponible qu’au sein d’un même cluster). De plus le scénario illustré ici concerne le déplacement de machines virtuelles située sur un cluster Hyper-V R1, vers un cluster Hyper-V R2 (utilisant des Clustered Shared Volumes).

Dans un premier temps, nous allons récupérer l’objet qui représente notre machine virtuelle avec le Cmd-Let Get-VM, puis nous pourrons l’arrêter proprement à l’aide du Cmd-Let Shutdown-VM.

L’objet machine virtuelle ainsi récupéré pourra nous servir pour des usages futurs dans notre script.

#Récupérer l’objet machine virtuelle.

$VmName = "Nom de la machine virtuelle à stopper"

$VM = Get-Vm $VmName

#Stopper la machine virtuelle

Shutdown-VM $VM

 

Etape 3 : Reconfigurer les cartes réseau

Lors du déplacement, il est nécessaire de reconfigurer les attachements réseau des cartes virtuelles  afin de les raccorder au nouveau réseau disponible sur la machine cible.

Dans un premier temps, nous allons récupérer les objets représentant nos cartes réseaux à l’aide du Cmd-Let Get-VirtualNetworkAdapter. Puis nous utiliserons le Cmd-Let Set-VirtualNetworkAdapter pour reconfigurer la carte réseau.

Comme le nouveau réseau ne sera disponible qu’une fois la machine virtuelle déplacée sur le nouveau serveur Hyper-V, nous allons préciser que nous souhaitons une exécution asynchrone et assigner la reconfiguration de notre carte au GUID de job récupéré précédemment.

Le paramètre « -All » du Cmd-Let Get-VirtualNetwokAdapter stipule que nous souhaitons récupérer toutes les cartes réseau de toutes les machines virtuelles gérées par SCVMM.

#Récupération des objets cartes réseau

 $VirtualNetworkAdapter = Get-VirtualNetworkAdapter -All | where {$_.name -eq $vm.name}

Set-VirtualNetworkAdapter -VirtualNetworkAdapter $VirtualNetworkAdapter –VirtualNetwork "Nom_Lan_Cible" -RunAsynchronously -JobGroup $NewJobGroup

 

Note : La variable “$_” représente l’objet en cour passé à travers le « pipe » lors de chaque itération. Ici nous récupérons tous les objets carte réseau gérés par SCVMM, puis nous filtrons ces objets pour ne retenir que ceux dont la propriété « Name » est égale à la propriété « Name » de notre objet $VM. En effet, la propriété « Name » des objets carte réseau est identique à la propriété « Name » des machines virtuelles.

La commande sera mise en file d’attente et ordonnancée automatiquement par SCVMM à la suite de la commande Move-VM que nous allons utiliser plus bas.

Attention, si votre machine virtuelle comporte plus d’une carte réseau, la variable $VirtualNetworkAdapter  ne contiendra pas un objet « Carte réseau » mais un tableau d’objet carte réseau.

Pour palier à cette éventualité, il convient de traiter le résultat comme suit.

#Récupération des objets cartes réseau

 $VirtualNetworkAdapters = Get-VirtualNetworkAdapter -All | where {$_.name -eq $vm.name}

$VirtualNetworkAdapters|Foreach{

    Set-VirtualNetworkAdapter -VirtualNetworkAdapter $_ -VirtualNetwork "Nom_Lan_Cible" -RunAsynchronously -JobGroup $NewJobGroup

}

Cependant, ce script ne fonctionne que si vos cartes sont toutes reliées sur le même réseau. Dans le cas contraire, il est nécessaire de gérer de nouvelles conditions (par exemple avec le nom du réseau sur lequel la machine est actuellement connecté, récupérable par la propriété « VirtualNetwork »)

#Récupération des objets carte réseau

 $VirtualNetworkAdapters = Get-VirtualNetworkAdapter -All | where {$_.name -eq $vm.name}

$VirtualNetworkAdapters|Foreach{

  switch ($VirtualNetworkAdapters.VirtualNetWork){

        "Nom_LAN1" {

           Set-VirtualNetworkAdapter -VirtualNetworkAdapter $_ -VirtualNetwork "Nom_Lan_Cible1" -RunAsynchronously -JobGroup $NewJobGroup

         }

        "Nom_LAN2" {

           Set-VirtualNetworkAdapter -VirtualNetworkAdapter $_ -VirtualNetwork "Nom_Lan_Cible2" -RunAsynchronously -JobGroup $NewJobGroup

         }

    }

}

Ici, nous récupérons le nom du réseau sur lequel la carte est connectée et nous la reconfigurons sur le réseau cible en fonction de ce nom. La fonction « Switch » nous permet ici de préciser une action spécifique pour différente valeur renvoyée par la propriété « VirtualNetwork »

Etape 4 : Déplacer la machine virtuelle

Voila enfin le moment de demander le déplacement de notre machine virtuelle.

Le déplacement  de la machine virtuelle est effectué grâce au Cmd-Let Move-VM en précisant le nom de la machine virtuelle ($VM.name), le serveur Hyper-V ciblé et le volume sur lequel sera stocké la machine virtuelle.

Nous n’oublierons pas non plus d’indiquer une exécution asynchrone de la commande en y associant le GUID du job créé précédemment.

Le paramètre « –UseLAN » indique que le transfert s’effectuera par le réseau.

Move-VM -VM $VM.name -VMHost $VMHost -Path "C:\ClusterStorage\Volume1" –UseLAN -RunAsynchronously -JobGroup $NewJobGroup

That’s it !

Nous venons de migrer notre première machine virtuelle entièrement à l’aide de la ligne de commande !

Ok, ne nous emballons pas trop, il reste encore à attendre la fin de la migration et à redémarrer manuellement la machine. De plus, migrer une seule machine virtuelle par ligne de commande n’est pas d’un grand intérêt.

Pour cette raison nous verrons dans la prochaine partie de cet article comment constituer une liste de machine virtuelle pour alimenter notre script et comment suivre l’avancement des jobs de façon à automatiser le déplacement  d’un grand nombre de machines.

 

Automatiser la migration de vos machines virtuelles avec SCVMM 2008 R2 Part 2-2

 

Pour les CMd-Let SCVMM, vous pouvez consulter les documents suivants.

SCVMM 2008 Scripting Guide

SCVMM Command Let Reference.

Mise à jour le Mercredi, 27 Octobre 2010 09:58
 
Comment attacher un LUN supplémentaire à une VM existante avec SCVMM dans un cluster Hyper-V PDF Imprimer Envoyer
Note des utilisateurs: / 3
MauvaisTrès bien 

Source article Technet

SCVMM est un outil fantastique qui permet la gestion des fermes de serveurs de virtualisation ainsi que les machines virtuelles associées.

Il facilite la gestion des fermes de serveurs Hyper-V, Virtual Server, Vmware VI3 et notamment la prise en charge des environnements de clusters de virtualisation.

Bien que la console d’administration graphique ne prévoie pas certains cas de figures spécifiques,  l’installation de SCVMM ajoute plus de 130 Command Let Additionnels dédiés à la gestion des machines virtuelles.

Très simples à prendre en main, ces nouveaux command let permettent de réaliser des scénarios complexes non pris en charge dans l’interface graphique d’administration.

Scénario : Ajouter un LUN supplémentaire à une machine virtuelle existante.

Sur votre SAN, vous avez créé différents RAID groups afin de refléter les différents usages et niveaux de performances souhaités. 

  • Vous avez créé des LUN sur des RAID 10 pour héberger les partitions système de vos machines virtuelles.
  • Vous avez créé des LUN sur des RAID 5 pour héberger des Données.

Lors de la création ou de la modification d’une machine virtuelle en cluster dans la console d’administration SCVMM, il n’est pas possible de répartir les différents VHD sur des LUNS différents.

Ceci est par contre réalisable avec les Command Let Powershell de SCVMM.

Ajouter un LUN à une machine virtuelle existante

Pour ajouter un nouveau LUN à une machine existante, il faut bien entendu commencer par publier ce LUN dans le bon Storage Group, créer et formater une nouvelle partition dans le gestionnaire de disque et le mettre à disposition comme ressource disque disponible dans l’interface d’administration Failover Cluster de Windows Server 2008.

Dès lors le LUN est disponible pour une attribution par SCVMM.

Note : Afin d’être en mesure d’identifier cette nouvelle partition, donnez lui un Label facilement reconnaissable dans le gestionnaire de disques (Ex : NOMDELAVM_DATA). Dans le cadre d’un cluster, n’attribuez pas de lettre  à votre nouveau disque. L’accès aux disques est géré par les volumes GUID.Pour réaliser ces opérations, votre machine virtuelle doit être en état arrêté (L’ajout de disques à chaud sera possible dans Hyper-V avec Windows Server 2008 R2).

Etape 2 : Récupérer le LUN à attacher par son label parmi les disques disponibles dans le cluster.

# récupérer l’objet Cluster SCVMM
$VMMCluster = Get-VmHostCluster
     

#Récupérer les volumes disponibles dans le cluster dont le label est celui que vous avez indiqué lors de la création de la partition

$MyLUN = $VMMCluster.AvailableStorageNode.DiskVolumes | where{$_.isClustered -eq $true}| where{$_.inUse -eq $False}| where{$_.Volumelabel -eq "LABELDUVOLUME"}

Nous récupérons un objet $MyLun qui représente mon volume à rattacher.

Etant donné que je n'assigne pas de lettre de lecteur aux volumes de mon cluster, je dois utiliser son GUID pour y accéder. Les chemins d’accès par GUID sont de la forme \\?\Volume{GUID_DU_DISQUE}.

La propriété Host HostVolumeID, me permet de récupérer le GUID utilisé en cluster. Il est préférable d’utiliser cette propriété plutôt que la propriété Name, qui peut contenir plusieurs GUID selon les cas de figures.

 

Etape 3 : Formater le chemin d'accès au volume en cluster à partir de son GUID

#Mise en forme du chemin d’accès à partir du GUID

$VolPath = "\\?\Volume{" + $MyLUN.HostVolumeID + "}\"     

Maintenant que je connais le chemin d’accès à mon nouveau volume, il ne me reste plus qu’à le rattacher à ma machine virtuelle et à créer mon disque VHD.

 

Etape 4 : Récupérer l'objet VM

$VM = Get-VM -name "Nom de la machine virtuelle"

 

 

Etape 5 : Ajouter un disque à la machine virtuelle et créer un VHD fixe

Pour créer un nouveau disque (ici un disque fixe de 40go) et le rattacher à ma machine virtuelle, j'utilise le CmdLet  New-VirtualDiskDrive. Ce command Let utilise l’objet machine virtuelle ($VM) récupéré précédemment ainsi que le chemin d’accès au fichier VHD situé sur mon nouveau LUN ($VolPath).

New-VirtualDiskDrive -VM $VM -SCSI -Bus 0 -LUN 1 -Path $VolPath -Size 40960 -Fixed -Filename "NOMDUDISQUEVHDD"    

 

Note : Dans l’exemple ci-dessus, nous attachons notre VHD à une carte SCSI, il est donc nécessaire que cette carte soit déjà présente dans la machine virtuelle.

That’s it !

Votre machine virtuelle dispose maintenant  d’un nouveau disque VHD situé sur un LUN différent.

 

 


La dépendance sur le disque est automatiquement rajoutée au niveau de la ressource cluster.

Il ne vous reste plus qu’à redémarrer votre VM et à formater votre nouvelle partition depuis la MMC Disk Management.

Pour plus de facilité, voici le script complet, il vous suffit d’affecter les bonnes valeurs aux variables.
Pour les plus téméraires, vous pouvez très facilement le transformer en fonction de vos besoins et l’intégrer directement à votre session PowerShell SCVMM.

###############################################################################
#
#                   Add-ClusteredLun SCVMM Script
#                   V1.0 du 14/04/2009
#
###############################################################################

$VMMserver   = "SERVEUR_SCVMM"
$VMname      = "NOM_DE_LA_VM"
$VolumeLabel = "LABEL_DU_VOLUME_A_ATTACHER"
$VHDName     = "NOM_DU_VHD_A_CREER" (avec extension .vhd)

$Size = “Taille DU VHD” (en Mo)

# Connexion au serveur SCVMM

get-VMMServer $VMMServer

# Récupération de l’objet Cluster SCVMM

$VMMCluster = Get-VmHostCluster     

#Récupération du volume non utilisé dans le cluster dont le label est celui que vous avez indiqué lors de la création de la partition.

$MyLUN = $VMMCluster.AvailableStorageNode.DiskVolumes | where{$_.isClustered -eq $true}|where{$_.inUse -eq $False}| where{$_.Volumelabel -eq $VolumeLabel}

# Mise en forme du chemin d’accès à partir du GUID

$VolPath = "\\?\Volume{" + $MyLUN.HostVolumeID + "}\"

# Récupération de l’objet machine virtuelle sur lequel on doit attacher le nouveau LUN

$VM = Get-VM -name $VMName

# Attachement du nouveau Disque sur la machine virtuelle.

New-VirtualDiskDrive -VM $VM -SCSI -Bus 0 -LUN 1 -Path $VolPath -Size $Size -Fixed -Filename $VHDName

Mise à jour le Vendredi, 18 Juin 2010 15:10
 
Administrer Hyper-V avec Powershell sans SCVMM PDF Imprimer Envoyer
Note des utilisateurs: / 13
MauvaisTrès bien 
Écrit par Alban CAOUREN   


Manager hyper-V 2008 R2 avec PowerShell sans SCVMM.

Update 09/08/2015 (Hyper-V 2012 intègre désormais nativement les CmdLet décrit dans ce post, il n'est plus nécessaire de récupérer le module powershell sur Codeplex).

Quand on souhaite automatiser l'administration d'une infrastructure Hyper-V sans passer par les Command-Let apportés par SCVMM il est nécessaire de passer directement par le provider WMI de Hyper-V (Cf. http://msdn.microsoft.com/en-us/library/cc136992(VS.85).aspx).


Bien que très efficace, l'utilisation de WMI peut rapidement provoquer quelques maux de têtes aux non initiés, Microsoft ne fournissant pas pour l'instant de command-let propre à Hyper-V.


Parti de ce constat une équipe de développeur dirigée par Emit James s’est mis à la tâche et a développé une librairie de fonctions "Cmd-Let" pour hyper-V directement à partir du provider WMI. Superbe initiative qui présente un double intérêt.

  1. Fournir des commandes simples pour manager Hyper-V
  2. Illustrer l'utilisation du provider WMI de Hyper-V en étudiant le source du script


Car cette librairie est en réalité un script Powershell qui une fois exécuté va mettre à  notre disposition en mémoire des fonctions utilisables comme des "cmd-let".

Actuellement en version 10b, PSHYPERV vous délivre pas moins de 80 fonctions dont voici un petit aperçu.


Machine virtuelle

  • Créer des machines virtuelles
  • Récupérer des informations des VM
  • Export/Import des VM
  • Arrêter/Démarrer des VM
  • Tester la connexion Heart Beat

Mémoire

  • Gérer la mémoire l’allocation de mémoire des VM

Processeur

  • Allouer des coeurs
  • Récupérer des informations sur le nombres de coeurs

Disque dur

  • Ajouter/Supprimer des contrôleurs
  • Récupérer des informations sur les VHD
  • Créer des VHD
  • Compacter/Convertir
  • Monter des VHD

Carte réseau

  • Ajouter des cartes
  • Supprimer des cartes


Snapshots

  • Créer / Déplacer / Supprimer / Renommer

 

Installer et exécuter la librairie de commandes pour Hyper-V

Télécharger le package composé de deux fichiers sur CODEPLEX à cet endroit : http://pshyperv.codeplex.com/

  • Hyperv.ps1
  • Hyperv.format.ps1xml

Décompresser les 2 fichiers et placez les à la racine de votre profil utilisateur.

Le fichier xml contient la définition des formats de sortie, c'est à dire la mise en forme du résultat des commandes, laisser ce fichier dans le même emplacement que le script.


Ouvrez une session Powershell (Attention assurez vous d'avoir au préalable activé l’exécution des scripts PowerShell avec la comande set-ExecutionPolicy -executionpolicy unrestricted)

Placer-vous à la racine (l’endroit où les 2 fichiers ont étés extraits)

Chargez maintenant la librairie de commande PowerShell pour Hyper-V en saisissant la commande suivante :

. .\hyperv.ps1

Le script liste l'ensemble des fonctions misent à disposition.

 

 

Vous pouvez maintenant utilisez les nouvelles commandes.

Exemple : Modifier la mémoire allouée à une machine virtuelle.

PS E:\> shutdown-vm -vm [Ma_VM] -server [Mon_Serveur_Hyper-V]
Shutdown of '[Ma_VM]' started.

PS E:\> set-vmmemory -vm [Ma_VM] -memory 1200 -server [Mon_Serveur_Hyper-V]
Set memory for '[Ma_VM]' to 1200 MB.

PS E:\> start-vm -vm [Ma_VM] -server [Mon_Serveur_Hyper-V]
Changing state of [Ma_VM]: Job Started.


Et voila !

Vous pouvez désormais facilement automatiser toutes vos opérations d'administration en quelques lignes.

 

Charger les commandes directement dans son profil Powershell.

Si vous utilisez fréquemment ces commandes il peut être intéressant de charger ces fonctions directement dans votre profil Powershell.


Le profil est tout simplement un script Powershell exécuté lors du lancement de votre invite de commande Powershell. Celui ci n'existe pas par défaut, pour le créer, ouvrez une invite Powershell et taper la commande suivante :

PS C:\> new-item -path $profile -itemtype file -force

Taper ensuite la commande suivante pour éditer le fichier profil et y ajouter l'exécution du script.

PS C:\> Notepad $Profile

 

 

De cette manière les commandes Hyper-V seront directement disponibles dès que vous lancerez une invite de commande Powershell.

Réagissez à cet article sur notre Forum.

Mise à jour le Dimanche, 09 Août 2015 13:37
 
Hyper-V / SCVMM, Activer la console depuis une machine XP. PDF Imprimer Envoyer
Note des utilisateurs: / 5
MauvaisTrès bien 

Vous avez sûrement déjà eu l'occasion de rencontrer ce problème si vous avez installé SCVMM et Hyper-V dans un environnement XP / Windows 2003.

Dans la console d'administration SCVMM ou depuis le portail de self-service (avec Internet Explorer), il n'est pas possible d'utiliser la prise de main en mode console depuis un poste XP sur une machine virtuelle qui n'est pas reliée au réseau.

Cette nouvelle console (VirtualMachineViewer.exe) qui succède au VMRC de Virtual Server R2 utilise désormais un nouveau protocole d'authentification (CredSSP) qui n'est pas activé nativement sous Windows XP.

La console de SCVMM (Virtual Machine Viewer) ainsi que le control Active X du portail de Self-Service utilisent deux modes de connexion :

  • Le mode "Computer" qui se connecte directement à la machine virtuelle
  • Le mode Host, qui accède à la machine virtuelle en passant par le Host 

Le mode "computer" nécessite que la machine virtuelle soit connectée au réseau, qu'elle possède un système d'exploitation qui accepte les connexions RDP et que les services d'intégration soient installés. C'est le mode préféré quand il est disponible.

Dans le cas du mode Host, la connexion est établie directement avec le Host Hyper-V Windows 2008, ce qui nécessite l'utilisation de CredSSP.

Pour activer le protocole CredSSP sur votre poste XP, vous devez installer le SP3 et modifier les clefs de registres suivantes :

 

1- In the navigation pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
2 - In the details pane, right-click Security Packages , and then click Modify .
3 - In the Value data box, type tspkg . Leave any data that is specific to other SSPs, and then click OK .
4 - In the navigation pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
5 - In the details pane, right-click SecurityProviders , and then click Modify .
6 - In the Value data box, type credssp.dll . Leave any data that is specific to other SSPs, and then click OK .
7 - Exit Registry Editor.
8 - Restart the computer.

 

Vous trouverez la procédure complète dans la KB ci dessous
http://support.microsoft.com/kb/951608

Mise à jour le Vendredi, 28 Décembre 2012 15:58
 
Automatiser ESX avec PowerShell et VI toolKit PDF Imprimer Envoyer
Note des utilisateurs: / 10
MauvaisTrès bien 
 

Si on me demandais quel est selon moi le language de scripting en environnement Microsoft le plus puissant du moment, je répondrai sans hésiter qu'il s'agît de PowerShell.

L'utilisation des command-let ou l'appel direct au objets .net ou com le rend adapté aussi bien aux débutant qu'aux experts les plus pointus.

PowerShell reprend le meilleur des Shell Unix associé à la puissance du modèle objet .Net, et n'a littéralement plus rien à voir avec son prédecesseur, la bonne vielle ligne de commande CMD (même si la pluspars des commandes de bases on conservé une syntaxe identique).

Grâce à sa puissance et sa simplicité d'utilisation, il n'y à aucun doute sur la formidable adhésion de ce language par les IT, d'autant plus que la pluspars des produits Microsoft de la gamme server s'appuient désormais essentiellement sur ce langage.

Quel rapport avec ESX me diriez vous ? la Service console de ESX est sous Linux et nous devrions alors plutôt parler de Kshell ou de Perl.

Ce serait pourtant oublier Virtual Center, qui permet de piloter l'ensemble des fonctions des ESX. En effet, VC tourne sous ...Windows.

Pour nous aider à manipuler les objets .Net du SDK de VI (VmWare Infrastructure), VmWare à produit ses propres cmd-Let. Vi ToolKit (VMware Infrastructure Toolkit for Windows). Ce kit comprend les cmd-let et la documentation associée.
Ce SDK à déja enthousiasmé nombre d'administrateurs et donné lieu à des développement vraiment très utilies que nous ne tarderons pas à vous proposer rapidement.

Pour rappel, les cmd-let sont des petits programmes développés en C# et qui s'appuient directement sur les objets .net.
Si vous pouvez par exemple écrire un programme powershell qui va accéder aux objets .net du SDK de VI pour faire un Vmotion... VmWare nous à simplifié le travail en "compilant ce programme" au sein d'un Cmd-Let (Move-vm) qui sera lui même utiliable dans vos scripts.

Le VI ToolKit vous permet d'automatiser à peux près tout ce qu'il est possible de faire avec VI (et certainement plus). Un fichier chm, fournis avec le kit détaille l'utilisation de plus de 120 cmd-let.


Bien sur, vous n'êtes pas obligé d'installer le Kit sur le serveur VI, vous pouvez l"installer sur votre station de travail et accéder directement à votre serveur VI par le port 443.

Pour visualiser une démonstration de l'utilisation du Vi-Toolkit, cliquez ici.

Coté Microsoft, SCVMM (System center Virtual Machine Manager)  annonce pouvoir manager des ESX, non pas directement bien sur, mais à travers un serveur VI et son SDK, la aussi la magie s'opère grace à Powershell.
Comme SCVMM est entièrement "PowerShellisé", Il devient possible de manager ses VM Hyper-v, Virtual Server et ESX à partir d'une ligne de commande (avec les Cmd-Let de SCVMM).

Un Move-Vm sous une ligne de commande PowerShell SCVMM aura alors pour effet d'effectuer le V-Motion souhaité sur notre Esx ciblé.


Alors pourquoi installer les Cmd-let VmWare si j'ai déja un serveur SCVMM dans mon datacenter ?


Et bien d'une part parce qu'il est tout à fait possible de faire cohabiter plusieures environnements PowerShell différents (plusieurs jeux de Cmd-let différents) sur la même machine (les cmd-let additionnels étant chargé au démarrage de la session), mais aussi, parce que les Cmd-Let VM-Ware sont entièrement conçu pour la gestion des ESX et ESXi et exposent l'ensembles des fonctions, ce qui n'est pas le cas des Cmd-Let SCVMM.

 

 

 

Mise à jour le Vendredi, 28 Décembre 2012 15:59
 
« DébutPrécédent12SuivantFin »

Page 2 sur 2
Bannière

Joomla! is Free Software released under the GNU/GPL License.