Les changements massifs de composants techniques des enveloppes de VM (GuestOS ou Invité), sont assez rare en production. Mais il peu arriver, lié à divers problématiques d’incompatibilités de drivers vs O.S., de devoir changer massivement ce dernier.
Prenons exemple des cartes réseaux Intel compatible type E1000. Pour rappel, VMware recommande d’utiliser les drivers de cartes réseaux type VMXNetx. Ce n’est pas obligatoire mais fortement recommandé afin de conserver toute les possibilités et compatibilités offertes par l’hyperviseur ESXi.
Mais évidement il existe depuis le début de notre ère ESX, des drivers dit compatible. L’objectif est à l’origine de pouvoir réaliser des P2V d’environnements avec ces cartes réseaux temporairement. Puis d’effectuer la migration de ces cartes vers VMXNet.
Cependant, il est souvent pertinent de conserver cette compatibilité pour diverses raisons souvent liées à l’application lié au serveur qui l’héberge. Au final, on traine comme un boulet cette fameuse carte jusqu’au jour ou cela n’est plus possible.
VMware nous a donné un bon exemple l’année passée avec la version 6.5 qui ne portait plus l’une de ces cartes réseaux compatibles notamment pour les systèmes d’exploitations plus récents tel que windows 2012 et cie. Il s’agit de la carte Intel E1000.
Lorsque vous devez réaliser une montée de version de vos ESX et VCenter, vous voilà bien contrain de réaliser qui faut abandonner cette carte réseau. Il faut dire que ces cartes réseaux compatibles peuvent souvent provoquer des réactions assez curieuses. Comme la perte de la configuration réseau ou autres phénomènes de ce type, digne de la loi de Murphy.
Alors comment faire pour changer massivement ces coupleurs réseaux ? …. PowerCLI bien sur !
Mais attention qui dit “changement de carte réseau” dit “changement de drivers de carte réseau”, et signifie implicitement “nouvelle carte réseau” vu du système d’exploitation ! Il est important de bien comprendre cela !
Le système d’exploitation va découvrir une nouvelle connexion réseau sans configuration réseau particulière hormis l’habituelle DHCP.
Alors comment procéder ?
Avant toute chose il est impératif de faire ses simulations sur une VM de test dans l’infrastructure VSPhere concernée. Il est important de constater les effets de bord dû aux changements et pouvoir valider le scénario de migration.
Deux choix pour gérer massivement ce déploiement du nouveau driver de carte réseau.
1/ Soit à froid
2/ Soit à chaud
Un changement massive à froid
C’est honnêtement le mieux, mais toujours réalisable, notamment si vous ne devez pas éteindre votre serveur pendant cette phase de changement.
Comment procéder ? C’est très simple et cela se faite en seule ligne de PowerCLI. De la magie ou presque !
Ce jeu de commande permet de réaliser comme on le ferait par le WebUI de VSphere, la modification du type de carte réseau. A la différence de l’interface WebUI, cela se modifie à froid.
Mais en powerCLI on peut le faire à chaud. Par contre les modifications ne seront prises qu’au prochain démarrage à froid et c’est impératif !
L’avantage de cette opération c’est que l’on ne perd pas la configuration de la carte réseau vu par le système d’exploitation (Windows compris !)
Après s’être authentifié dans votre infrastructure VSPhere, il suffit d’exécuter cette commande, et c’est terminé !
Get-VM [Nom de VM] | Get-NetworkAdapter | Set-NetworkAdapter -type vmxnet3 -confirm:$falseA noter que pour une opération massive, il suffit via PowerShell de fournir une liste pour appliquer le changement.
Si vous souhaitez toucher toutes les VM, il suffit de ne pas fournir de nom de VM; attention aux risques !
Mais, voila c’est une opération très simple, mais elle n’hésite d’éteindre vos VM et de les redémarrer.
Un changement massive à chaud
Le scénario est assez simple sur le principe mais peut avoir des répercutions sur les parties applicatives, et les divers protections du serveurs, tel que Firewall, Antiviraux, Routage, etc.
En fonction du système d’exploitation, ce scénario peut être complexe. Notamment pour les serveurs Windows.
Pour les OS Linux, au final c’est assez simple car depuis les kernel récents la dénomination des cartes réseaux est normée. Elle est liée principalement à l’emplacement PCI et le type de driver. Ainsi on sait forcément comment se nomment les cartes réseaux type E1000, E1000e, VMXNet sous Linux. La seule chose qu’il est impératif de maitriser c’est le port PCI, c’est lui qui numérotera la carte réseau sous linux.
ATTENTION, vérifiez s’il existe des règles de renommages de cartes réseaux ! C’est également un levier qui peut vous éviter de réaliser le scénario ci-après, mais rend un votre VM non standard. Pour vérifier allez voir le fichier adapté, par exemple sous CentOS/RedHat:
vim /etc/udev/rules.d/70-persistent-net.rules.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:xx:xx:xx:xx:xx",
ATTR{type}=="1", KERNEL=="ens*", NAME="eth0"Vous l’aurez peut-être compris pour les serveurs Linux, l’astuce est de prévoir à l’avance une copie de la configuration de votre carte réseau sous le nom de la future carte réseau. Puis de changer le contenu de cette configuration en renommant convenablement le nom de la carte réseau. Si votre serveur est sous NETPLAN, c’est finalement encore plus simple, il suffit dupliquer la ligne de configuration de la carte réseau type E1000x vers une nouvelle à l’image de la VMXNetx.
Votre modification préparée, il suffit d’éffectuer les modifications à chaud tel que vous le feriez sous l’interface WebUI de VSphere.
Soit :
1/ Suppression de la carte réseau E1000 (par exemple)
2/ Ajout de la carte réseau VMXNet
Attention aux grosses configurations VSPhere un temps de latence peut provoquer un temps de prise en compte, puis de l’exécution assez long. Ce n’est pas normal dans les faits, c’est souvent dû à un problème de fonds de vo.s VCenter.s.
Pour supprimer la carte E1000 à chaud deux variantes de PowerCLI peuvent-être utilisées.
Soit en utilisant l’objet PowerShell VirtualMachineConfigSpec
$VM = Get-VM [NOM VM]
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$Adapters = Get-NetworkAdapter -VM $VM|?{$_.Type -like "e1000*"}
Foreach($Adapter in $Adapters){
$DevSpec = New-Object VMware.Vim.VirtualDeviceConfigSpec
$DevSpec.Device += $Adapter.ExtensionData
$DevSpec.operation = "remove"
$Spec.deviceChange= $DevSpec
$Spec.deviceChange
}
$VM.ExtensionData.ReconfigVM_Task($Spec)Soit en utilisant l’objet Config.Hardware.Device
$VM = Get-VM -Name [NOM VM]
$NetworkName = ( Get-NetworkAdapter -VM $VM | ?{$_.Type -like "e1000*"} | where {$_.Name -like "Network*"} ).Name
$nic = $vm.ExtensionData.Config.Hardware.Device | where {$_.DeviceInfo.Label -like $NetworkName}
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$dev = New-Object VMware.Vim.VirtualDeviceConfigSpec
$dev.operation = "remove"
$dev.Device = $nic
$spec.DeviceChange += $dev
$vm.ExtensionData.ReconfigVM($spec)Il y a t’il une différence notoire ? Oui et non, il faut comprendre que l’intervention ne se fait pas tout a fait au même niveau dans l’enveloppe de la VM gérée par VSPhere. Pour ma part je préfère la deuxième variante plus fiable.
L’ajout de carte réseau à chaud se fait par le même jeu de commande en utilisant l’objet VMware.Vim.VirtualVmxnet3. Cette fois-ci on intervient par les fonctions du switch réseau.
$NetworkName = [VSWITCH RESEAU]
$VM = Get-VM [NOM VM]
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$dev = New-Object VMware.Vim.VirtualDeviceConfigSpec
$dev.Operation = "add"
$dev.Device = New-Object VMware.Vim.VirtualVmxnet3
$dev.Device.Connectable = New-Object VMware.Vim.VirtualDeviceConnectInfo
$dev.Device.Connectable.StartConnected = $True
$dev.Device.WakeOnLanEnabled = $True
$dev.Device.Backing = New-Object VMware.Vim.VirtualEthernetCardNetworkBackingInfo
$dev.Device.Backing.DeviceName = $NetworkName
$dev.Device.MacAddress = $Adapter.MacAddress
$spec.deviceChange += $dev
$VM.ExtensionData.ReconfigVM($spec)Une fois terminé votre action aura changé votre interface réseau comme une nouvelle carte réseau. C’est pour cette raison qu’il est important de préparer le système d’exploitation à votre nouvelle carte réseau.
A noter qu’il est possible sous Windows d’utiliser les commandes netsh pour préparer le terrain, mais cela n’est pas forcément facile notamment en fonction de la version de Windows Server. Cette opération peut par exemple exécutable à distance par un orchestrateur.
L’orchestration
Lorsque l’on prévoit une opération de masse comme celle-ci, il est concevable d’utiliser des scripts agissant à exécuter à distance pour chaque type d’O.S. C’est une méthode, que l’on utilisait et que l’on peut toujours utiliser lorsqu’il n’y a pas d’outil d’orchestration. Cela devient assez difficile dans des environnements cloisonnés.
Il est donc presque indispensable d’avoir ce genre d’outil à demeurre pour faire le travail de préparation des serveurs avant l’opération de chagement massif des cartes réseaux.
Imaginez que vous deviez également modifier les configurations des pare-feux de vos VM (Linux ou Windows), et peut-être d’autres choses ?
Pensez aux produits OpenSource ou de facto compris dans vos logiciels d’infrastructures, comme Ansible capable de travailler avec Windows comme Linux. Ou encore VSPhere Orchestrator ou VRA ?
Parlons Méthode
- Préparer deux VM de test pour tester le principe de ces scripts et valider votre ou vos scénario ou scénarii.
- Préparez un audit de vos VM à modifier, afin de connaitre leurs constitutions, (pare-feu, routage, natage, version d’OS + build, patchs, etc.).
Créer un échantillon de VM pour chaque version d’OS à la build près. Et c’est très important ! Une build près peut influencer votre résultat. - Si vous avez un comité de changement au sein de votre organisation, mettez-les dans le coup et c’est TRES important. Ils vous permettrons de garantir que vous n’avez rien oublié et n’impacterez pas une couche applicative.
- Préparez votre méthode de changement de vos cartes réseaux.
Rappel: Deux possibilités pour changer vos drivers de cartes réseaux, soit à chaud, soit à froid.
notez que peut importe la méthode utilisée, l’adresse MAC de l’interface réseau est reconduite de facto. - Pensez à organiser votre déploiement des paramétrages, à pousser aux VM à l’aide d’un orchestrateur, car les modifications seront industrialisées.
Petite note pour les Windowsiens; pensez à supprimer vos drivers de cartes réseaux sous Windows Server, cela permet d’optimiser la base de registre matériel et d’éviter de mauvaises surprises.
Plusieurs solutions pour faire cela
Utilisez ce script PowerShell utilisant l’outil de gestion des drivers PlugAndPlay. En cas de doute procédez à un snapshot VMware ou effectuez un Checkpoint pour restaurer votre Windows Server à la dernière bonne configuration connue.
Checkpoint-Computer -Description “PointBeforeDeleteUnusedDrivers”
Get-ComputerRestorePointPuis, comme souvent c’est le cas, exécutez ces exclusions de sécurités le temps de l’exécution.
Bien évidement tous dépendra des stratégies GPO de votre entreprise !
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
MyCleanDrivers.ps1# Base sur la source de TheITBross
# MyCleanDrivers.ps1
# Setting Variables
$dismOut = dism /online /get-drivers
$Lines = $dismOut | select -Skip 10
$Operation = "CleanMyDrivers"
$Drivers = @()
foreach ( $Line in $Lines ) {
$tmp = $Line
$txt = $($tmp.Split( ':' ))[1]
switch ($Operation) {
'CleanMyDrivers' { $Name = $txt
$Operation = 'theFileName'
break
}
'theFileName' { $FileName = $txt.Trim()
$Operation = 'theEntr'
break
}
'theEntr' { $Entr = $txt.Trim()
$Operation = 'theClassName'
break
}
'theClassName' { $ClassName = $txt.Trim()
$Operation = 'theVendor'
break
}
'theVendor' { $Vendor = $txt.Trim()
$Operation = 'theDate'
break
}
'theDate' { # change the date format for easy sorting
$tmp = $txt.split( '.' )
$txt = "$($tmp[2]).$($tmp[1]).$($tmp[0].Trim())"
$Date = $txt
$Operation = 'theVersion'
break
}
'theVersion' { $Version = $txt.Trim()
$Operation = 'theNull'
$params = [ordered]@{ 'FileName' = $FileName
'Vendor' = $Vendor
'Date' = $Date
'Name' = $Name
'ClassName' = $ClassName
'Version' = $Version
'Entr' = $Entr
}
$obj = New-Object -TypeName PSObject -Property $params
$Drivers += $obj
break
}
'theNull' { $Operation = 'CleanMyDrivers'
break
}
}
}
Write-Host "All installed third-party drivers"
$Drivers | sort Filename | ft
Write-Host "Different versions "
$last = ''
$NotUnique = @()
foreach ( $Dr in $($Drivers | sort Filename) ) {
if ($Dr.FileName -eq $last ) { $NotUnique += $Dr }
$last = $Dr.FileName
}
$NotUnique | sort FileName | ft
Write-Host "Outdated drivers"
$list = $NotUnique | select -ExpandProperty FileName -Unique
$ToDel = @()
foreach ( $Dr in $list ) {
Write-Host "Duplicate found " -ForegroundColor Yellow
$sel = $Drivers | where { $_.FileName -eq $Dr } | sort date -Descending | select -Skip 1
$sel | ft
$ToDel += $sel
}
Write-Host "Drivers to remove " -ForegroundColor Red
$ToDel | ft
# Removing old drivers
foreach ( $item in $ToDel ) {
$Name = $($item.Name).Trim()
Write-Host "deleting $Name" -ForegroundColor Yellow
Write-Host "pnputil.exe -d $Name" -ForegroundColor Yellow
Invoke-Expression -Command "pnputil.exe -d $Name"
}Autre option
Utilisez un utilitaire gratuit comme DeviceCleanup, qui possède un binaire utilisable en mode commande permettant de purger les anciens drivers absents.
A vous de jouer !