Sebastien.warin.fr

Introduction

Afin de vider ma liste de sujets à blogger qui s’entassent depuis plusieurs mois dans mes brouillons, je continue ma série de posts sur l’infrastructure IT. Dans mon post précédent vous avez pu apprendre que Wygwam a migré en Mars d’une infrastructure hétérogène Virtual Server 2005 / VMWare vers une architecture homogène sous Windows Server 2008 R2 avec Hyper-V et SCVMM en version 2008 R2.

J’ai donc déployé sur notre serveur “primaire” un Windows 2008 R2 Full avec System Center Virtual Machine Manager (SCVMM), un outil de la gamme System Center permettant le management centralisé de notre infrastructure virtuelle (création, configuration et déploiement des machines virtuelles, allocations des ressources, déplacement à chaud, gestion des templates de VM, etc.. etc..).

Dans notre architecture, SCVMM pilote plusieurs serveurs de virtualisation Hyper-V, véritables machines de course (Bi-Quad Core, 8 à 12 Go de DDR3 et disques SAS 15000tr/min).

Etant donné que ces serveurs de virtualisation n’ont qu’un seul rôle : virtualiser, ils ont été installé en “Server Core”. L’installation “Server Core” est un Windows Server ultra-minimaliste sans interface graphique ni bureau ou Explorateur de fichier, juste le “coeur” de Windows afin de gagner en performance, réduire la maintenance (et le nombre de mise à jour à appliquer) et par la même occasion, réduire la surface d’attaque. Cela simplifie énormément l’administration, et SCVMM me permet ensuite de gérer mon parc de VM que je repartie ensuite sur les serveurs “Core” dédiés à la virtualisation.

Cartes réseau et Réseau virtuel

Une fois mes serveurs de virtualisation installés avec en “Server Core” avec le rôle “Hyper-V” et ajoutés dans les listes “Hosts” de SCVMM, il faut créer le réseau virtuel pour connecter les VM qui tourneront dessus.

Pour bien faire, j’ai à chaque fois deux cartes réseau installées sur chaque serveur Core. Une carte réseau sera dédiée pour la machine hôte (le serveur en lui-même) et l’autre carte réseau dédiée pour les machines virtuelles.

Pour cela, dans les propriétés de chaque serveur hôte dans SCVMM, sous l’onglet “Network”, je crée un “Virtual Network” que j’attache à une de mes deux cartes réseau. Chez nous, les cartes réseau D-Link Gigabit sont utilisées pour les machines virtuelles :

En se connectant sur les “Server Core”, on retrouve toujours nos deux interfaces réseau (via un “ipconfig /all”) :

On retrouve bien une 1ère interface “Local Area Connection” sur ma carte Broadcom réservée pour le serveur hôte et la 2ème interface “Local Area Connection 4” lié au “Microsoft Virtual Network Switch Adapter”.

C’est cette seconde interface qui va servir de “switch” pour toutes les machines virtuelles.

Mais en théorie, pour faire les chose proprement, il faudrait désactiver tous les protocoles réseau sur cette interface et ne laisser que le “Microsoft Virtual Network Switch Procotol”.

Sur un serveur classique (en Full Install), on retrouve dans les propriétés de la carte réseau les différents protocoles activés pour la carte en question :

Il suffit de ne sélectionner, pour la carte dédiée aux VMs, que le protocole “Microsoft Virtual Network Switch Protocol” et surtout de désactiver les protocoles TCP/IP (v4 et v6), le client MS Network, le File Sharing, etc…

L’outil NVSPBind

Malheureusement, sur un “Server Core”, il n’y pas de véritable interface graphique. Vous ne pourrez donc pas trouver la fenêtre des propriétés permettant d’activer ou de désactiver les protocoles réseau sur une carte comme montré ci-dessus.

A la place, on trouve sur le site MSDN de Microsoft, un outil nommé : NVSPBind à l’adresse : http://code.msdn.microsoft.com/nvspbind

Comme l’indique l’introduction…

nvspbind is a tool for modifying network bindings from the command line. It is especially useful in Server Core environments with the Hyper-V role enabled.

… cet outil à spécialement été conçu pour les “Server Core” avec le rôle Hyper V installé afin de permettre de regler correctement les protocoles réseau des cartes utilisées.

Il vous faudra tout d’abord récupérer le package sur le site et l’installer dans le répertoire que vous souhaitez :

En lançant le programme”nvspbind.exe” vous obtiendrez la liste des interfaces réseau et leurs protocoles :

Pour régler correctement l’interface réseau utilisée par les machines virtuelles, il faut trouver l’interface “Internal”. Dans notre cas ci-dessous, nous avons :

• La BroadCom en “Local Connection Aera” : correspondant à la carte réseau de la machine “hote”
• La “Local Connection Aera 2” correspond au Switch Hyper-V (vms_mp)
• La D-Link en “Local Connection Aera 3” où tout est désactivé sauf le “vms_pp” : c’est la carte utilisée pour nos VMs configurée dans VMM
• La “Local Connection Aera 4”: 2ème interface réseau de ma carte D-Link configurer avec tous les protocoles (avec donc une IP attribuée comme on peut le constater dans un ipconfig).

C’est cette dernière interface, définie en “Internal” de type “vms_mp”, qui nous est inutile. Pour suivre les best-pratices, sur notre carte réseau D-Link, il ne devrait y avoir QUE le “vms_pp” utilisé pour les VMs et nous devrions désactiver les protocoles sur la vms_mp.

Comme sur la fenêtre graphique des propriétés de l’interface réseau présentée ci-dessus, il faut désactiver les protocoles :

• ms_netbios : NetBios Interface
• ms_server : File and Printer Sharing for MS Networks
• ms_msclient : Clients for MS Networks
• ms_tcpip : Internet Protocol v4 (TCP/IPv4)
• ms_tcpip6 : Internet Protocol v6 (TCP/IPv6)
• ms_netbt : WINS Client protocol
• ms_smb : MS NetBiosSmb

On peut cependant laisser les protocoles QoS Packet Scheduler (ms_pacer), et les Link-Layer Topology Discovery Mapper et Responder (ms_lltdio et ms_rspndr).

Pour cela tapez les commandes suivantes :

nvspbind /d « Local Area Connection 4″ ms_netbios
nvspbind /d « Local Area Connection 4″ ms_server
nvspbind /d « Local Area Connection 4″ ms_msclient
nvspbind /d « Local Area Connection 4″ ms_tcpip6
nvspbind /d « Local Area Connection 4″ ms_netbt
nvspbind /d « Local Area Connection 4″ ms_smb
nvspbind /d « Local Area Connection 4″ ms_tcpip

Et voilà vos interfaces réseau sur vos Windows Server Core correctement configurées

En partenariat avec

Le WygDay est une journée organisée par Wygwam et Microsoft, complètement consacré à la veille technologique. De nombreux experts de chez Wygwam et Microsoft vous présenteront un aperçu des technologies émergentes et témoigneront de leurs expériences. C’est l’occasion d’échanger directement avec eux !

Nous aborderons cette année, différents axes : Développement Visual Studio 2010, Architecture/Industrialisation, SharePoint 2010, Office 2010, Exchange 2010, Cloud Computing, Cartographie, Bing Maps, Recherche et Innovation. Pour plus d’informations sur les sessions : http://wygday.wygwam.com/Sessions.aspx

Venez nous retrouvez en vous inscrivant sur notre site WygDay 2010.

Rendez-vous le 8 juin 2010 à EuraTechnologies
165 avenue de Bretagne 59000 Lille
Métro Canteleu (Direction St Philibert – Ligne 2)
Parking gratuit et sécurisé

Pour ma part retrouvez-moi en plénière le matin à 9h, et l’après-midi pour une session sur la Stratégie et le développement Cloud à 13h30 et à 14h45 pour présenter le xBrainLab.

A demain

Toujours dans le cadre de notre migration, nous avons dû migrer des serveurs virtuels de VM Ware ESX vers Hyper-V. J’ai creusé plusieurs pistes avec ce que l’on peut trouver sur Google à ce sujet, et voici la solution que j’ai retenu pour réaliser cette tache.

Etape 1 : préparer la VM

Il faut commencer par désinstaller les VM Additions sur la machine virtuelle pendant qu’elle tourne encore sur ESX. En effet, il vous sera impossible de le faire par la suite; il vous faudra alors les supprimer à la main en suivant la KB de VM Ware ce qui est un peu moins amusant !

Ensuite, il faut supprimer vos “snapshots” (appelé Checkpoints sous Hyper-V). Via le “Virtual Infrastructure Client” (client lourd de gestion du serveur ESX), cela est relativement facile en cliquant-droit sur les VMs en question, vous pourrez accéder aux snapshots de la VM et les supprimer facilement (boutons Delete / Delete All).

En effet, la création de snapshots engendre la création à la volé d’un disque de différenciation permettant d’écrire toutes modifications sur le disque dans un fichier séparé (une sorte de disque de différentiation) dans le but de pouvoir revenir à l’instant où a été créée la snapshot. Ces snapshots engendrent donc le “splittage” du disque virtuel dans différents fichiers (dont les .delta) incompatible pour réaliser notre conversion. Le fait de supprimer ces snapshots permettra de “merger” (fusionner) votre disque virtuel en un seul fichier, le *.vmdk.

Etape 2 : récupérer l’image de la VM

Une fois notre machine virtuelle préparée (plus de VM Additions et disques virtuels “propres”), il faut récupérer le disque dur virtuel de votre VM (le .vmdk). Etant donné que vous avez accès à votre serveur ESX en SSH (serveur linux), nous pouvons utiliser SCP pour parcourir notre serveur ESX et récupérer l’image.

Dans ce but, il existe l’outil Win-SCP que j’utilise habituellement mais le taux de transfert (sur un lien Ethernet Gigabits) n’’a pas excédé 3Mo/s fort limitant pour des VMs qui pèsent entre 20 et 60Go.

En cherchant un peu, j’ai mis la main sur un outil gratuit de Veeam nommé “FastSCP” qui, comme son nom l’indique, est beaucoup plus rapide (jusqu’à 6 fois plus rapide que les autres).

Promesses tenues, j’ai pu récupérer mes images à une vitesse moyenne de 20Mo/s.

Etape 3 : convertir l’image VMWare (vmdk) vers le format Hyper-V (vhd)

Une fois notre disque virtuel récupéré sur notre poste Windows, j’ai utilisé l’excellent utilitaire WinImage en version 8 permettant très facilement de convertir un disque dur virtuel WM Ware (vmdk) en une image Hyper-V (vhd).

Etape 4 : remonter la VM sur Hyper-V

Une fois notre disque virtuel converti en VHD, j’ai remonté une nouvelle machine virtuelle Hyper-V (en utilisant System Center Virtual Machine Manager pour ma part) en spécifiant notre disque virtuel VHD fraichement converti. SCVMM s’est occupé de déployer les VM Additions d’Hyper-V automatiquement, et la VM a pu redémarrer sans aucun souci sur un hyperviseur Hyper-V.

Migration de VM Ware ESX vers Hyper-V réussie, merci à Fast-SCP, WinImage et SCVMM pour le boulot

Je me suis retrouvé il y a quelques semaines à refaire l’infrastructure IT chez Wygwam en migrant d’un environnement Virtual Server / VM Ware ESX / Windows 2003 vers un environnement full Microsoft avec Windows 2008 R2 / Hyper-V, SCVMM, SCDPM, & Co…

En supprimant proprement des contrôleurs de domaine (via dcpromo) une erreur m’en empêche  m’indiquant que des rôles FSMO ont été supprimés et n’existent plus :

Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com
FSMO Server DN: CN=NTDS Settings\0ADEL:18a67e84-64fc-4be4-97cc-e28dd0100576,CN=WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b,CN=Servers,CN=Premier-Site-par-defaut,CN=Sites,CN=Configuration,DC=wygwam,DC=com

J’ai donc sur ce pas vérifié dans la console MMC d’Active Directory, les “Operations Master” de notre domaine. Mais rien d’anormal, le ou les serveurs pour les différents rôles sont correctement configurés.

Pour creuser un peu plus loin, vous pouvez aussi vérifier voir redéfinir les bons serveurs avec l’utilitaire “NTDSUtil” (en mode “fsmo maintenance”) en suivant notamment la KB255504. Là aussi, dans mon cas, rien d’anormal, tous les rôles FSMO sont correctement configurés vers les bons serveurs comme me le confirme un “netdom query fsmo” :

En relisant l’erreur, ce qui m’a le plus perturbé, c’est le nom du serveur qui pose problème : “WYGSERVER\0ADEL:6cc8b949-b186-4120-9f6b-085c8c84806b”. WYGSERVER étant chez nous un ancien contrôleur de domaine qui nous a “lâché” il y a déjà plusieurs mois/années. Nous avions pourtant à cette époque correctement migré tous les rôles Active Directory, et supprimé complètement les objets AD et DNS vers ce serveur.

En relisant aussi ce message d’erreur, autre interrogation concernant le rôle FSMO qui pose problème : “CN=Infrastructure,DC=DomainDnsZones,DC=wygwam,DC=com”. Visiblement bien que supprimé ce rôle était toujours sous l’appartenance de l’ancien contrôleur “WYGSERVER” et je ne savais où le vérifier (par rapport aux différentes MMC pour la gestion d’Active Directory).

J’ai donc sorti l’artillerie lourde avec “ADSIEdit” pour fouiller ce qu’il y a vraiment dans notre Active Directory. Je n’ai pas tout de suite trouvé car cet objet ne se trouve pas dans les “Naming Context” connus par défaut. Il faut spécifier le “Distinguished  Name”, dans notre cas “DC=DomainDnsZones,DC=wygwam,DC=com” :

Il devient alors possible d’accéder à notre objet “Infrastruture” qui semble être à la source du problème :

En éditant les propriétés de cet objet, j’ai pu constater que l’attribut “fsmoRoleOwner” défini pointé vers notre ancien contrôleur de domaine d’où la présence du “0ADEL:xxxx” dû fait que ce contrôleur n’existait plus :

J’ai donc pu correctement redéfinir cet attribut en sous la forme : “CN=NTDS Settings,CN=<SERVER_NAME>,CN=Servers,CN=<SITE_NAME>, CN=Sites,CN=Configuration,DC=wygwam,DC=com” (en remplaçant respectivement SERVER_NAME et SITE_NAME par le nom de votre serveur et le nom de votre site AD) :

Il a fallut faire de même avec le rôle “ForestDnsZones” en éditant la valeur de l’attribut “fsmoRoleOwner” sur l’objet “Infrastructure” du schéma “CN=ForestDnsZones,DC=wygwam,DC=com”.

Une fois ces rôles correctement configurés, le retrait de contrôleur de domaine dans notre organisation ne vous posera plus de problème

Il y a un peu près un an j’écrivais sur mon blog trois articles sur l’extensibilité de Visual Studio 2008 :

• Part 1 : Comment étendre Microsoft Visual Studio

• Part 2 : créez vos fenêtres d’outils avec CreateToolWindow2 !

• Part 3 : Quelques interactions avec Visual Studio

Quelques jours après je poursuivez sur une introduction à MEF : Managed Extensibility Framework.

Le rapport ? Et bien mélangez les deux et vous aurez le nouveau modèle d’extensibilité de Visual Studio 2010 En ajoutant aussi que le nouvel éditeur de code en WPF (où l’on appréciera grandement le Zoom-In/Out lors de présentation), nous apporte des tas de possibilité en matière d’extension.

Jugez par vous même! Aurait-on pu avoir ce genre de comportement dans les versions antérieures ?

Un petit “add-in” qui remplace les chaines de caractères “wygwam” et “microsoft” par leurs logos respectifs ! Oui je sais cet add-in est inutile mais il montre bien les possibilités apportés “je fais ce que je veux où je veux…. Et en WPF”

Un petit article de présentation arrivera prochainement, en attendant retour en mode préparation des TechDays