Pour réaliser notre devoir de bon consultant, nous sommes bien souvent en train de puiser via notre moteur de recherche préféré les bons liens pour rechercher les bonnes informations.
Je vous propose un certains nombre de liens officiels, qui je suis sur, vous aiderons à votre quête d’informations.
Vous êtes-vous déjà demandé comment et où l’interface utilisateur vSphere génère la configuration matérielle par défaut de la machine virtuelle après avoir sélectionné un système d’exploitation invité spécifique lors de l’assistant de création de machine virtuelle ?
La réponse est assez simple en demandant à la plate-forme vSphere et bien sûr, cela est fourni en tant qu’API que tout client logiciel peut utiliser, y compris notre propre interface utilisateur vSphere !
Cela se fait grâce à l’ API EnvironmentBrowser pour interroger la liste des systèmes d’exploitation invités pris en charge et la compatibilité du matériel virtuel. En plus de ces informations, nous pouvons également demander à la plate-forme vSphere quelle est la configuration matérielle par défaut pour tous les systèmes d’exploitation invités pris en charge à l’aide de l’ API QueryConfigOption .
Pour démontrer comment utiliser l’API QueryConfigOption, voici deux fonctions PowerCLI simples qui peuvent être trouvées dans cet exemple:
Fonction Get-VMHardwareVersion {
paramètre (
[ Paramètre ( Obligatoire = $true )][ Chaîne ] $ClusterName
)
$cluster = Get-Cluster $ClusterName
$envBrowser = Get-View $cluster .ExtensionData.EnvironmentBrowser
$envBrowser .QueryConfigOptionDescriptor ().key
}
Fonction Get-VMHardwareConfig {
paramètre (
[ Paramètre ( Obligatoire = $true )][ Chaîne ] $ClusterName ,
[ Paramètre ( Obligatoire = $true )][ Chaîne ] $VMHardwareVersion
)
$cluster = Get-Cluster $ClusterName
$vmhost = $cluster | Get-VMHost | sélectionner - Premier 1
$envBrowser = Get-View $cluster .ExtensionData.EnvironmentBrowser
$vmHardwareConfigs = $envBrowser .QueryConfigOption ( $VMHardwareVersion , $vmhost .ExtensionData.MoRef )
$vmHardwareConfigs .GuestOSDescriptor
}Avant de pouvoir récupérer la configuration matérielle de la machine virtuelle pour un système d’exploitation invité spécifique, nous devons spécifier la compatibilité matérielle de la machine virtuelle prise en charge. Pour ce faire, vous pouvez utiliser la fonction Get-VMHardwareVersion et spécifier le cluster vSphere souhaité pour interroger ces informations, comme indiqué dans la capture d’écran ci-dessous.
$ClusterName = "MainHost1-Cluster"
Get-VMHardwareVersion -ClusterName $ClusterName
Une fois que nous avons la liste des versions des compatibilités matérielles des VM prises en charge, nous pouvons utiliser la fonction Get-VMHardwareConfig et spécifier le cluster vSphere souhaité et la version de compatibilité matérielle VM pour récupérer la liste de tous les systèmes d’exploitation invités et leurs configurations matérielles par défaut.
$results = Get-VMHardwareConfig -ClusterName $ClusterName -VMHardwareVersion "vmx-10"
$results
Les résultats de cette fonction sont un tableau de tous les systèmes d’exploitation invités. il suffit de filtrer davantage les résultats en désactivant par exemple la propriété Id ou FullName
Voici toutes les appliances virtuelles Nested ESXi actuellement disponibles au téléchargement. Cette page sera mise à jour périodiquement, veuillez revenir ici si vous avez des questions concernant la version de l’appareil.
Pour ceux qui préfèrent utiliser les appliances virtuelles ESXi imbriquées à l’aide de ma bibliothèque de contenu Nested ESXi vSphere, abonnez-vous simplement à :
Ce n’est pas nouveau, mais beaucoup d’ingénieur en informatique ou développeur cherche perpétuellement la bonne configuration pour construire son serveur pour un lab ou plus.
La problématique est que l’encombre d’un serveur au format tour ou rack est avéré.
Si l’on cherche à se retrouver seul chez soi avec son serveur, au lieu de la personne avec qui nous vivons, c’est la bonne démarche !
Après une configuration à base de Shuttle et d’intel I7-8700 créée en 2017, je vous propose un nouveau challenge:
Un VRAI serveur AMD en format Mini-ITX.
Vous allez me rétorquer, “Pffffuu, facile….”. Mais là je vous parle d’un VRAI serveur avec une carte serveur sans l’équipement de carte vidéo.
“Aahhhh ?”. Eh bien oui ! 🙂
Après sa fameuse carte mère X470D4U au format ATX, ASRock Rack, la filiale d’ASRock, a publié courant janvier une nouvelle version de cette fameuse carte mère. Plus rapide et pourvu du chipset X570 devenu un standard pour les cartes mères à base de processeurs AMD.
Mais cela n’est pas tout. Cette carte est au format Mini-ITX.
Cette nouvelle au final avec les problématiques de COVID, à pris beaucoup…beaucoup de retard sur la production venant de Chine.
Les premières livraisons sont arrivées au compte-gouttes courant Juin dans certains pays en Europe, et Juillet/Aout en France.
Pour couronner le tout, certains composants comme les alimentations se sont fait attendre également. Autant dire que les approvisionnements sont tendues à cause de ces épisodes d’épidémies et partout dans le monde.
Voici donc un exemple de configuration que je vous propose en versus Mini-ITX.
Un serveur avec un processeur AMD et dépassant 10 cœurs.
Pas de blocage d’évolution de la RAM à 32 ou 64GB
La possibilité de mettre plus de deux disque de stockage
Un budget raisonnable pour ce genre de configuration
Cette X570D4I-2T est une bombe, et propose tous de sa petite sœur la X470. Attention cependant, cette carte mère est le premier centre de coût après le processeur. Comptez plus de 300€.:
1 socket AMD AM4 pour processeur AMD Ryzen 3000
4 Slots mémoire DDR4 2133/2400/2666/2933 MHz Dual-Channel (128 Go max.)
8 SATA 6Gb/s (par OCulink) avec le support RAID 0/1/10
1 x M.2 PCIe 4.0 x4 / SATA 6 Gbps
1 port PCI-Express 4.0 16x
2 LAN 10 GbE Intel X550-AT2
1 port LAN mangement IPMI Realtek RTL8211E
1 Contrôleur Aspeed AST2500
Et oui, cette carte serveur possède sa carte graphique. Inutile de monopoliser un port PCI pour une carte graphique, car comme vous le savez, seul les AMD de la série Vega intègre le processeur graphique. Un sacré gain de place, de consommation. Et il nous reste un port PCI utilisable pour soit une carte graphique dédié pour du calcul GPU ou autre.
Il s’agit bien ici d’une carte mère serveur, car il y a la présence d’un BMC, car comme on peut le voir, un troisième port Ethernet est disponible. Il s’agit d’un port de management qui permet, comme beaucoup de carte mère serveur de prendre la main à distance (RSA, iLO, et cie). Et surtout de démarrer la carte mère et ses périphériques.
Pour ajouter un petit plus (qui existait dans la configuration Shuttle), une carte Wifi en port PCI avec un chipset Intel, et … une puce bluetooth. De quoi être complet, non !?!
Deuxième centre de coût.
Mon objectif était de monté en puissance après ma configuration Shuttle à base d’Intel I7-8700.
Ainsi, de 12 Thread sur 6 Cœurs, j’ai fais le choix rapport/prix de passer à 12 Cœurs 24 Thread, soit doubler le compute.
Les EPYC étant trop cher, j’ai sélectionner le Ryzen 9 3900X 3800MHz.
Troisième centre de coût. Le choix important et doit-être en compatibilité avec les recommandations constructeurs.
Deux barettes Crucial CT2K32G4SFD8266 propose ainsi 64 GB de RAM. Ainsi deux emplacements reste libre pour monter à 128GB la capacité maximale mémoire.
Pour faire fonctionner cela, une bonne alimentation au format TFX, car au format Mini-ITX, c’est le format implicite.
J’ai choisi un bon rendement pour jouer la carte budget électrique et éviter des pertes dû au mauvais rendement. La TFX Power 2 300W Gold de chez BeQuiet me semblait une évidence pour rester dans un budget convenable. 300W, cela parait faible, mais cela est très suffisant, a moins d’utiliser des disques dur mécanique)
C’est très secondaire, mais au final, non. Il va accueillir tous l’ensemble et doit-être d’encombrement minimal. J’ai choisi le boitier BU12 de Chieftec, bien sur sans l’alimentation. Le boitier est de bonne facture pour un prix très raisonnable. Si on cherche à héberger beaucoup de disque dur il faudra changer pour un boitier un peu plus haut. Pour mon besoin, je suis parti pour deux unités à fortes capacités. (Nous en parlerons plus tard)
Ce boitier possède des emplacements 2,5″, 3,5″ et un pseudo 5 1/4″. Avec des berceaux d’adaptations à prix modique, il est donc possible de mettre en deux à quatre disque 2,5″.
C’est un choix important pour éviter d’avoir trop de bruit et avoir une ventilation efficace. Par rapport à la hauteur du boitier, le choix est très dirigé.
ATTENTION, ASRock impose un montage des ventilateurs au format LGA15xx, alors que le processeur est au format M2.
Certains constructeur de système de refroidissement propose des ventilateurs, ou ventirad pour les puristes, adaptables pour de nombreux format et cela peut import le socket du processeur.
C’est le cas du C7 de chez Cryorig, qui possède un look très sympa, sans cloisonnement qui provoque lorsque le ventilateur se voile, des bruits de frottement. La hauteur de ce ventirad nous laisse encore un petit de mou.
Comme je vous l’ai dit, j’ai choisi deux disques SATA SSD à fortes capacités. Selon son besoin, ils pourront être montés en RAID1 ou non en fonction. J’ai choisi un volume par disque Segate Baracuda 120 SSD. Ce choix est le meilleur compromis/prix avec IO supérieurs à Western Digital ou Crucial par exemple.
Enfin pour éviter de monopoliser l’un de ces pour le système de virtualisation, un disque M2 de 250 GB WD blue que je possédais. Très largement suffisant.
La carte mère s’intègre sans complication sur le boitier.
C’est côté alimentation que l’intégration doit-être soignée, car la place disponible est faible. Notamment près du ventilateur du boitier.
Une attention toute particulière est aussi sur le raccordement. Fourni avec l’alimentation TFX, BeQuiet! propose un adaptateur ATX vers ATX 12V. Il ne faut pas non plus oublier l’alimentation 12v du CPU, sinon la carte mère s’allumera de facto, mais sans CPU rien ne fonctionnera et sans aucune alerte sur la partie BMC.
Comme on peut le voir sur les illustrations, le raccordement des unités de disques de stockage SATA s’effectue par un câble OnLink. Attention ce câble est assez fin et peu, vite s’abimer. Via ce câble, quatre connexions SATA sont disponibles.
ATTENTION également, ASRock recommande d’utiliser les câbles d’alimentations venant de l’alimentation à découpage TFX et non de la carte mère pour éviter des dégradations de la carte mère. Tous dépends de l’alimentation utilisée ATX ou ATX12V.
Aspeed AST2500 oblige, il faudra se contenter d’un port vidéo VGA. Mais cela n’est pas forcément utile, car nous disposons de notre BMC. Et là tout se fait à distance !
Précaution, tout de même, utilisez la version Java de la prise à distance. Cela vous permettra d’avoir plus d’options à disponibilité.
Cela parait simple, mais il y a toujours des mauvaises estimations de compatibilité avec un hyperviseur ou un autre.
Avant l’achat, il est évident que des vérifications de compatibilités ont été réalisé notamment avec VMware. L’objectif était également de pouvoir installer un ESXi 7. Comme vous le savez, les drivers de l’ESXi 7 ont été complètement ré-écrit, ce qui ne peut pas forcément arranger les choses.
Force de dire que l’installation passe comme une lettre à la poste. Même la carte WIFI grace à son chipset Intel, est reconnue.
J’ai poussé le bouchon un peu plus loin en virtualisant un hyperviseur Linux, Proxmox. Bien évidement il est important d’activer le partage de l’hyper threading et affecter un nombre suffisant de CPU dédié à cette VM.
Ainsi nous disposons, d’un hyperviseur ESXi, et d’un hyperviseur Proxmox afin de virtualiser des containers LXC/LXD.
Chacun y trouvera son compte.
Installer un Proxmox au lieu d’un ESXi 7, ne pose aucun soucis de facto non plus. Noyau Linux oblige, c’est du gâteau !
Là aussi, tout est reconnu. Le petit plus, par rapport à une config Shuttle Intel, aucun besoin de toucher au configuration IOMMU pour éviter des instabilités, car ici TOUT est disponible et fonctionne sans rien faire.
Ainsi le partage en Pass-Thru des add’on PCI ou USB pour une VM, est fonctionnel.
Deux exemples de VM avec leur port PCI ou USB en mode Pass-Thru.
Installer un ESXi en mode Nested ne pose non plus aucun soucis. Il suffit de réserver un certains nombre de ressources CPU en mode CPU-Host par exemple pour profiter d’un hyperviseur VMware sous Proxmox.
Pour rappel sous linux, il est impératif de paramétrer les modules modprobe en fonction du fondeur du cpu:
Il faut commencer par contrôler si le paramètre nested est activé ou pas dans le processeur :
cat /sys/module/kvm_intel/parameters/nested
ou
cat /sys/module/kvm_amd/parameters/nested
# N ou 0S’il est à N ou à 0, c’est qu’il n’est pas activé.
Pour activer l’activer, il suffit de positionner la variable à 1 à l’aide de la commande; Remplacez xxxx par le fondeur du cpu:
echo "options kvm-xxxx nested=1" > /etc/modprobe.d/kvm-xxxx.confIl faut ensuite redémarrer le module kvm. Pour cela il faut que toutes les vms soient arrêtée sur le serveur.
modprobe -r kvm-intel ou modprobe kvm-intelOn vérifie :
cat /sys/module/kvm_intel/parameters/nested
# Y ou 1Côté hyperviseur, on est prêt !
Coté guest-OS, plus particulièrement l’hyperviseur virtualisé, il est impératif de paramétrer au niveau de l’enveloppe du guest le type de cpu à host.
Puis également, même si ce n’est pas forcément impératif, ajouter le paramètre : args: -enable-kvm dans le fichier de conf de la vm (Par exemple : /etc/pve/qemu-server/106.conf
C’est tout ! Vous voilà prêt pour virtualiser un hyperviseur…Heu mais que dis-je ? 🙂
La boucle est bouclée !
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.
Poursuivre la lecture « Gérer le changement en masse des cartes réseaux sous VMware VSPHERE »
Depuis l’annonce de la sortie commerciale de la suite vSphere 7, nous sommes tous dans l’attente des changements et surtout des rétro-compatibilités des matériels. C’est essentiel pour savoir vers quoi nous allons tendre en terme de stratégie SI.
Voici donc officiellement les ébauches des changements et des obsolescences à gérer dans les mois à venir…
