Détails

Écrit par Jb

Catégorie : VMware

Publication : 3 septembre 2010

Affichages : 113161

Les divers flux de communication entre les différents éléments d'une infrastructure vSphere (par exemple le dialogue entre le serveur ESX(i) et le serveur vCenter) transitent dans un canal sécurisé avec SSL. Par défaut les certificats SSL qui permettent le chiffrement / déchiffrement du trafic réseau crypté, et qui sont générés automatiquement lors de l'installation de ESX(i) ou de vCenter sont auto-signés et sont des clés de 512 bits. Il est légitime pour des raisons de sécurité (et en outre recommandé par VMware), de souhaiter remplacer les certificats d'origines par d'autres émis par une autorité de certification digne de confiance. Il est possible de se tourner vers une autorité de certification externe comme VeriSign, ou alors d'utiliser une autorité de certification interne à l'entreprise.

La documentation VMware à ce sujet est un peu floue et je vais donc décrire ici mon propre retour d'expérience avec l'utilisation d'une autorité de certification sous Windows 2008 R2.

Détails

Écrit par Jb

Catégorie : VMware

Publication : 11 juin 2010

Affichages : 25047

Il n'est malheureusement pas encore possible de démarrer nativement une machine virtuelle VMware Workstation (même avec la version 7.1) sur une clé USB bootable. Pourtant il m'est arrivé quelque fois de vouloir tester une clé USB bootable, et je suis tombé sur un billet qui explique une solution de contournement utilisant un gestionnaire de démarrage.

Détails

Écrit par Jb

Catégorie : VMware

Publication : 15 juillet 2010

Affichages : 46115

VMware a sorti le 13 juillet dernier la version 4.1 de son environnement de virtualisation vSphere. Cette nouvelle mouture propose quelques améliorations et innovations intéressantes. La suite de cet article a pour but de présenter rapidement et de façon non exhaustive ces nouveautés dans la pratique.

Détails

Écrit par Jb

Catégorie : VMware

Publication : 30 janvier 2010

Affichages : 45799

Vote utilisateur: 1 / 5

Introduction

Les hyperviseurs que sont ESX 4 et ESXi 4 proposent (comme dans la version 3.5) une gestion avancée de la mémoire physique. Le noyau du système (désigné par VMkernel) gère l'ensemble de la mémoire disponible dont une partie lui est réservée, et une autre réservée, dans le seul cas d'ESX, au Service Console (ESXi en étant dépourvue) qui par défaut occupe environ 300 Mo (au maximum 800 Mo). Le reste de la mémoire est utilisable par les machines virtuelles moyennant pour chacune d'elle un "overhead" (espace mémoire supplémentaire utilisé par le VMkernel pour les traitements liés à la gestion de cette mémoire) qui dépend de l'espace mémoire et du nombre de vCPU qui leur sont alloués.

ESX(i) 4 permet une sur-allocation de la mémoire, c'est à dire qu'il est possible d'attribuer à l'ensemble des machines virtuelles sur un serveur hôte, plus de mémoire que ce dernier n'en possède réellement. Afin de gérer efficacement cette sur-allocation, et ce, même en cas de contention (quand les machines virtuelles se disputent l'accès aux ressources physiques), VMware a doté ESX(i) de 3 différents mécanismes de gestion de la mémoire : le "Transparent Memory Page Sharing", le "Balloon driver" (vmmemctl), et le "VMkernel Swap". Le premier est activé par défaut (il peut être désactivé) et fonctionne systématiquement (même sans contention). Les deux derniers n'entrent en jeu qu'en cas de contention, et le serveur ESX(i) qui doit trouver de la mémoire pour une machine virtuelle, préfère d'abord le "Balloon driver", puis le "VMkernel Swap" en dernier recours (ce dernier étant bien sûr le moins satisfaisant en termes de performances).