Bon les ptis gars ce coup ci on va parler de Vmware, pourquoi, bin simplement que je me suis tapé ce superbe « how to » exhaustif pour réviser mon examen que j’ai… SI SI… faut le dire que les gens le sachent …passé avec mon pote succès… donc comme d’ab, avant la lecture, une bonne bière, pour aujourd’hui pour changer on vas goûter l’Orval.. amis Moine si tu m’entend merci… si si elle est sympathique… dans la ligné de la Chimay bleu mais peut être un peut plus amérisée…. Soit … prêt… on y va … startons le howto

CHAPITRE 1 ) Introduction et vue d’ensemble de la bête

La société Vmware,

Petite société qui naquis en 1998, achetée par EMC² en 2004, managé séparément ( et dieu sait qu’ils insistent lourdement avec cela, malgré que le SAN soit de plus en plus promus…étrange n’est-ce pas), ce petit software ( non cherchez pas, il n’y a pas de jeux de mots la ) est issu de recherche universitaire, ils sont d’ailleurs dépositaire de nombreux brevets (quelle intro, quelle prestance). L’histoire dira si ils vivront face à Microsoft qui sort sont Virtual Serveur 2005… car Mr Microsoft leur a bien proposer d’être acheté il on dit non, ils ont préféré EMC²… bon pour l’instant Microsoft a encore un sérieux retard sur ce genre de produits…. Profitons lisons…

Maryse dite nous ce qu’est une machine virtuelle ?

Vmware permet de faire tourner simultanément dans le même PC, plusieurs PC nommées VM (virtual Machines). C’est n’est pas un émulateur, ce sont des environnements presque réels, qui on accès réellement des cycles cpu et à de la mémoire, seul les I/O sont simulés et redirigé vers le vrai hardware, ( ex : le disque, le rezal* ), et toutes ces petites VM (Virtual Machines) sont schédulées ensemble sur un seul et même hardware par un Maestro nommé le Kernel Vmware (VMKernel). C’est une virtualisation comme nos aïeux Z/Os en sont capables depuis fort longtemps. Mais c’est sur X86 alors on crie au miracle et a la nouveauté.

Alors admettons qu’on serait des vendeurs quels sont les clefs du succès de Vmware.

Les principes clefs sous Vmware sont :

ISOLATION Les machines sont indépendantes les unes des autres, si une meurt, les autres continuent de fonctionner (normalement… diront les mauvaises langues).

ENCAPSULATION Chaque machine est physiquement représentée par un ensemble de fichier, y compris le disque dur et la définition matérielle (cartes Réseau, Vidéo etc…).

Compatibilitée Chaque machine virtuelle, voit le même PC standard et ceci peu importe sur quel serveur ESX elle est.

HARDWARE INDEPENDANCE : Chaque machine virtuelle ne voit pas le matériel physique de la station host, vu qu’il ne voit qu’un PC standard ( CQPF ), c’est une superbe facilitée de déplacer les machine virtuelle d’un serveur physique a un autre. (A tel point qu’il est possible même de les perdre et de plus savoir ou on l’a posée.. si si véridique).

Et donc…AVANTAGES à utiliser les machine virtuelles

Déjà La maintenance Hardware est super facilitée, un upgrade hardware ne perturbe pas les machine virtuelles car la VM (Virtual Machine) n’a conscience que d’un PC standard. En plus on va voir qu’il y a une facilitée de d’installation des machines par clonage des machines existantes, si on veut un backup du genre ghost, le backup des machines se résume à une copie d’une paire de fichiers. Et parce que Plusieurs machine virtuelle tournent sur un même serveur, on a meilleure utilisation des ressources, c’est connus, le CPU ne fout rien la plupart du temps, le TCO (Total Cost of Ownership, acronyme a placer obligatoirement si on est un vendeur) tombe, cela fait par exemple, que l’on n’a qu’une maintenance serveur a payer au lieu de 10, et avec possibilité de tuning, on peut choisir qui seront les bête aimées et les bêtes noires sur nos serveur consolidés.

Bref ça rend heureux un opérateur système vive la consolidation, un autre aspect sympatoche, le Disaster Recovery, car cela permet de faire des machine de backup ( cluster ou hot standby ) a moindre coût, Et l’utilisation possible du SAN pour séparer storage du processing est une vision intéressante.

Et enfin pour les tests et le développement: On a ainsi des machines toujours prêtes sous le coude pré-installées, avec du hardware flexible.

Et les arguments contre… Un seul je dirais, mais pas des moindre si le serveur ESX tombe, tout tombe (ha ouais quand même).

La Gamme de produits VMWARE

M. Vmware dispose de 3 types des produits, les softs dits de virtualisation, puis ensuite ceux ( houps pardon, celui ) de management et ceux ( houps repardons celui ) de conversion, toutes avec un nom a la con précédé d’un V comme….. Vente ??? non Virtuel Bandes d’idiots.

Vplatform

ESX Serveur : Serveur de virtualisation hautes performances

GSX Serveur : Serveur de virtualisation basé sur un OS existant

Workstation : virtualisation pour stations de travails

ACE : virtualisation et déploiement de machine sécurisée et uniformisée

Vmanage

Virtual Center : Outil de gestion de parc de machines virtuelles sous ESX et GSX

Vtools

P2V ( Physical 2 Virtual ) : c’est Outil de conversion de machine réelle vers machine Vmware. Il prend une image d’un poste réel (via un genre de ghost) et la transforme en machine VMWARE (en échangeant au vol les drivers ).Cela Fonctionne pour ESX, GSX et Workstation et Supportent principalement des OS Windows ; NT4 SP4, W2K sp1, W2003

Ce soft est composé de 2 composants, le 1^er prend un snapshot du poste, le second reconfigure la station. On peut aussi utiliser un outil différent pour le 1^er point, ( ex le norton ghost original)

Avantages/possibilité/restrictions comparées des VPlateformes

Workstation :

Performances 70-90% de la machine réelle

dépend d’un OS, ( d’où la perte de perf linux ou Windows)

Pas d’accès et de management a distance par Vmware

idéal pour environnement de développement / test

un maximum de type de machine VM ( Os ) disponible

Utilisable sur tout hardware supporté par l’os

Son et USB

GSX Serveur

Performances 70-90% de la machine réelle

Machine jusqu'à 8 cpu

dépend d’un OS, ( d’où là aussi la perte de perf ) ( linux ou Windows )

virtualisation identique a la Workstations mais tuné pour supporter plus de VM

management a distance + script

Utilisable sur tout hardware supporté par l’os

Max 3.6 GB de Ram par machine virtuelle

Max 64 Vcpu (on dira VM à la place de Vcpu pour l’instant) par ESX

ACE

Uniquement sous windows, mais supporte des Vm sur tout OS

ACE est un genre de Workstation, qui est déployable sur les station clientes,

Un Admin. reste maître de ces Workstation et le client final ne peut que les utiliser

Cela permet de déployer des environnements sécurisé et uniforme, limitable dans le temps

ESX Server

La bête… 83-98% de la machine réelle ( selon les manifestants )

Machine physique jusqu'à 16 CPU

Directement installé sur le HDW ( le fameux « Installed on BARE-METAL ». a lire avec l’accent de Shrek en VO)

Management a distance + script

Tuning des ressources on the fly

Utilisable sur moins de gamme de hardware, le vmkernel devant accéder lui-même directement au hdw

Moins de type de machine VM ( Os ) disponible

Mécanisme de Sauvegarde de mémoire vive

Max 3.6 GB par machine virtuelle

Virtual SMP ( machine virtuelles BI CPU )

Max 80 Vcpu ( 80 cpu virtuels ) par ESX

Vmotion possible

Et pour bien comprendre, l’interaction OS / Vmware de chacun, Un super petit dessin.

VIRTUAL CENTER

Dans un serveur virtual center, on crée des fermes, ces fermes contiennent des serveurs esx ( qu’on ajoute avec le bouton droit de la souris dans le virtual center client, pour autant qu’on ai suffisamment de licences) ces fermes sont des représentations administratives , au moment de l’ajout d’un serveur dans une ferme, le VCC (Virtual Center Console) demande le user ROOT, il s’en sert pour créer un user nommé vpxuser dont il se sert pour ses accès futurs. Ce vpxuser a comme home directory /home directement et c’est dans un sous répertoire vmware qu’il fourre ses config de VM du nom de la station.

Chapitre 2) ESX rien qu’ESX (ce a quoi qu’on va s’intéresser )

ESX en détail :

Quand on a la main sur un serveur ESX on pense qu’on est sur un Linux, c’est pas totalement faux, en effet la console de management est basée sur une RED HAT 7.2. mais ce qu’il fait bien comprendre, ce que c’est pas un serveur GSX tuné sous linux. Non le noyau qui fait tourner vos VM est le VMKERNEL, c’est d’ailleur lui qui schédule la console. C’est un OS propriétaire développé par VMWARE, ce n’est pas linux, linux ne sert que d’interface avec cet os il permet d’accéder au devices console et au devices partagés. On récapitule l’interface Homme PC est un LINUX, l’interface PC Vmachines est un OS propriétaire nommé VMKernel…. Que j’en voye pas un qui dis Houaaiiis ESX c’est un Linux… sinon flagellation, et il ira s’expliquer avec Mr VM pour le débat Qui est L’os.

Le VMKERNEL tourne directement sur le HDW ( Hardware ) et sur un HDW qu’il pense valide, si un probleme hardware survient, patatra. Il y faut penser a mort avant pour éviter les pbm HDW !!! ( Dieu Bénisse l’alimentation redondante )

Le serveur ESX Dispose d’une interface Web ( MUI ) Vmware Management User Interface et d’une console Ecran/Clavier/Souris à distance pour les machines virtuelles nommée REMOTE CONSOLE, celle ci est dispo soit sur le cd d’install soit directement dans le MUI. Elle est disponible pour Linux en RPM et TGZ et aussi disponible pour Windows.

Et si on a du pognon on a Virtual Center :

Ce petit soft additionnel, et fort cher, permet de Manager de façon centralisée, plusieurs serveurs ESX mais il gère aussi les serveurs GSX, on dispose alors de la possibilité d’un rangement logique de nos petites VM, du clonage des VM ,de migration de VM entre serveur Gsx & Esx machine éteinte. Et le clou du spectacle, de la migration en life ( sans down time) via Vmotion ( qu’on verra en détail plus tard ) entre de VM serveur Esx ( mais seulement si, et seulement si, les Data sont sur un disque SAN partagé)

Ce serveur Virtual center, dont la morale nous le fait logiquement installer autre part que dans une VM tourne exclusivement sous windows. Il dispose d’un Client lui aussi Uniquement Windows, nommé VC Client (VIRTUAL CENTER CLIENT) il lui faut le .NET Framework pour son installation.

Pour les impatients : Reportage Photo : Installons un ESX bientôt Disponible

Préparation :

Cela s’installe sur un Serveur X86 mais il faut Valider agressivement le type de Hardware via les « System Compatibility Guides dispo » sur le site. Ne vous laisser pas embobiner par vos vendeur. Si c’est pas la dedans…

Esx_systems_guide.pdf et ESX_IO_guide.pdf

REFUSEZ DE TOUCHER

Les HBA (Host Bus Adapter) SAN supportés sont les EMULEX et les QLOGIC, un guide compatibility est aussi dispo à la même adresse. ( Ne prenez pas peur avec tous ces mots étranges sur le SAN on verra cela après un peut plus profond… pour l’instant retenez, un SAN c’est un disque DUR )

Sinon la petite préparation à effectuer est simple, avoir l’environnement IP que l’on va donner au serveur ESX, un pc de management connectable réseau, les support, les clefs Esx et/ou SMP , un IE6 netscape 7 ou Mozilla 1 (IE5.5 non recommandé). Et pour les OS Guest (dans les VM), se munir de leur clef, et du support si possible en ISO (Amis néophite, un ISO c’est une image bit a bit d’un CD… bit a bit n’a rien de sexuel ).

Ensuite Tester le Hardware 72H avant l’install de ESX, faire test mémoire, et/ou HD et CPU. Souvent personne ne le fait, mais c’est hautement recommandé, comme dirait un collègue, quand on met tous ses œufs dans le même panier, il est bon de s’assurer qu’il n’est pas percé.

Installation… Voir ICI reportage Photo bientôt Disponible

L’installation est fort simple, Booter sur le CD, le boot nous propose alors différentes options.

NOAPIC, pas de support APIC réserver au pbm de plantage a l’install sur des vieux hardwares

TexT, install normale en mode texte

DRIVERDISK, utilisé sur un HDW récent SI Mr vmware fournis un driver pour celui ci

Bootfromsan, utilisé pour une installation du vmware ( le système) sur un disque san

Bootfromsan-text idem mais en mode text

Et si on précise rien et qu’on tape enter, un installation normale (sur disques locaux & mode graphique) se lance.

Si on n’a pas de clef VMware, l’installation n’est pas empêchée mais le VMKERNEL ne se lancera pas tant qu’on ne lui donnera pas une clef valide.

Ensuite on configure le start-up profile, ici le snapshot est celui de la config du startup profile post installation.

Après cette phase, il faut attribuer de la mémoire à la console, pour l’instant on va dire que la console sert à faire gérer les machine virtuelles. Plus on a de VM, plus il faut nourrir la console en RAM.

Il convient ensuite de définir quel carte réseau est réservé à la console, théoriquement cette carte ne peut pas être partagée avec les machines Vmware.. Il existe bien un truc pour le faire, mais c’est non recommandé ( C’est mal les enfants, ne le reproduisez par a la maison).

Si on se plante en jouant et qu’on attribue toutes les cartes réseaux aux Vmkernel (ce qui est impossible en jouant qu’avec le Mui) mais que par exemple on se trompe de carte, on n’a forcément plus accès à la console via le réseau, celle ci n’ayant plus d’interface réseau avec le monde extérieur, et donc, plus de MUI. La seule façon de s’en sortir est d’utiliser la commande console vmkpcidivy –I ( case insensitive pour le I ) pour faire ce wizard en mode texte .

dans cette étape pré installation il faut aussi associer les devices disque soit à la console soit au vmkernel (c’est ici qu’on prend conscience que le Vmkernel attaque directement le hardware qu’on va lui spécifier) , les contrôleurs disques eux on la possibilité d’être sharés (accessible par la console et le vmkernel simultanément) , pour cela, donner le contrôleur au vmkernel et ensuite cocher la case, shared with Service console.

Le système de fichier de la console est typiquement Unix donc les partitions sont montées dans des répertoire ( un mount point ) et non pas vue de lettre logique comme dos/windows.

Le fichier qui contient de mapping de mount de la CONSOLE est /etc/fstab, il ne contient pas les mount des partitions Vmware.

On passe ensuite au partitionnement du disque système, attention un disque dur sur PC ne peut contenir que 4 partitions primaire, au passage Un grand merci aux limitation que l’on traîne depuis 1976 au nom de la sacrosaint compatibilité, donc il nous en faut plus donc on sacrifie une primaire que l’on découpe en autant de partitions étendues que l’on souhaite car, on va le voir, il nous faut un bon paquet de partoches.

Le partitionnement est préconisé ainsi par Monsieur Vmware

Mount Point	Disque	Taille	Type	Utilisé par	Sert à
/boot	Principal	50 Mb	Ext3	Console	À le noyo et les boot files
aucun	principal	2x la mémoire allouée a la console	SWAP	Console	Swap disk de la console
/	Principal	2 à 4 Go	Ext3	Console	Racine contient tout ce qui n’est pas monté, os, config etC., contient le home du user root
/home	Principal	2Go	Ext4	Console	Contient les rép perso des users, mais ceux ci contiennent le fichier de config de la VM, les Core de VM et les Log de VM
/vmimages	Any	Ne pas lésiner	Ext3	Console	Contiendra par nomenclature les images ISO de CD et les images de Floppy, ainsi que les export disque de machines VM
/var	Principal	1,5 a 2Go	Ext3	Console	Contient les Log Vmware
/tmp	Principal	De 100 a +	Ext3	console	Disque temporaire, normalement peu utilisé mais les procédure VM de maj d’os par exemple l’utilisent
none	LOCAL	100Mb	vmkcore	Vmware	Partition de Dump en cas de PSOD
None	local	1x la RAM	Vmkfs2	Vmware	Partition ou on créera le swapfile des machines VMWARE ( pas confondre avec la console )
None	any	MAX	Vmkfs2	vmware	Partition qu’on utilisera pour les HD des machines virtuelles.

Petites notes :

Au partitionnement ont a 2 choix, Automatic ou Manuel, prendre le manuel, l’automatique est je pense un piège a touriste car il ne réalise pas le partitionnement comme on le veut, je vois pas d’ailleurs pourquoi Mr Vmware l’a laissé en l’état.

À la création de ces partitions, penser à en profiter pour tester la surface, c’est effectivement très lent, mais il faut être sur du matériel qu’on vous dis ! alors on le FAIT.

Note, on découpe /var et /tmp qui sont susceptible de grossir ( les logs sont dans /var par exemple ) pour limiter les crash si le disque dur est FULL ( si car si /var est full, / aura encore de la place ).

Boot, le swap et / sur partition principale, c’est ne pas obligatoire mais par convention on fait comme cela. Les rebelles que vous êtes peuvent faire ce qu’il veulent, a la limite moi je m’en tamponne.

/home séparé de /, car il est supposé contenir les config file des VM, les Core.. et il faut tout mettre en œuvre pour que la partition Root (/) ne serre pas.

le swap est un type de partition en soi, il n’est pas monté dans un répertoire.

la partition de swapfile vmware, sert a l’overcommitement ( c’est a dire faire démarrer plus de VM avec de la ram qui n’existe pas en vrai.. vous avez rien compris hein… moi non plus j’ai rien compris a ce que j’ai écris, soit, cela sert par exemple a avoir 5 Go de Ram dans l’ensemble de nos machine virtuelles, alors que le serveur ESX n’en n’aurais que 2,5 Go de Ram.. a manier avec parcimonie on verra aussi ça après ( L’overcommitenment , pas la parcimonie )

/vmimages c’est par tradition, le pbm des traditions c’est que des scripts déjà tout fait, du style le script de backup de machine vm vmsnap.pl utilise par défaut /vmimages. Donc bêtement on garde ce nom

La partition vmkCORE : si le serveur ESX se vautre, le fameux PSOD ( Purple Screen Of Death, un blue screen vmware qui est pas bleu quoi) Un dump est mis dans cette partoche, au reboot le process vmkdump extraira ces infos pour les poser dans /root et cela afin de pouvoir les transmette à Mr Vmware, il est possible en 2.5 ( non recommandé, mais possible ) de sharer cette partoche via SAN sur plusieurs serveurs, dans ce cas, la tailler de façons conséquente la documentation dit 1,6 go sans l’expliquer ici, j’avoue je ne sais toujours pas pourquoi.

On y Vient

VMFS : le file system du jour

Vmware utilise son propre système de fichier pour les machines virtuelles, il permet de stocker de larges fichiers et leur vmkernel y accède avec de grandes performances. Ce système de fichier est de base partageable ( d’où l’avantage SAN avec ESX… bon ok ceux qui savent toujours pas ce que c’est un SAN ne sont pas plus avancés ) cette magnifique fonction est fièrement appelée (VMFS Multiple Access nature), dans cette partition sont stocké (de façon transparente via un espace réservé nommé METADATA) l’état lock des fichiers afin de coordonner de façon efficace l’accès par diffèrent serveurs ESX, ceux ci n’ayant pas de moyen de communication entre eux autre que le disque.

Le metadata est mis à jours quand on change les attributs d’un fichier, quand on crée un fichier,et quand on éteint ou allume une VM, il y a un système de lock qui ne permet qu’a un seul serveur ESX de mettre a jours ces metadata a la fois

Une partition vmfs a des limites et pas des moindres, c’est un system de fichier flat, pas de répertoires, bienvenu de retour en 1970 Doc… et maximum 256 Fichiers, tout les volumes VMFS sont montés dans le répertoire /vmfs sous un répertoire avec le nom physique vmhbaXXXXX et avec un alias qui a le nom du volume label que les humains que nous sommes lui ont donné, ces partition ne sont pas visible dans /etc/fstab.

Ce type de partition est extensible sur une autre partition, et ce sur 32 partitions, ( Petite Remarque : c’est un JBOD (encore un acronyme… et oui je suis payé a l’acronyme) , Just a Bunch of Disk, bref un amas de disque, ce n’est pas splitté en secteur, cela ne gagne de la performance grâce a d’hypothétiques IOs Multi-bras, ici on remplis le 1^er et quand il est plein on passe au suivant, c’est du dépannage pas une solution performante.. Reprenons) à chaque extension, on gagne 128 fichiers supplémentaires. Mais une fois de plus, je répète que ce n’est pas recommandé car à ce moment là chaque disque devient un SPOF( Yess encore un : Single Point of Failure ). Si une seule des ces partition est out, tout l’array est mort.

LE MUI (Vmware Management User Interface)

Le MUI est dispo a l’url HTTPS://MAMACHINEESX, via la porte console l’http est redirigé vers HTTPS (via code http 303 pour info sur un Apache 1.3.31) L’utilisateur ROOT sous linux est l’équivalent de l’utilisateur Windows ADMINISTRATOR,il a tout pouvoir. La configuration du serveur ESX (onglet options dans le mui) se fait avec l’user ROOT (ou équivalent en droits).

Le site Web MUI est signé avec un certificat SSL de VMWARE, si on veut le changer les clefs sont dans /etc/vmware-mui/ssl

Clef privée de decyrptage

Mui.key

Certificat

Mui.crt

Après ‘install au 1^er reboot, le mui affiche un reminder qui , demande de créer un swap space Vmware et des virtual ethernet switches.

LE SWAP VMFS : de diou combien il y a de swap la dedans

Le swap vmfs (rapidement expliqué plus haut) permet l’overcommitement, c’est à dire avoir la possibilité d’avoir plus de ram dans nos VM que de ram physique dans le serveur ESX ( je sens que je me répète non ?… A ce propos, pour les forts en calembours affligeant, la répète ça devrait vous faire rire un bon quart d’heure)…. Reprenons ce satané swap, il loge dans une partition VMFS, il doit être créer via le mui « options/swap configuration » et il faut penser à L’ACTIVER.. et ouais plein de quidam l’oublie cela.

Via le MUI on peut faire un fichier unique de swap, via vmkfstool on peut en créer 8 en console, comme cela ils se sentent moins seuls… non en fait, ça vous permettra de vous dépanner si vous avec créé les partoches trop courtes et Murphy aidant, le disque VMFS contenant la swap est pleine.

Et qu’en plus que vous avez rajouter de la ram et vous voulez réajuster votre overcommitement,bref, vmkfstools option –k crée ou modifie le swap ( avec un swap non actif ) –k comme KREATE bien sur , -w active le swap W comme WAS Y et –y désactive le swap l’option –y Y comme Yesss a la question Pete le.. –y nécessite de donner l’id du swap, cet id est trouvable si on fait un cat de

/proc/vmware/swap/stats

Si je trouve le naze qui a dégoté ces switchs pour vmkfstools je lui mets un contrat sur la tête.

LE REZAL sous VMWARE et LES Switches virtuels

Définissable dans mui via « options /network connection /virtual switches ».

Chaque machine virtuelle qui veut utiliser de l’Ethernet doit être branché à un Switch virtuel. Ce switch peut être connecté a une ou plusieurs cartes réseaux afin de converser vers l’extérieurs

Les nom des switches virtuels (network labels) sont case sensitive (éviter les espace et les caractères à la con).

Voila a peut près tout ce qu’on peut faire coté réseau

Vmware utilise des switches virtuels, ces switches peuvent, être connectées ou non, à une ou des cartes réseaux physiques, on peut connecter 32 machines VM a ces switches.

Concernant l’agrégat des cartes réseaux un switche connecté à cet agrégat est nommé bond, ce bond peut être d’un maximum de 10 cartes, il y a plusieurs configuration possible

Mac out policy (default) : load balancing via mac adresses

Low cpu consommation

Ip out policy : load balancing via ip adresses

Consomme plus de Cpu

A besoin de configurer la connection du switch via un lien IEEE 802.3ad

J’en entend déjà le penser.. non 802.3ad c’est pas de l’etherchannel on est pas loin mais c’en est pas

Standby : une carte bosse, les autres attendent qu’elle crève pour faire du fail over.

C’est la que vous allez vous rendre compte que c’est des psychopates chez Vmware, un switche non connecté a une carte réseau est appelé un vmnet, un switche connecté à une carte réseau est appelée vmnic

Ces switches peuvent être connectés directement a des vlan (un vlan par switche VM), et s’interconnecter via un trunk IEE 802.1q, attention de bien vérifier le hdw pour cela, toutes les cartes réseaux ne gère pas le protocole 802.1q ( ex : acenic, 3com ), alors on dispose de Port Group (a qui ont donne le n° du vlan). Ces port group sont connectées au VM.

Éventuellement en cas de besoin,et seulement dans ce cas la, on peut partager la carte console avec les Mv, en chipotant /etc/rc.d/rclocal pour monter un driver nommé vmxnet_console.o

La console est connectée directement a une carte réseau nommée eth0 (nomenclature Linux). Sauf bien sur le bidouillage précité.

Un Serveur ESX peut gérer 16 cartes 10/100 et 8 cartes Gigabit, et chaque machine virtuelle peut gérer 4 cartes virtuelles…. Comptez vous ceux qui suivent.

Via le mui, on peut jouer avec la duplexitude et la vitesse d’une carte dédiée à un switch, c’est une bonne pratique de la forcer (et coté switch aussi les enfants).

Deux fichiers permettent de voir cette configuration, ici un Port Group :

Par défaut la carte réseau proposée est une carte vlance, celle ci émule une carte AMD pclance32 qui est compatible et reconnue de bases par tous les OS, mais offre de moindres performances que la VMXNET, celle ci a de meilleures performances et surtout charge moins le CPU. Il faut cependant attendre l’installer les VMWARE Tools pour profiter du Driver.

Penser à changer éventuellement le switch ou est connecté notre VM ainsi que la carte réseau quand ont crée une VM.

Le vlance, performe a 60 à 70 % de la bande passante dispo.

La vmxnet performe de 80 à 90% de la bande passante dispo.

Info gratos : LE Pxe n’est pas supporté sur les VM sous Windows XP

Chaque machine virtuelle a sa propre Mac adresse. Celle-ci est calculée à partir de l’UUID de la machine virtuelle, et utilise la base vendor Id

Soit :

00 :0C :29 :* :* :* pour une machine crée pas le virtual center

00 :50 :56 :* :* :* pour une machine crée par le Mui

Vmware et le San

Voila on y est enfin.. non de dieux c’est quoi c’te SAN

Premièrement pour info, rien que pour retarder ce moment tant attendu … sachez qu’ on ne peut pas se servir de NAS car le Vmkernel ne gère ni le nfs ni le smb, nis autre protocoles étranges, on peut éventuellement l’utiliser pour /vmimages, mais pour les partoches VMFS, il faut un disque SCSI un array raid quelconque ou un Vrai SAN

Mais gneuugneuuuu on en parle depuis des plombes, c‘est quoi un SAN, donc le Storage Aera Network ( encore un acronyme ) est une espèce de réseau dédicacé pour des IO disque, en bref un PC accède à une baie de disque via un réseau propriétaire. L’équivalent de la carte scsi ( ou réseau suivant l’image qu’on choisit) dans le poste est un HBA ( HOST BUS ADAPTER), celui ci est connecté à la baie de disque sur un SP (Storage Processor), et cela passe par l’intermédiaire de Fibre Channel Switches. Un peut comme dans un réseau Ethernet, il y a un genre de mac adresse qui est utilisé pour adresser chacun des devices, celle ci se nomme WWN (World Wide Names), elle fait 16 char hexa de Long (une bête mac adresse c’est que 12… alors qui c’est qui a la plus longue).

L’avantage c’est que du coup on branche plein de serveur sur ce petit réseau dédié.

Et bien sur pour ne pas tomber en RADE, on prend la bonne habitude de tout doubler (ça tombe bien c’est pas cher comme matos <- ceci était une JOKE)

Dans la baie de disque, on découpe virtuellement des disques durs indépendants, appelés des LUN (Logical Units).

Une fois qu’on a tout doublé (a moindre coût forcément) il y a plusieurs chemins pour accéder a nos disques, vus que nos paquet SAN n’ont pas de GPS il y a un truc nommé :

Multipathing

Le multipathing c’est la configuration redondante des accès au hba vers les sp, il est effectué directement par le vmkernel sans softs additionnels, il y a deux méthodes d’accès :

MRU, Most Recently Used, il utilise le un chemin, si celui ci meurt, il passe au chemin de secourt, si le 1^er chemin revient, il reste sur le chemin de secours, c’est la méthode utilisée par défaut par le vmkernel

FIXED (aussi appelé prefered path) on lui définit un chemin, en cas de pbm, il change de chemins, si le chemin préféré revient, il rebascule dessus, utile pour mettre en place du Qos statique sur le switches mais si on a un pbm intermittent on a droit un phénomène de YOYO fort désagréable.

Zoning.. encore un truc étrange

Afin que pas tous les HBA ne voient tous les LUN, (ce qui est embêtant quand un Windows Réel connecté sur la même baie décide d’écrire sa signature sur un disque VMFS). On doit cacher certain LUN a certains serveurs. Ceci s’appelle le Zoning

Donc on peut soit implanter du soft zoning au niveau du SP afin de filtrer la visibilité par WWn, soit implémenter du hard zoning au niveau du switche, voir du HBA.

Et c’est à partir de là que la nomenclature disque de Vmware se clarifie, Vmware utilise la nomenclature suivante pour nommer ses disques, avec HBA et bien sur avec une pauvre carte SCSI aussi :

Vmhba + adapter : SP : LUN : Partition

Ex : Vmhba1 :1 :12 :1 , HBA1 sur un San SP 1, lun 12 partition 1

Ex : Vmhba0 :0 :0:9 sur un carte SCSI locale ( hba0) , partition 9

Ex : vmhba0 :1 :0 :1 sur une carte SCSI locale (hba0) , deuxième array, 1ere partition

La numérotation commence toujours a zéro à l’exception de la partition qui commence à 1. à noter que si la partition est à 0 c’est qu’on est sur un disque non partitionné ou qu’on accède à un lun (cas typique quand on connecte un RAW Device -> vus plus tard)

Vmware, Par défaut, ne scanne que les 8 premiers LUN, on peut modifier ceci en changeant la sysval disk.maxLun

Pour cacher des lun au niveau du vmware directement ,on utiliser la sysval ( dans options ) disk.maskluns, exemple

Disk.maskluns=vmhba1 :0 :1-14 ,32,35;

Attention: au (;) a la fin de chaques lignes vmhba

Ne seront alors affichés que les lun 0,16-31,33,34 etc. jusqu'à la valeur de disk.maxlun

Note : le lun 0 est impossible a masquer

Ps spécial chipoteurs, les sysval sont dans le fichier /etc/vmware/vmkconfig,

Allons un peut plus loin créons notre partition vmfs a la paluche

Afin, de permettre le partitionnement via commande line via FDISK,il faut trouver quel nom ‘linux’ le device à et pour trouver le nom /dev/ ??? d’un disque vmfs il faut faire

Vmkpcidivy –q vmhba_devs (Q case insentive)

Quand on partitionne avec FDISK, il faut mettre soit même le type de partitions Vmware soit VMFS ou VMKCORE car Fdisk ne gère pas nativement ces nr de Partitions

Type de partitions vmware:

FB -> VMFSv2

FC -> Partition Core

Ensuite pour créer créer la partition VMFS avec ex :

Vmkfstools –C vmfs2 vmhba1:0:12:1 ( C case sensitive ) il est là le piege

Bonne pratique :

La bonne pratique est de séparer sur des LUN différents des machines de test, de prod et les templates, ceci afin ce sauvegarder les IO.

Encore une petite étrangeté, une machine Vmware peut accéder directement a un device SCSi ou un LUN, mais depuis la version 2.5, il est possible d’accéder directement tout en faisant semblant d’utiliser un disque VMFS, cette méthode s’appelle utiliser un RDM (Raw Disk Mapping) :

Cela permet donc ainsi d’avoir par exemple un REDO, de permettre l’export etc etc, tout en utilisant physiquement directement le LUN, coté performance ce n’est pas beaucoup mieux, la raison principale d’utiliser cette chose est éventuellement le clustering entre machine réelle et un VM, ou utiliser les tools de management SAN directement a partir d’un VM. Noter que l’utilisation du redo avec une vrai machine en cluster en face, c’est un accès directe a la catastrophe. Donc on peut le faire, ouais bof.

Re… Les partitions VMWARE ( VMFS )

Rabachons, mais Une fois l’installe effectuée il faut créer ce disques VMFS. Avec le mui penser a leur donner un label cohérent qui aide ( ex local, vmdata .. vmkswap ), c’est toujours mieux qu’avec les HBA quelquechose.

les volumes vmfs peuvent être public ou shared, on détaillera cela dans le clustering, mais en gros Public, veut dire que plusieurs serveurs ESX peuvent voir les fichiers mais un seul peut en ouvrir un a la fois, shared supprime cette limitation quand on fait du clustering.

Type de fichiers qu’on peut glaner dans un VMWARE:

Disques Virtuels	*.VMDK
Swap	*.VSWP
Suspend	*.VMSS
VC templates	*.VMTD
Redo Files	*.REDO
Config File	*.VMX
Disque autres ex:GSX	*.DSK
BIOS cfg	NVRAM
Vm Crash file	CORE
Log files	*.LOG

VIRTUAL CENTER

Dans un serveur virtual center, on crée des fermes, ces fermes contiennent des serveurs esx ( qu’on ajours avec le bouton droit de la souris dans le virtual center client, pour autant qu’on ai suffisamment de licences) ces fermes sont des représentation administrative , au moment de l’ajout d’un serveur dans une ferme, le VCC (Virtual Center Console) demande le user ROOT, il s’en sert pour créer un user nommé vpxuser dont il se sert pour ses accès futurs. Ce vpxuser a comme home directory /home directement et c’est dans un sous répertoire vmware qu’il fourre ses config de VM du nom de la station.

Les Machines Virtuelles.

Une machine virtuelle est CECI

chaque machine virtuelle a 6 Slots PCI Virtuels, dont un déjà mangé par la carte vidéo virtuelle, reste donc 5 Slots Libres

donc -> 2 SCSI + 1 VIDEO + 3 LAN

ou -> 4 LAN + 1 VIDEO + 1 SCSI etc etc

La machine virtuelle accède toujours a du matériel virtualisé, ex : VMWARE SVGA II pour la vidéo, AMD PCNET lan card, et ceci indépendamment du matériel réel qui est en dessous. C’est clair ?

Penser à ne pas être root, pour la création et le management des VM, si on crée un machine sous ROOT, on doit la manager avec Root, et en tant que root, on peut commettre des erreurs qui impacte le système, et en plus elle sera crée dans /root et non dans /home ce qui nous avance a rien d’avoir taillé avec amour nos partitions.

Si on a Virtual Center, ne pas administrer simultanément avec le MUI, ça va directe a la création de PBM.

Quand on crée une VM, lui donner un nom correct, s’assurer quel est unique dans son répertoire ( autrement cata assurée), le fichier de config par défaut a le nom de la machine.VMX c’est un petit fichier texte qui décrit le Hardware, il faut choisir le bon type d’os qu’on veut installer dans guest opération system

ça permet d’optimiser le choix du hardware, et choisis le bon VMTOOLS associé

Ne pas exagérer avec le SMP ne l’utiliser qu’en cas de nécessité.

Choisir la Ram associé

La case WORKLOAD citrix, permet d’allouer + de mémoire physique par défaut a cette machine, permettant ainsi d’avoir de meilleurs performances sur cette machine, le VMkernel traite cette machine avec plus d’égards. ne pas le cocher si pas besoin, cela impacte les perf des autres VM.

Le disque dur, on choisit si on en veut un neuf, un existant déjà sur une partoche VMFS et on peut aussi choisir un accès direct à un LUN sur un SAN ( marche pas sur disques non SAN )

on choisit ensuite dans quelle partition VMFS on veut notre disque, son nom (prendre un nom représentatif , les partitions VMFS n’ayant pas de répertoire c’est vite cochoneux ), et une taille, contrairement a Workstation et GSX, les disques sont monolithique, cela veut dire que si on choisit une partition de 4Go le système va créer immédiatement un fichier qui est le disque virtuel de 4 Go, sur G et W cela crée un fichier qui grossis au fil du temps et qui se split en bloc de 2GO.

Le disque vmdk peut être étendus grâce a la commande

vmkfstool –X 1024M vmhba0 :6 :4 :1 :toto.vmdk

cela étend le disque toto a 1 go, mais il faut ensuite faire le nécessaire sur l’os afin de prendre en compte cet nouvel espace ( raid 0, partition magique , etC. )

Il y a 4 modes possibles pour les disques

Persistent, un disques normal comme il se comporterais dans un PC

Dans tout les autres modes, le système travail avec en plus du disques, avec un fichier REDO, celui ci enregistre tous les IO disque différent de ceux du disque d’origine. Et le disque original reste inchangé.

Les modes avec redo sont

Non Persistant, tous data est écrit dans un fichier a part, au power on, le redo est dégagé .

Undoable, au power on, le système demande si on supprime le redo ou si on le fusionne avec le disque reel, ou si on continue a utiliser le REDO.

Append, tout le travail se fait sur le Redo même après power ON/OFF sans demander.

ATTENTION : Le redo tue les performances I/O des disque, plus le redo gonfle, plus cet impact est grand, il impacte aussi les I/O en changeant fréquemment les metadata , et au final plus le redo est gros plus cela sera pénible de le refaire fusionner avec le Disque véritable.

On peut changer ces mode quand la VM est éteinte. Mais on peut aussi jouer avec le redo, en live grâce a la commande vmware-cmd et vmkfstoolls.

Un Redo fait minimum 16Mo, et grossis par bloc de 16Mo.

A la validation, le disque est créé. Et on retombe sur un récap de la machine virtuelle.

Les CDROM peuvent et doivent au maximum être mappés sur un fichier ISO posé dans Vmimages plutôt que sur le CDROM physique, c’est plus rapide et moins gourmant, sous ESX le /dev/cdrom peut être partagé entre plusieurs VM

Pour créer un ISO, soit utiliser un soft tierce ( nero, winimage etc ) soit utiliser le spartiate mais suffisant DD (Dédé T’est Ou dédééééé… attention pas de error checking sur l’image générée avec DD)

Ex : Dump le device cdrom vers le fichier pathname et force des block de 32k

Syntaxe :

DD if=/dev/cdrom of=pathname bs=32k

Le display, le réduire a 15 bits est suffisant et limite la charge de la console a distance ( 8bit est trop , sauf si serveur en mode Texte, ou qu’on est quasiment aveugle )

Une fois qu’on en est la, prendre la remote console ( depuis le mui ou celle de virtual center, les console virtuelles permettent d’accéder a la souris, au clavier et a l ‘écran, ainsi que reseter, éteindre et allumer une VM.

La VM démarre, on peut passer dans le bios ( utile seulement pour changer le boot order )

La remote console utilise une encryption SSL sur le port 902 par défaut entre votre station et l’adresse console de la station VM

Note : ctrl + alt + enter passe en full screen.

L’installe se poursuit comme sur un pc standard, a la fin de l’install il faut installer les VMWARE TOOLS :

LES VMWARE TOOOOLS

Pour installer ceux ci, cliquez install vmware tools dans une de vos remote console, cela fait monter l’iso avec les tools adéquat a votre os ( d’ou l’importance de choisir correctemen t l’os a la creation de la machine ). Ensuite soit on va sur le CDROM soit on patiente que l’autorun démarre.

Les Vmware tools fournissennt :

Les drivers adéquats et optimisés ( notamment la vmxnet , et la video )

LA VIDÉO par exemple est beaucoup plus rapide, et la souris ‘sort’ de la

Vm quand on arrive en dehors de la fenêtre de la remote console

Un heartbeat entre la vm et le esx

Un gestionnaire de mémoire VM ( ballon )

Le vmware toolbox qui permet :

schrink disque : ( met a 0 les secteur non utilisés ) afin de permettre un

fichier plus petit en export

Et une synchronisation horaire entre la VM et le ESX, par défaut désactivé

Une VM saturé au niveaux CPU ayant un Faux Hardware elle est susceptible de dériver dans le temp, donc soit on s’assure d’un mise a l’heure via NTP AD soit on utilise la toolbox

On peut le setter aussi cette synchro sans toolbox en ajoutant tools.synctime=true dans Le vmx de config

Sous 2003 pour accélérer la vidéo, mettre HDW accélération de la carte vidéo a Full et mouse accélération un chouilla plus aussi

Sous 2000 la vidéo est a full par défaut,

Pour Linux, il faut soit même se débrouiller pour démarrer vmware-toolbox, et l’install est automatique uniquement si on lance les vmware tools install en init 5.

Sinon install manuelle ( installe vmwaretools monte le ISO avec les tools )

Fin de l’installe la machine est prête. Que peut ton en faire… l’utiliser certes mais aussi :

Clonage de machine :

Il suffit de dupliquer le HD, mais attention Windows aura le Même SID, utiliser sysprep pour réinitialiser ces sid dans un Windows, VC intègre un sysprep automatique pour cloner. Et dupliquer config et HD ( bouton droit sur une vm éteinte puis choisir clone ), sur virtual center on peut stocker ces clone en tant que templates, ( disque & prototype de config file ) prêt a l’emplois, spur le la machine Vcserveur ( partition NTFS exclusivement ) soit sur un volume vmfs basé sur un disque SAN

Sur esx manuellement, faire fonctionner sysprep, puis exporter le HD via vmkfstools –e et –i

La copie directe du DSK via CP est possible mais impacte les perf du système, et si un hd fait 10Go copie 10 Go alors que vmkfstool n’utilise que l’espace réellement utilisé.

Si on veut optimiser la taille de ses export, 1 ) defrag de l’os 2 ) shrink via les VMTOOLS

Le shrink s’occupe de mettre a Zéro les bit du disque qui ne sont pas adresse ( l’emplacement ou était feu un fichier par exemple )

Vmkfstool a la syntaxe suivante :

Ici on exporte test.vmdk depuis le disque Vmware vmdata ( qu’on peut nommé aussi vmhbax :x :x :x :test.vmdk ) et le pose dans /vmimages sous le nom toto.dsk

Ensuite on le réimporte ( copie ) dans vmdata sous un nom testbis.vmdk

Cette procédure respecte la répartition de charge, copie seulement les secteurs utilisés, et l’export fournis un fichier compatible vmware GSX et Workstation. Donc le 1er fichier toto.dsk est un fichier texte décrivant le disque et ensuite suivent des chunk de 2go

Nommé nom + -sXXX.dsk .. ici un disque de 100 Mo vide.

VMOTION

Une autre possibilité est disponible si on a Virtual Center, c’est VMOTION, permet de déplacer une machine qui est en marche d’un serveur ESX a un autre et ceci dans down time. Les crédules hurlerons fouuuuutaiiise, mais je l’ai vus croyez-moi, pour les Thomas essayer de trouver une licence d’éval et faite le test avec un SAN d’éval ;)

Attention, replaçons tout de suite le décors c’est pas un soft de Failover, si la machine source, ou le serveur ESX source est plus en état, il ne faudra pas espérer faire marche le vmotion

Mais Comment ce petit miracle s’exécute Maryse ?

Tout d’abord il y a des règles c’est comme avec les Gremlins. Et contrairement à celle des Gremlins il ne faut pas les transgresser sous prétexte de vouloir monter un film.

Soit, on va se la faire à la Yoda c’est la Mode :

Les VMDK sur un LUN SAN partagé avoir tu dois.

Disposer d’un réseau additionnel dans le même RANGE utilisable pour VMOTION avoir tu dois.

Gigabit Ce réseau vmotion avoir tu dois.

Le serveur ‘source’ doit être Up & Running avoir tu auras.

Les Virtual switches, les mêmes noms de switches configurer tu dois.

Les mêmes cpu ( FAMILY et STEEPING ) dans les deux machines obligation tu dois ( on peut vérifier cela en faisant un cat /proc/cpuinfo).

Et en plus il ne faut pas :

Un Device connecté : CDROM, FLOPPY, un port Sériel ( me fait toujours rire ce francisme) ou un port parallèle.

Du clustering avec une autre VM.

Une session remote console ouverte.

Un Virtual Switch interne ( ouais c’est de fait débile, mais je préfère vous le rappeler.)

Considérons un bel environnement ainsi :

Vmotion est initialisé par un opérateur via une console virtual center, la 1er chose est la copie du fichier de config ( vmx ) de la VM dans ESXA vers ESXB en utilisant le lan VMOTION.

Ensuite la ram de la VM est copiée de la VM dans A vers la VM dans B, ceci avec le même principe qu’avec le redo de disque, c’est a dire que la ram passe en Read Only et toute la ram qui serait modifiée après le lancement de la copie est gardée dans un coin à part.

Le disque n’a pas à être copié, car il réside dans un LUN sharé… d’où le San.

Une fois la copie terminée, la VC Console suspend la VM dans le serveur A, copie le reste de la RAM modifiée ainsi que l’état de la machine vers la VM dans B, et défreeze la machine qui tourne alors sur le serveur B.

Si la migration est un succès, il nettoie alors la config de la VM du serveur A, sinon, il rebascule sur le serveur A.

Coté User Final, c’est un petit lag de rien du tout, même pas de quoi faire couper une session TCP. Le truc a se remémorer, c’est que quand la machine passe d’un serveur ESX a un autre, certes le poste garde sa MAC adresse, mais coté switch c’est la même chose que de débrancher un câble d’un serveur et le rebrancher dans une autre porte. À vous de prévenir le cache ARP de votre switche au mieux.

GESTION DES RESSOURCES

Choses à savoir sur le CPU

Bon ça commence à devenir long… ami lecteur que fait tu encore ici… fuis fuis tant que tu en as encore le temps…. Bon donc faisons prompt et balançons des vérités.

La console tourne toujours et uniquement sur le CPU 0.

Tout les 20 millisecondes, le Vmkernel réassigne les taches sur les cpu de façon, intelligente. il trouve les CPU flemmards.

Une machine VM Mono cpu, ne tourne à la fois que sur UN CPU.

Une Machine VM Bi cpu, tourne à la fois que sur 2 cpu physique différents.

Si le HWD Fail ( ex 1 cpu ) –> Tout Fail

Ne pas confondre : PCPU -> Physical CPU

VCPU -> Virtual CPU

LCPU -> Logical CPU ( cpu hyperthreadé )

Un PCPU Hyperthreadé contient au moins 2 LCPU.

Un PCPU HT ne contient pas réellement 2 CPU, il n’a pas la puissance de 2 CPU, cela veut simplement dire que quand un LCPU est occupé à prendre de la mémoire par exemple, l’autre LCPU travaille, c’est une méthode pour optimiser le rendement d’un CPU.

L’hyper threading peut être désactivé au niveau du bios du serveur et via une variable ESX.

On peut aussi isoler une machine virtuelle de l’hyperthreading ( config de la VM ).

L’émulation de l’écran, du port série, des Floppy et du CDROM tourne dans la console et non dans le VMkernel.

Choses à savoir sur la RAM :

Haaa ça, ça me plait. Le Vmkernel utilise différentes techniques afin de conserver la RAM.

depuis j'ai pondu un article complet sur la gestion de celle ci :Article sur la gestion de la RAM du Sympathique ESX'

Le fameux Overcommitement, par exemple si une machine a 128 mo, par défaut il réservera au démarrage que 64Mo en ram et 64 mo en swap ( fichier swapvmware .vswp ) et l’attribuera en cas de nécessité.

Économisation de la mémoire, Vmkernel (encore lui) compare les pages mémoires des machines virtuelles, dès qu’il le détecte il ne stocke les identiques qu’une fois, ce qui permet de récupérer de la mémoire. Cette technique est active par défaut, on peut la disabler via les sysval. C’est celle qui m’a le plus bluffé ( si si je suis encore bluffable) .

De-allocation intelligente de la RAM, le ballon drivers vmmemctrl installé par les tools, en cas de manque de mémoire gonfle ( en fait le driver mange de la mémoire, ce qui fait swapper l’os, l’espace ‘gonflé’ est autant de ram disponible pour les autres machines. Quand on en arrive là c’est que ça commence a être raz la geule, ça vas pas tarder à ramer.

Et enfin, si malgré tout cela il faut encore de la mémoire, le vmkernet fait swapper la RAM sur le fichier de swap, n’ayant pas conscience de ce qu’il fait swapper, les performance peuvent être catastrophiques.

Il est important de noter que chaque VM utilise en plus de la mémoire qu’on lui attribue un overhead, ( mémoire vidéo, gestion du hdw virtuel etc.. ) 54 Mo pour un VCPU, et 64 pour un BICPU et plus même si la mémoire allouée de la machine virtuelle dépasse 512 Mo.

Et ne pas oublier ce que mange le serveur lui même pour manager les vm ( 192Mo pour 8 machines par exemple ) ainsi que la ram que boulotte le vmkernel pour sont propre fonctionnement soit 21Mo.

ON PEUT VOIR une recap bien jolie de cela dans l’onglet memory du mui

TUNING des Ressources

Seul un User de classe ROOT ( donc par défaut que ROOT ) peut tuner les ressources via le MUI. Un Admin user peut tuner via Virtual Center.

On peut chipoter aussi via /proc/vmware sur la console et via vmware scripting API.

Ton amis le Share

Les shares, les ressources sont tuner par shares.

Ex, 3 Virtuals machines:

Cela fera schématiquement 2 tours de Cpu pour C, 1 pour A, 1 pour B et on recommence

Si maintenant on éteint A, cela fera 2 tour de CPU pour C, 1 pour B et on recommence

Les shares peuvent être changés au vol, machine vm allumée.

La console par défaut a 2000shares, une VM 1000.

On retrouve ce mécanisme pour régler, le Cpu, la priorité d’allocation de la ram, priorité d’accès a la bande passante du disque dur.

Note les share HD son proportionnel par LUN. C’est 1000 par défaut, y compris la console

Autres possibilités avec le CPU.

Le pourcentage, cela définit le % de puissance Maxi et Mini sur le CPU,

Exemple un CPU de 1Ghz, donc on a dit mini 3% maxi 80% :

Machine virtuelle aura toujours au minimum réservé pour elle 3%, ces 3% ne seront jamais données à d’autres VM, de temps Cpu, et sera bridée a 80% de temps cpu, ( bref quasi un poste a 800Mhz maxi ), a l’intérieur de la VM quand le poste sera a 100%, sur la vm il ne sera qu’a 80%

La ressource se configure de 0 a 100% pour un CPU, et 0-> 200% pour 2 CPUs.

La console par défaut a un minium de 8%

Affinité, on peut décider sur quelle LCPU on bloque l’exécution d’un VM.

Autres possibilité avec la RAM :

On dispose d’un minimum et d’un maximum à allouer pour la ram, Le minimum c’est le minimum de ram vive toujours réservée a la machine VM. Le maximum est le maximum de Ram vive que peut utiliser la VM. L’ensemble max-min de toutes les VM doit être inférieur au swap.

Les shares configuré par défaut est de 10 par Mo de Ram dispo.

Une machine VM ne peut démarrer que si le minimum requis est dispo, ( par défaut 50/50 ex 128 mo sur une VM = 64 min, et 64 swap ) et que la différence est disponible dans le swap.

Tunnig possible du Réseau

on peut restreindre le débit sortant uniquement ( quand c’est arrive c’est déjà trop tard, utiliser alors une méthode en amont )

Average Bandwith, Band passante moyenne

Peak Bandwitz, bande passante maximalke

Busrt size, debit autorisé pour le peak

Par défaut ce tuning est coupé.

Pour plus d’infos sur le tuning tuning, direction la console et lancez man cpu, mem, numa, diskbw, hyperthreading, net, nfsshaper.

LE CONTROLE D’ACCÈS

Hoooo ca devient chiant tout cela non… Vmware dispose de 4 niveaux de sécurité, que ce soit via le Mui ou via VC.

Administration du Système

Administration d’une VM

Gestion du Power d’une VM

Voir l’état d’un VM

Ensuite en fonction que l’on dispose de VC ou pas, la gestion des droits diffères.

Avec le serveur ESX les droits sont contrôlés via les droits fichiers Linux, les fameux RWX.

Selon les droits du VMX et les VMDK associés on a

R -> peut voir la machine dans le Mui

X -> peut jouer avec le power

W -> peut jouer avec la config

Avec a chaque fois, Owner, Group, Other

Ex sur un fichier config j’ai les droits suivants :

RWXR-X--- root toto

L’user root peut tout faire, les membres du groupe toto, peuvent voir la machine et la démarrer.

On peut changer ces droits via chmod ou le file manager du Mui.

Puis les membres du group ROOT ( par défaut que Root ) peuvent jouer avec la config du serveur ESX.

Si Virtual center est utilisé, les droits diffères, le serveur VC utilise toujours un user vpxuser qu’il a créé lors de la 1^er connection du serveur ESX à la ferme Virtual Center, pour faire quoi que ce soit sur le serveur ESX, mais en amont, sur le serveur VC, les droit sont gérés, on utilise alors soit des users locaux soit ceux du domain dont appartient le serveur VC.

On retrouve alors les mêmes droits cité avant, plus un, le Virtual Center Administration, qui a droit de changer les permission VC et de mettre a jours les licences.

Dans VC, les droits sont hérités de hauts en bas , idem active directory.

En bref, dans VC les droits sont plus pointus, et disposent de la possibilité d’utiliser les droits windows. Avec juste ESX, ce sont les droits au niveau fichier, des users/groups locaux.

Le monitoring et le tuning

Rhaaa rhaaa courage ça se termine, vous voyez bientôt le bout du tunnel. Donc ont dispose de pas mal de tools pour monitorer l’état de la bête, via le Mui, on a une idée précise du cpu et de ram au cours de 5 dernières minutes, on peut utiliser le virtual center pour avoir un environnement complet avec historique, on peut utiliser vmkusage qui est un site web qui reprend l’historique du moment qu’on a installer le vmkusage dans le cron (vmktree est un concurrent officieux plus sympas, il permet de Zoomer, allez donc voir http://tihlde.org/~larstr/vmktree/ ) et enfin en ligne de commande.

Pour des infos instantanées esxtop, et voir l’état du système des cat dans /proc/vmware

Le principe général est de trouver les bottleneck, et d’allouer plus a ceux qui en ont vraiment besoin.

Pour info dans esxtop, la console doit avoir un ready time de 0 à 3, de 3 a 10 elle bosse, au-dessus il y a surcharge.

Donc on doit vérifier les Ready time des cpu, la présence de swap au niveau de la mémoire ballon et swap réel, on peut jouer avec les share pour privilégier telle ou telle machine.

Vérifier aussi les share disque pour voir éventuellement le réglage share, le move de la station quelque part ou le lun est moins sollicitée etc …

Idem pour le rezal, /proc/vmware/net/vmnic…., vérifier que c’est bien des vmxnet quand on le peut, la bande passante est pas raz la geule etc …

Penser pour vous alarmer de tout cela a utiliser les alarmes ( bonne introduction n’est ce pas ) dans virtual Center, celle ci peuvent envoyer un email, faire une notification snmp, lancer un script, et par vm, jouer avec les options de power, jouer avec Vmotion peut être une solution.

Sinon Tenir la console à l’œil aussi

La console aussi peut être source de contention, si au top ou uptime, le load average est supérieur a 1, c’est que le CPU est sur alimenté. La console rame, et on oublie pas Pour alléger la console, le bien pratiquer le vmware, dis: pas de remote console si pas nécessaire, pas d’utilisation de disquette et de cdrom dans les VM si possible, pas de X windows sur la console Vmware ( si si les gens l’on fait ) Bien faire gaffe au soft additionnels fourrés dans la console ( backup agent, moniteur tierce et).

Utiliser free –m, vmstat et /ou /proc/meminfo pour avoir l´état ram.

Coté disques, Vdf permet d’avoir l’état de charge des HD ( vdf –h est sympas pour l’humain que vous êtes ) , df existe mais ne prend pas en compte les partitions vmfs, si un disque semble full sans raison utiliser find pour trouver le fichier pénible qui bourre le disque.

Pour trouver qui lock un fichier un petit « lsof | grep REG » fera l’affaire.

Coté remontée d’info pour avoir tout ceci a l’oeuil Vmware dispose de la possibilité d’activer le SNMP, pour l’activer dans le MUI en Root, option -> snmp configuration ( et on choisis démarrage auto ou manuel ).

Par défaut la config est RO pour le domaine public.

Les Mib vmware sont dispo dans

/user/lib/vmwaree/snmp/mibs

les trap sont configurable dans /etc/snmtp/snmpd.conf pour l’esx ou via la VC console.

BACKUP & DISASTER

BACKUPER

Alors là on a le choix, soit Le backup traditionnel comme sur un vrai serveur, avec un agent interne ( et oui le backup traditionnel c’est pas avec un tape en bois ), soit en prenant avantage du principe d’encapsulation, ( par dessous ) car tout est fichier, la config de la VM ainsi que les disques durs des stations.

Ce principe peut être amélioré car avec la fonction redo, il et possible de prendre un backup d’un VM en état de marche. Cette méthode est par contre pas recommandée pour les serveur de type BASE ( sql etc ) ainsi que les serveur Mails exchange.

Mais c’est l’idéal pour des serveur DC, de d’applis simples ou de Citrix.

C’est évident aussi, que, comme sans Vmware, c’est une bonne idée de séparer OS des SOFT ( on découpe deux HD un C : et un D : ) ce qui est d’ailleurs par après l’idéal pour partir d’un template ou clone.

Quoi backuper :

Si on utilise Vcenter le user vpxuser a son home dans /home/vmware, sinon les machine sont stockées dans le Home de leur owner

Il nous faut : lefileconfig.vmx

Les paramètres bios : nvram

Le dernier log : vmware.log

Et aussi dans la partition VMFS,

Le/les vmdk ( disque dur )

Le vmss ( fichier freeze qui contient la ram )

Le redo ( éventuellement )

À noter un sympathique script vmkb.pl s’occupe de faire les redo et d’exporter via VMKFSTOOL les disques dans un rep de notre choix ( qui peut être un share smb monté par exemple ).

Le vmsnap.pl fait la même mais copie via SSH sur un autre serveur , une bonne idée pour un failover.

Le backup de la console :

Idem , via agent ou autre, ce qu’il faut c’est /etc tout est la, le script vm-support qui est normalement utilisé pour snapshoper la config et l'envoyer à vmware peut être utiliser pour vous aussi. Mais c’est toujours stressant psychologiquement car il n’y a pas TOUT le répertoire /etc dedans.

CLUSTERER

Alors la aussi coté possibilités c’est OPEN BAR, On peut déjà clusteré les VM

Soit via Cluster-in-a-box,

Tout le clustering étant dans le même serveur ESX, cela protége des crash software.

Il faut mettre laisser partition VMFS en type public et mettre le bus Sharing de la carte SCSI virtuelle des machines qui est connecté aux disques partagé ( quorum ) en VIRTUAL

Le Cluster-across-box,

en faisant le clustering de VM dans des serveur ESX différents, les vmdk étant alors dans un LUN de SAN sharé. Pour cela il faut mettre le bus sharing de la carte SCSi virtuelle en Physical, la partition elle VMFS elle en shared pour lui indiquer de laisser ouvrir un fichier par plusieurs machines, et bien sur l’utilisation de switche réseau interne pour le heartbeat n’est plus possible.

Et le Cluster P & V, ( Physical to Virtual )

Soit le cluster entre une machine physique ( un vrai serveur normal ) et une machine VM a l’intérieur d’un serveur ESX, le tout via un LUN accédé directement ou via RDM (les disques oranges) .

On peut aussi cluster directement les serveur ESX

Via Veritas Cluster Serveur, bon là ça fait peur, c’est supporté par veritas , pas par Vmware et Virtual Center et donc Vmotion aussi ne fonctionnent pas avec …. Glups quoi

Autostart/autostop

Et en cas de problèmes de Power ( un arrachage de prise par la femme de ménage etc … ) pensez à avoir paramétré l’autostart et l’autostop des machines ( encore qu’en cas d’arrachage de prise l'autostop est forcément pris de court ) c’est pas mal de voir démarrer après l’esx lui meme nos VM tant attendues, pour cela dans le mui/options on peut choisir d’activer l’autostart & l’autostop, ainsi que l’ordre dans laquelle cela démarrer, et le temps de pause entre le démarrage des machines.

Proctologie, Allons plus au fond de l’esx lui même.

Comment ESX Boot ?

Techniquement c’est comme un pingouin normal, la machine démarre, le bios passe, fait sauter le secteur 0 du disque la le LILO prend le relay, lilo ( Linux Loader ) s’occupe de vous afficher un joli menu et ensuite de démarrer sur le noyau linux alias notre service Console,

Lilo est paramétrable via le fichier de config /etc/lilo.conf, mais attention il faut ‘compiler’ ces modifications, lilo ne lis pas lilo.conf au boot pour cela,lancer juste lilo en ligne de commande fera l’affaire, mais Mr Vmware préconise un lilo –c /etc/lilo.comf –v ( verbeux et en spécifiant le fichier de config ).

C’est dans ce fameux lilo qu’est fait la réservation de ram pour la console. En fait c’est plutôt de la contrainte a utilise SEULEMENT X Mo de Ram par le noyo Linux.

Bref le lilo enclenche le noyau (Un linux modifié), ( posé dans /boot ), celui ci lance le script init ,c’est pour l’instant un démarrage de Linux standard dirons nous, init lance /etc/inittab qui gère les console, le type de démarrage est un multi User/Texte Mode/network soit un init 3.

Le système exécute les scripts qu’il trouve dans /etc/rc.d/rc3.d et lances les script nommés S quelque chose dans l’ordre des numéros ... dont les plus importants sont ;

S10network démarre le réseau, monte les interfaces ip LO ( LoopBack alias locahost ) et celle de la console.

S21syslog démarre le moteur de l’event viewer linux ( amis Windowsien je sais que tu m’as compris ).

S55sshd démarre le deamon SSH pour l’accès distant.

S56xinetd est responsable de démarrer le service d’écoute VM port 902 nommé vmware-authd.

S90vmware est celui qui nous intéresse le plus. C’est celui qui démarre le Vmkernel en utilisant vmkloader ;

Il monte les drivers Vmkernel

Il monte les volumes sous /vmfs

Démarre vmware-serverd qui est le processus celui qui s’occupe de la gestion d’authentification derrière le port 902.

NOTE : quand on utilise VC, vmware-serverd est remplacé par vmware-ccagent

Partant de là c’est lui le maître d’orchestre CPU qui considère le précédent noyau comme

Une simple VM

S91httpd.vmware démarre l’apache qui va nous servir de MUI

Et au final, une Virtual Machine est donc un ensemble de processus qui tournent en partie dans la console, et en partie dans sous le noyau Vmkernel, c’est pour cela qu’il reçoivent un PID (Process ID coté linux) et un VMID (Virtual Machine ID appelle aussi World ID qui débute à 140) coté Vmkernel. Le parent de ces processus est vmware-vmx

ET voilà vous savez tout…. Maintenant faut s’en rappeler.

Exam, je l’aurais pas je l’aurais pas….

Bon l’exam qui suit le cours Vmware ESX + Virtual Center , c’est simple c’est 80 gentilles questions QCM qui reprennent tous les chapitres du cours…a savoir :

· Understand VMware Products

· Differentiate Among VMware Products

· Understand the Architecture of ESX Server

· Install and Configure ESX Server

· Operate and Manage ESX Server

· Configure Networking Under ESX Server

· Set ESX Server Resource Allocation Policies

· Administer Virtual Machines Under ESX Server

· Monitor and Tune ESX Server

· Configure Clustering Between ESX Server Virtual Machines

· Troubleshoot an ESX Server

Allons-y directement il y a une bonne partie de question que je qualifierai de ‘questions de Putes’ du genre…. Quel est la moins crédible des hypothèse qui pourrait expliquer la panne suivante…

Bon j’ai eu de la chance je m’en suis tiré… j’ai signé leur feuille donc la déontologie ( qui est fortement implantée chez moi ) et elle m’interdit de vous donner les questions, cependant si vous avez des question sur l’examen,

Mr Vmware vous répond : http://www.vmware.com/services/cert_faqs.html

Et en prime il vous file un petit questionnaire de test pour vous mettre dans le Bain :

http://www.vmware.com/services/cert_questions.html

Un autre truc sympathique pour réviser, c’est RTFM pas la doc pour ce coup ci mais

http://www.rtfm-ed.co.uk/vmware/default.htm un pti gars bien sympathique.

Coté réviseur de cours, j ‘ai encore rien trouvé chez bozon ou autre ça doit être trop frais encore je pense. Mais cela devrait arriver.

Autre ‘Tip’ lisez au moins une Fois les 400 pages de la doc, c’est un chouilla plus gros de la constitution européenne mais c’est pas la fin du monde, allez allez pour vous motiver sachez que dedans il y a la solution pour que la remote console s’ouvre directement a partir du Mui si vous utiliser Firefox ... Motivant non ?

Epilogue

ET voilà en espérant que c’était pas trop long, et que personne ne se soit endormi, mais bon dans la mesure ou c’est un sujet pour deux mois, autant qu’il soit un peut plus conséquent que les autres fois,) d’autant plus qu’à mon avis l’Orval a pas dépassé la page 13 et que dans ces conditions c’est pas simple.

Comme toujours, les remarques constructives ou des trouvaille d’horreur sur ces pages vers thanspam@trollprod.org …. et ceux qui encore une fois sont allergiques à mon orthographe et/ou a mon style que les plus prudes qualifient de détendu, ne vous acharnez pas à écrire, après tout je force personne à lire. C’est vous qui voyez.. ;)

On applaudit encore une fois le Chef Chaudard du calvaire de relecture qu’il a enduré…

Allez bonne semaine….sous vos applaudissement…