PI Services

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.

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>)

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).

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.

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

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

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 :

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).

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

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

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.

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.

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.

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).

Lors de la mise au point d’une maquette sur un poste portable, il est pratique d’avoir en local des templates au format VHD. Dans ce post nous verrons comment créer des templates au format VHD ainsi que comment les déployer à l’aide d’HYPER-V.

Créer un template au format VHD

Tout d’abords il faut créer une machine virtuelle avec l’OS désiré pour le template, il est également pertinent de passer les derniers patchs ainsi que d’installer la dernière version des services d’intégrations HYPER-V. Il est également possible d’installer des applications qui seront utiles au master.

• Un fois la VM prête pour être transformée en template, il serait judicieux d’éteindre la VM et d’en copier le VHD (avant l’exécution du sysprep) afin de pouvoir recréer le Template si celui-ci venait à être mis à jour.
• Après avoir démarré la VM, il faut maintenant exécuter le sysprep sur celle ci en prenant bien soir de cocher la case generalize afin de générer un nouvel SSID lors de l’utilisation du template.

• Une fois la VM éteinte, il faut en copier le VHD vers l’emplacement souhaité, il est par ailleurs préférable d’ ajouter l’attribut Read-Only au VHD généré.

Utiliser un template VHD dans HYPER-V

En utilisant HYPER-V, il est très simple de déployer un OS à l’aide d’un VHD, pour ce faire il suffit de suivre l’assistant de création d’une machine virtuelle et une fois arrivé à la page Connect Virtual Hard Disk il faut utiliser un VHD existant et ne pas laisser HYPER-V en créer un automatiquement :

Contexte

Lors de la préparation de déploiement de contrôleurs de domaine virtualisés, j’ai souhaité embarquer dans un Template déjà existant un export média d’Active Directory, le tout dans le but de réaliser une “Install From Media” (IFM) afin de réduire le temps de la première réplication et aussi économiser de la bande passante.

Les étapes

Pour réaliser cette opération, j’ai suivi les grandes étapes suivante:

1. Export de l’AD de production dans un répertoire
2. Déploiement du Template OS (déjà utilisé pour d’autres services)
3. Copie de l’export dans le répertoire souhaité de la VM
4. Arrêt de la machine Virtuel
5. Tentative de création du Template

Création du Template

Une fois la machine arrêter, il est possible de générer le Template, cependant la création du Template au travers de SCVMM échoue a 49%:

En analysant le statuts de création du Template on remarque que ce dernier échoue a 99% de la partie Sysprep:

et ce même après plusieurs tentatives sur différents hôtes et différentes librairies:

La cause

Dans le cas présent, le mécanisme sysprep exécute la commande sysprep /generalize.

Pour rappel, il n’existe aucune limite au nombre d’exécutions de Sysprep sur un ordinateur. Cependant, l’horloge de l’Activation de produit Windows commence son décompte la première fois que Windows est lancé. Vous pouvez utiliser la commande sysprep /generalize pour réinitialiser l’activation du produit Windows à trois reprises maximum. Après trois exécutions de la commande sysprep /generalize, l’horloge ne peut plus être réinitialisée.

Les solutions

Afin de palier a ce type de problème, vous pouvez:

• Recréer une machine virtuel et refaire le Template
• Modifier le comportement de “Microsoft-Windows-Security-Licensing-SLC” via le paramètre SkipRearm positionner sur la valeur 1
• Utiliser les fonctionnalités de déploiement de machine virtuelle pour y ajouter la copie de fichier a la première ouverture de session.

Pour rappel, il existe un outils permettant de réaliser les mises a jours des Vhd offline, des Templates ainsi que des machines Offline des librairie VMM. Virtual Machine Servicing Tool (VMST). Pour plus d’information http://technet.microsoft.com/en-us/library/cc501231.aspx .

Les news sur Windows 8 s’enchainent et une bonne nouvelle vient de sortir :

Hyper-V sera intégré dans la version cliente de Windows 8 ! (En effet jusque là Hyper-V était réservé aux versions serveurs)

D’autres informations ont filtré comme la configuration matérielle du poste client qui devra respecter les pré-requis suivant:

• Processeur gérant le SLAT (Second Level Address Translation)
  • Extended Page Table chez Intel (disponible dans les processeurs Intel Core i3, i5 et i7)
  • Rapid Virtualization Indexing chez AMD (aussi nommé AMD-V Nested Paging et disponible dans les processeurs AMD de la génération “Barcelona” – Phenom II … )
• 4 GB de RAM (au minimum)
• Version 64 bits de Windows 8

De nouvelles fonctionnalités apparaissent :

• Live Storage Move : Déplacement à chaud du VHD de la VM vers un autre disque local, un support USB ou un partage réseau)
• Support du WiFi lors de la création de vSwitch externe
• Apparition d’un nouveau format VHDX (qui permettrait d’avoir des disques de 16 To - Cette dernière info n’est pas officielle).
• Support de l’USB, de l’audio et de l’accélération graphique dans les machines virtuelles (ndlr : très probablement une reprise ou une évolution de la technologie RemoteFX apparue avec 2008 R2 SP1)

N.B. : Ce dernier point nécessite d’utiliser le client connexion Bureau à distance RDC (Remote Desktop Connection).

Des améliorations ont été également réalisées sur le matériel pris en charge dans les machines virtuelles invitées (guest VM) :

Note : Les fonctionnalités d’ajout de mémoire à chaud (Dynamic Memory) et d’ajout de disques à chaud (nécessite un contrôleur SCSI virtuel) sont bien sûr toujours présentes.

Virtual PC et le XP Mode semblent donc vivre leurs derniers jours…

Pour plus d’informations : http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

Microsoft a mis en ligne un poster résumant les différents possibilités offertes par Hyper-V R2.

Le poster est au format PDF et peut être téléchargé ici.

Extrait sur le CSV (Cluster Shared Volume):

Microsoft à mis en ligne le Service Pack 2 de Microsoft Application Virtualization (App-V) 4.5.

Parmi les nouveautés, nous avons :

• Récupération après incident (disaster recovery)
• Support de la haute disponibilité de l’infrastructure avec le support des bases de données SQL en miroir (SQL Mirroring)
• Support des réplications inter-site
• Compatibilité avec le déploiement d’Office 2010.

Pour le télécharger, c’est par ici.

Pour de plus amples informations, vous pouvez consulter la « release note », la documentation, ainsi que la « FAQ (.docx)».

La version 3.0 est désormais disponible en Beta Release. Pour rejoindre le programme de beta-test, il suffit de suivre ce lien.

Pour rappel, cet outil permet de déployer des mises à jours de sécurité sur des machines virtuelles non démarrées au sein des bibliothèques de SCVMM.

La version 3.0 peut maintenant gérer :

1. Les VMs éteintes dans les bibliothèques SCVMM.
2. Les VMs arrêtées ou en état sauvegardé (Save State) sur les serveurs hôtes.
3. Les templates des machines virtuelles.
4. Les disques durs “Offline” au sein de bibliothèques SCVMM par injection de packages de mise à jour.
5. Les serveurs HyperV 2008 R2 en “Failover Cluster”.

VMST 3.0 est développé pour fonctionner avec SCVMM ou SCVMM R2, ainsi qu’avec les technologies suivantes :

1. Windows Server Update Services (WSUS) 3.0 SP1 ou WSUS 3.0 SP2.
2. System Center Configuration Manager (SCCM) 2007 SP1, SCCM 2007 R2, or SCCM 2007 SP2.