PI Services

Le blog des collaborateurs de PI Services

Renommage des ressources d’une VM suite à un déploiement par SCVMM

 

Lorsque vous déployez une machine virtuelle par VMM, celle ci est préfixé au niveau du nom par SCVMM. La ressource Virtual Machine Configuration est également préfixée.

Voici un script qui va se charger de renommé les ressources comme ci celle ci avaient été déployé depuis Hyper-V /Failover Clusters et non VMM.

image

 

 

Code:

Param ([string]$VM, [string]$MonCluster)

if (($VM -eq $NULL) -or ($MonCluster -eq $NULL))
{
    write-host "Il manque un argument" -f yellow
}
else
{
    $VM=$VM.ToUpper()
    get-cluster $MonCluster
    if ($?)
    {
        get-cluster $MonCluster | Get-ClusterGroup -Name "SCVMM $VM Resources"
        if ($?)
        {
            (get-cluster $MonCluster | Get-ClusterGroup -Name "SCVMM $VM Resources").name=$VM
            if ($?)
            {
                sleep -s 2
                ((get-cluster $MonCluster | Get-ClusterGroup -Name "$VM" | Get-ClusterResource) |?{$_.resourcetype -eq "Virtual Machine"}).name="Virtual Machine $VM"
                ((get-cluster $MonCluster | Get-ClusterGroup -Name "$VM" | Get-ClusterResource) |?{$_.resourcetype -eq "Virtual Machine Configuration"}).name="Virtual Machine Configuration $VM"
            }
            else
            {
                write-host "Renommage du Groupe de Ressource echouer" -f yellow
            }
        }
        else
        {
            write-host "Groupe de Ressources pas trouver" -f yellow
        }
    }
    else
    {
        write-host "Cluster pas trouver" -f yellow
    }
}

Nested Hyper-V sous Windows server 2016 TP5 : erreur au démarrage d’une machine virtuelle

 

Si vous rencontrer sous cette erreur en démarrant une machine virtuelle en utilisant la fonctionnalité Nested sous TP5

 

image

 

Cela est du au faite que votre Hyperviseur hôte n’est pas dans la bonne version de Build.

Pour que ce message n’apparaisse plus, il faut que la version de l’Hyperviseur hôte démarrant des VM Hyper-v TP5 soit également en version TP5.

Création d’une application virtuelle pour SCVMM 2012

Pour créer notre package d’application virtualisée, vous devez installer une machine qui servira de référence.

Cette machine doit se rapprocher le plus possible en terme de configuration (registre, ..) de l’environnement sur lequel sera déployé votre application virtualisée.

Connectez-vous sur cette machine et installer le séquenceur App-V.

Les binaires sont disponibles dans la librairie VMM (Application Framework)

image

L’application permettant la capture est désormais installée.

image

Lancer l’application et cliquer sur Create a New Virtual Application Package

image

 

Cliquer sur Next

clip_image001

 

Sélectionner l’application à virtualiser. Dans notre exemple, nous allons installer Filezilla.

Cliquer sur Next

image

Donner un nom à votre Package et cliquer sur Next

image

image

 

L’installation démarre. Procéder à l’exécution de votre application avec les paramètres tel que vous désirez que ceux-ci soient capturés.

image

Une fois l’application installée, vous pouvez procéder à d’autres modifications sur la machine. Ceux-ci seront capturés.

Cliquer maintenant sur I am finished installing et cliquer sur Next

image

image

Cliquer sur Next

image

image

Cliquer sur Close

image

Vous avez maintenant fini de capturer votre application. Il faut maintenant sauvegarder votre projet.

Cliquer sur File et Save as

image

image

Le package est désormais créé. Il ne vous reste plus qu’à déplacer votre package dans la librairie VMM.

image

image

 

Dans ce blog, vous pourrez trouver un exemple d’une installation d’application virtualisée à travers un Update de service  de type In-Place dans VMM 2012

http://blog.piservices.fr/post/Mise-a-jour-de28099un-service-dans-SCVMM-2012.aspx

Mise à jour d’un service dans SCVMM 2012

 

Nous avons une VM associée à un service. Nous allons ici mettre à jour le service en installant une application virtualisée : SumatraPDF

Notre service nommé Generic Server 2K12 a été installé à partir du service Template ST –Generic Server 2K12.

image

Pour mettre à jour notre service, nous allons dupliquer le service Template ST –Generic Server 2K12, effectuer notre modification sur celui-ci et ensuite l’appliquer à notre service en production.

Aller sur le service Template à éditer

image

Faites un clic droit et cliquer Copy

image

Une copie apparait dans la console.

image

Sur celui-ci à l’aide d’un clic droit allez dans Open Designer

image

La fenêtre d’édition du service Template apparait

Double-cliquer sur votre service Template

image

 

Aller dans la section Application Configuration et cliquez sur Add et sélectionner Virtual application

image

 

Cliquez sur Browse

image

Sélectionner votre Package. Pour l’exemple, nous allons sélectionner notre package correspondant à SumatraPDF.

Cliquez sur OK.

image

 

Donnez un nom à votre application virtuelle et cliquez sur ok.

image

Cliquez maintenant sur Save and Validate.

image

 

Faites maintenant un clic droit sur le service Template dupliqué et cliquer sur Publish.

image

Nous allons maintenant appliquer notre service Template sur le service en production.

Remarque : pour que la modification apportée sur le service soit effective, il faut que la/les VM présente sous le service dispose(nt) de l’agent App-V. (Celui-ci est présent dans la librairie VMM)

Affichez les services et faites un clic droit sur le service à updater et sélectionner Set Template

image

Cliquez sur Browse pour sélectionner le service précédemment configuré.

image

 

Cliquer sur Next

image

Sélectionner Apply updates to existing to virtual machines in-place et cliquer sur Next.

Cocher la case Apply the updates et cliquer sur Next puis sur Finish

image

Le job se lance.

image

Une fois celui-ci finit, rendez vous sur la / les VMs concernés.

SumatraPDF s’est bien installé sur l’ensemble des VMs de notre service.

image

SCVMM 2012 Computer already exist lors d’un Scale-Out de service

Vous souhaitez déployer une seconde instance de votre service avec un nom prédéfinit mais lorsque vous vous apprêtez à déployer votre VM, un message d’erreur apparait :

image

Cependant, dans votre Cloud privé, aucune machine virtuelle de ce nom n’est présente.

Pour remédier à ce problème, il est nécessaire d’accéder à la base de donnée VMM sur le serveur SQL et de supprimer l’entrée présente avec ce nom de VM.

Connecter vous sur votre base de donnée VMM

image

Aller sur la table tbl_WLC_VMDeploymentConfig

image

Editer la table et rechercher la colonne ComputerName et identifier votre nom de VM posant problème.

image

Supprimer la ligne du tableau.

image

Le problème de la VM déjà existante lors du Scale-Out dans VMM n’apparait plus. La VM peut être déployée.

image

Création et affectation d’un Switch convergé depuis SCVMM 2012

Nous allons ici créer un Switch Logique au travers de VMM et l’affecter à notre hôte Hyper-V.

L’affectation du Switch via VMM  va créer dans notre exemple le Teaming des cartes ainsi que les différentes VNICs avec la QOS associé.

Dans VMM, Créer un nouveau Port Profile

image

Donner un nom à ce nouveau Profil et sélectionner la configuration de Teaming que vous désirez créer pour vos hôtes Hyper-V en sélectionnant Uplink port profile et en sélectionnant le mode de Teaming souhaité et son algorithme de Load Balancing.

image

Sélectionner les différents Network Site que vous souhaiter intégrer a votre Port Profile et cocher Enable Windows Network Virtualization.

image

Le résumé de vos actions apparait.

Cliquer sur Finish

image

 

Nous allons maintenant créer un Logical Switch.

image

 

Cliquer sur Next

image

 

Donner le nom du Switch virtuel et cliquer sur Next.

image

 

Cliquer sur Next

 

image

 

Sélectionner Team et cliquer sur Add

image

Sélectionner le Port Profile précédemment créé et cliquer sur Ok.

image

Cliquer sur Next

image

Dans l’onglet Virtual Port, cliquer sur Add

image

Sélectionner les virtuals ports comme sur l’exemple ci dessous via le bouton Add.

(Ces virtuals ports sont nativement présent dans VMM et détiennent des Bandwidth Weight qui définiront notre QOS)

image

 

image

image

 

Cliquer sur Next

image

 

Cliquer sur Finish

image

 

Nous allons maintenant affecter à notre hyperviseur le Switch Logique précédemment créé.

Sélectionner votre Hôte et afficher ses propriétés.

image

 

Aller dans l’onglet Virtual Switches

image

Sélectionner New Logical Switch

image

 

Ici sélectionner les différentes interfaces réseaux devant participer à la configuration de votre Switch.

image

 

Nous allons maintenant ajouter 3 VNICs pour notre exemple qui permettront d’avoir des VNICs nécessaire pour notre cluster Hyper-V :

  • VNIC Cluster
  • VNIC Live Migration
  • VNIC Management

Cliquer sur New Virtual Network Adapter de manière à ajouter des VNICs

image

Procéder à la configuration de votre VNIC

image

Procéder de même pour les autres VNICs et cliquer sur OK.

image

 

Un message apparait. Cliquer sur OK

image

 

Votre Hyperviseur applique la configuration de votre Switch Convergé poussé depuis VMM.

Nos 3 VNICs sont maintenant apparue sur notre Hyperviseur.

image

 

Ces 3 VNICs détiennent également les configurations réseaux qui ont été appliqués.

image

Hyper-V – Erreur “Logon failure : the user has not been granted the requested logon type at this computer” sous Windows Server 2012 R2

Contexte

Dans Hyper-V sous Windows Server 2012 R2 vous obtenez l’erreur “Logon failure : the user has not been granted the requested logon type at this computer” lorsque vous tentez d’éteindre ou allumer une VM.

2014-07-17_180510

Problématique

Cette erreur intervient même lorsque l’utilisateur fait partie du groupe “Hyper-V Administrators”.

L’erreur dans le journal d’évènements Windows (Applications and Services Logs / Microsoft / Windows / Hyper-V-VMMS / Admin) est la suivante :

Error 15500 : “VM” failed to start worker process: Logon failure:the user has not been granted the requested logon type at this computer. (0x80070569). (Virtual machine ID <GUID>)

2014-07-29_180732

Cette erreur est due à une GPO qui ôte un droit au compte d’Hyper-V.

Solution

Pour résoudre ce problème, il faut donc identifier et modifier la GPO qui change les droits en lui ajoutant NT Virtual Machine\Virtual Machines au droit Log on as a service ou exclure le serveur Hyper-V de la GPO.

Il existe également une solution à court terme qui permet de contourner le problème. Pour cela il faut redémarrer le service Hyper-V Virtual Machine Management depuis la console Services. Le redémarrage de ce service n’a pas d’impact sur les machines virtuelles (qu’elles soient allumées ou éteintes).

2014-07-17_180610

Création d’un Virtual Switch Hyper-V de type réseaux convergé en Powershell

 

Ici, nous allons voir comment créer un Switch virtuel Hyper-V de type convergé.

Sur un unique Switch virtuel Hyper-V, nous allons ici créer plusieurs Management OS qui permettront de séparer de façon logique via différences vNICs, des réseaux de type Live Migration, Cluster, Management ou autres.

image

 

Dans notre exemple, nous créons tout d'abord le switch virtuel Hyper-V.

New-VMSwitch "SwitchVirtuel" -MinimumBandwidthMode weight -NetAdapterName "NICsTeam" –AllowManagement $false

image

Nous allons maintenant ajouter 3 vNICs.

vNIC LiveMigration
Add-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "SwitchVirtuel"


vNIC Cluster
Add-VMNetworkAdapter -ManagementOS -Name "Cluster" -SwitchName "SwitchVirtuel"


vNIC Management
Add-VMNetworkAdapter -ManagementOS -Name "Management" -SwitchName "SwitchVirtuel"

Dans l’affichage des cartes réseaux, trois nouvelles interfaces virtuelles sont apparues :

image

 

Maintenant afin de contrôler les différents flux réseaux véhiculés par ces interfaces, nous pouvons appliquer à chacune d’entre elle une politique de QOS.

QOS vNIC LiveMigration
Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20

QOS vNIC Cluster
Set-VMNetworkAdapter -ManagementOS -Name "Cluster" -MinimumBandwidthWeight 30

QOS vNIC Management
Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 50

Remarque : la somme des Weights ici appliqués est de 100. (Ceci est hautement recommandé mais non requis d’avoir une somme à 100).

A l’aide de la commande Get-VMNetworkAdapter –ManagementOS vous pouvez voir les différentes vNICs créés. (non visible depuis l’interface graphique Hyper-V).

image

Configuration du Live Migration Settings dans un cluster en Powershell

 

Depuis la console de gestion Failover Cluster Manager, il est facile de sélectionner les réseau devant être utilisé par le Live Migration.

Allez sur Network ==> clique droit Live Migration Settings

image

 

Et il ne vous reste plus qu’a sélectionner les interfaces réseaux souhaitées.

image

 

Maintenant pour effectuer la même opération en Powershell, veuillez taper:

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-Object {$_.Name -notmatch "LM" -and $_.Name -notmatch "VN -"}).ID))   

Dans le filtre de la commande:

Where-Object {$_.Name -notmatch "XXX" -and $_.Name -notmatch "XXX"}).ID))

Veuiller taper comme valeurs pour les XXX une partie de la chaine de caractère du nom matchant vos interfaces réseaux afin de les identifier.

Hyper-V et NetApp – Retour d’expérience

Introduction

Dans le cadre d’une migration de stockage, j’ai été amené à utiliser différents outils de NetApp (SnapDrive, SnapManager…).

Dans ce billet je ferai une brève présentation des différents outils utilisés ainsi que mon retour d’expérience quant à l’utilisation de ces derniers.

Environnement

L’environnement source se compose de différents serveurs Hyper-V (sous Windows Server 2008 R2 SP1 et Windows Server 2012). Toutes les machines virtuelles se trouvent sur un stockage en local.

Dans un souci de PRA / PCA, l’environnement cible se composera de différentes baies NetApp réparties sur deux sites différents. Les machines virtuelles sont donc basculées du stockage local au stockage sur la baie.

Les baies NetApp serviront également de sauvegarde.

Outils

Différents outils NetApp sont utilisés dans l’environnement cible.

SnapDrive est l’outil qui permet d’interagir entre le système d’exploitation et la baie de stockage. Il peut ainsi générer des snapshots consistants du point de vue du système d’exploitation en s’appuyant sur des fonctionnalités telles que VSS.

SnapManager for Hyper-V (SMHV) permet de réaliser des snapshots des machines virtuelles hébergées par les hosters.

OnCommand permet de gérer le stockage des baies.

Retour d’expérience

 

Installation et migration

L’installation et la configuration des outils sur les serveurs Hyper-V se font simplement. L’attachement des volumes sur la baie se fait via SnapDrive.

2014-06-20_141253

La migration des machines virtuelles sur la baie se font ensuite grâce à la fonctionnalité Live Migration d’Hyper-V (pour plus d’informations sur la Live Migration suivre ce lien http://technet.microsoft.com/en-us/library/jj134199.aspx).

Mise en place des sauvegardes

La mise en place des sauvegardes se fait en via SMHV. On associe des règles à l’hyperviseur pour les sauvegardes.

2014-06-20_142008

Les sauvegardes via NetApp se font de deux façon différentes : application consistent et le crash consistent.

L’application consistent utilise VSS au niveau de la VM afin d’assurer une consistance au niveau application. A l’inverse le crash consistent utilise VSS au niveau du hoster. Il n’y a donc pas de consistance au niveau applicatif.

N.B : Les sauvegardes de types application consistent ne fonctionnent pas avec des machines virtuelles possédant des bases de données (cela inclut également les contrôleurs de domaine). Pour ces VMs les sauvegardes seront faites qu’en crash consistent, ce qui réduit les possibilités au niveau restauration (restauration à chaud impossible par exemple). Il peut-être alors intéressant de mettre en place système de sauvegarde différents en parallèle afin d’avoir plus de fonctionnalités en cas de restauration.

L’intégration de SnapManager for Hyper-V avec OnCommand se fait uniquement ligne de commande via SnapDrive.

Cette intégration permet par exemple, la gestion automatique des sauvegardes. Dans le cas rencontré, une fois les sauvegardes effectuées une copie des données est envoyée sur la baie du site distant.

 

Conclusion

La mise en place des outils NetApp sur les serveurs Hyper-V est rapide. Les bascules des machines virtuelles du stockage local vers la baie de stockage s’avèrent beaucoup plus longues (cela dépend de la taille de la VM bien entendu). Il faut compter 30 minutes pour l’installation des outils NetApp et 15 minutes pour la migration d’une VM faisant une centaine giga-octets.

N.B : Ces estimations peuvent variées en fonction de l’environnement (vitesse des disques, temps de redémarrage des serveurs…).

La migration des VMs peut se faire à chaud via la Live Migration, ainsi la production n’est pas impactée.

Les sauvegardes des VMs sont faites assez rapidement (les sauvegardes sont uniquement basées sur le delta entre la dernière sauvegarde et l’état actuel de la VM). Une sauvegarde d’une dizaine de machines prend une dizaine de minutes en application consistent et prend quelques minutes (1-2 minutes) en crash consistent.

La réplication de la baie principale à la seconde baie prend du temps lors de la première réplication (cette initialisation doit être faite en ligne de commande sur le contrôleur de la seconde baie).

N.B : Dans le cadre du projet, cette étape s’est faite avec les baies sur le même site pour augmenter la vitesse de copie (environ 20 minutes pour 100 Go de données). Une fois les baies sur les différents sites la vitesse sera plus lente (le lien réseau entre les sites n’étant pas du gigabyte) mais les données à transférer seront moindre (delta uniquement).

Les restaurations peuvent se faire à chaud (sauvegarde de type application consistent uniquement) sur le même hoster ou en récupérant les fichiers (sur le même hoster ou un hoster différent).