VMware Education vient de mettre à disposition de tout le monde des vidéos techniques autour des solutions comme vSphere, vCloud ou encore SRM et ce, gratuitement.
Pour en profiter, cliquer sur le lien suivant : http://vmwarelearning.com/
VMware Press a choisi le livre co-écrit par Eric Maille et René-François Mennecier, VMware vSphere 5 au sein du datacenter, pour être traduit en anglais et mis à disposition à l’ensemble de la communauté internationale. Félicitations à Eric et René-François !!!
Aujourd’hui j’ai rencontré la problématique suivante: J’ai voulu migrer le port vmkernel dédié au management traffic d’un virtual switch standard existant vers un virtual switch distribué depuis le vSphere Client mais cela n’a pas fonctionné correctement.
La procédure en temps normal est de s’assurer d’avoir une redondance réseau (nic teaming) au niveau du vmkernel portgroup du Vss avant de procéder à la migration vers un dvportgroup d’un vDs. On rajoute le host depuis l’interface Networking (Home -> Networking) du vSphere Client en prenant le soin de sélectionner une seule des deux cartes réseaux faisant partie du nic teaming pour le port vmkernel à migrer vers le vDs. Malheureusement lors de cette phase de migration, la carte réseau à migrer avec la configuration IP du vmkernel se retrouve systématiquement sur le premier DvUplink créé sur le vDs ; or ce DvUplink1 n’a pas la bonne configuration associé pour le management traffic (Vlan ID). Le host se retrouve alors dans un état isolé et n’est plus joignable.
Pour résoudre ce problème et migrer correctement son port vmkernel sur le dvportgroup correspondant au management traffic, il faut passer par une remote console (de type KVM ou iLO) et activer le local tech support mode puis faire alt+F1 pour passer en mode support. Une fois en mode support, faites un esxcfg-vswitch -l pour lister la configuration active des switchs virtuels standard et distribués.
Vous verrez alors un DVport ID attribué pour un client de type vmk0 (qui correspond au vmkernel management traffic) et la carte réseau attribué au premier DVPort ID (attribution réalisée de façon automatique lors de la tentative précédente de migration via le vSphere Client). Il faudra alors réattribuer la carte réseau du premier DVPort ID au DVPort ID correspondant au DVportgroup du management traffic (avec la bonne configuration VLAN associée)
Procéder alors comme suit :
1) esxcfg-vswitch -Q vmnic -V DVPortID_1 dvSwitch_name (permet de retirer la carte du DVPort ID mentionnée par DVPortID_1 )
2) esxcfg-vswitch -P vmnic -V DVPortID_mgmt_traffic dvSwitch_name (permet de réattribuer la carte réseau au DVPortID correspondant au DVPortgroup du management traffic sur le vDs)
Le host ne se retrouve plus isolé et vous avez correctement réalisé la migration de votre port vmkernel d’un switch virtuel standard vers un switch virtuel distribué.
Eric Maillé a récidivé et cette fois-ci avec un ouvrage sur vSphere 5. Pour tout professionnel de l’informatique qui se respecte et qui cherche à appronfondir ses connaissances sur la virtualisation VMware avec la dernière version qu’est vSphere 5, le livre d’Eric qui s’intitule : VMware vSphere 5 au sein du Datacenter est fait pour vous !!!
Ce livre a été co-écrit avec René-François Mennecier que je salue au passage pour son commentaire laissé sur mon blog 🙂
Alors n’hésitez pas et achetez le ; parlez en aussi autour de vous. Il est disponible aux editions ENI.
En ce jour qu’est le 12 Juillet 2011, VMware sort enfin la version 5 de vSphere.
Au programme de cette nouvelle version de vSphere :
– Des machines virtuelles pouvant aller jusqu’à 1To de mémoire, 32 vCPUs
– Une refonte de VMware HA avec la notion de master/slave pour les nodes (il n’y a plus de notion de primary nodes limités à 5 primary). AAM n’existe plus, place à FDM (Fault Domain Manager)
– Storage DRS (on peut créer un cluster de datastores et tout comme DRS, sDRS se chargera automatiquement de migrer les données sur des datastores en fonction de l’occupation et de la charge IO)
– Profile-Driven Storage (création de profils de données spécifiques pour les machines virtuelles ; ceci permettra notamment en connaissant les besoins en terme de données ou d’IOps pour une machine virtuelle donnée d’y affecter un profil spécifique)
– vStorage API (amélioration du VAAI avec possibilité de réclamer l’espace perdu lors de suppressions de machines virtuelles sur un datastore)
– Stateless (possibilité de lancer des installations d’ESXi 5 en diskless et d’avoir une seule version qui sera patché et maintenu grâce à vCenter pour ensuite être massivement déployé sur l’ensemble des serveurs ESXi 5 de vos environnements)
Il y a encore plein d’autres nouveautés avec cette version majeure de vSphere !!! Je reviens vers vous très vite pour partager tout ça…
VMware rules !!!!!
Vous cherchez la façon la plus simple pour déployer vos serveurs ESXi 4.1 ? Un serveur de déploiement administrable depuis vCenter via l’installation d’un plugin ? Tout cela est maintenant possible grâce à PXE Manager pour vCenter. Ce serveur de déploiement a été développé par Massimiliano Daneri et est téléchargeable sur la page des VMware Labs.
Au menu de ce plugin PXE Manager for vCenter :
– Automated provisioning of new ESXi hosts stateless and statefull
– ESXi host state (firmware) backup, restore, and archiving with retention
– ESXi builds repository management
– ESXi Patch management
– Multi vCenter support
– Multi network support with agents
– Hosts memtest
– vCenter plugin
– Deploy directly to VMware Cloud Director
– Deploy to Cisco UCS blades
Vcenter est maintenant totalement autonome grâce à ce plugin ; il est maintenant possible de gérer l’installation, la configuration et l’administration de la machine physique jusqu’à la machine virtuelle depuis son vSphere Client. A vous de tester !!!
Salut à tous,
Après de longs mois d’absence, je suis de nouveau de retour sur la blogosphère VMware. J’en profite pour souhaiter à tous mes readers une bonne et heureuse années 2011.
Tout plein de nouveaux projets pour moi cette année : nouveaux challenges professionnels, passage de la certification VCAP-DCA (VMware Certified Advanced Professional)
Je ne manquerais pas, malgré tout cela, de vous poster dès que possible de nouvelles astuces, des news ou encore des How-To
A très vite 🙂
Nous savions déjà qu’avec la prochaine mouture de vSphere, la version 5, l’implémentation de DRS (Distributed Resource Scheduling) for Storage, Host-based replication for SRM (Site Recovery Manager) et Network I/O Control allait être faite. Mais voilà que sur le web, plus d’informations ont filtrées sur sur le sujet.
Voici donc les grandes nouveautés annoncées en plus des précédentes déjà connues :
– Build on the vSphere ESXi hypervisor architecture
– vSphere Auto Deploy combining host profiles, Image Builder and PXE
– Unified CLI framework, allowing consistency of authentication, roles and auditing
– Support for up to 1 TB of memory
– Support for 32 vCPU’s per VM
– Nonhardware accelerated 3D graphics for Windows Aero support
– USB 3.0 device support
– UEFI virtual BIOS
– Host EUFI boot support
– New GUI to configure multicore vCPUs
– Client-connected USB devices
– Smart card reader support for VMs
– Apple Mac OS X Server 10.6 (Snow Leopard) guest OS support
– Support for up to 512 VMs
– Support for up to 160 Logical CPUs and 2 TB or RAM
– Improved SNMP support
– Storage driven storage delivery based on the VMware-Aware Storage APIs
– Improved version of the Cluster File System, VMFS5
– Accelerator for specific use with View (VDI) workloads, providing a read cache optimized for recognizing, handling and deduplicating VDI client images
– iSCSI user interface support
– Storage APIs – Array Integration: Thin Provisioning enabling reclaiming blocks of a thin provisioned LUN on the array when a virtual disk is deleted
– Swap to SSD
– 2TB+ LUN support
– Storage vMotion snapshot support
– vNetwork Distributed Switch improvements providing improved visibility in VM traffic
– ESXi Firewall protecting the ESXi 5.0 management interface
– A browser-based, fully-extensible, platform-independent implementation of the vSphere Client based on Adobe Flex
– vCenter Server Appliance
– Inventory Extensibility: providing a manager to monitor partner extensions
– vCenter Solutions Manager, providing a consistent interface to configure and monitor vCenter-integrated solutions developed by VMware and third parties
– System message logging enhancements
– Revamped VMware High Availability (HA) with Fault Domain Manager
– All hosts in cluster can be primary nodes
– Cluster also uses shared storage as a channel for heartbeat detection
Il arrive parfois que d’anciens plugins soient encore présents depuis votre plug-in manager ; ces plugins dont vous n’avez plus forcément besoin (suite à l’installation – désinstallation de diverses appliances virtuelles par exemple) peuvent très vite polluer votre plug-in manager.
Voici la méthode à suivre pour supprimer un ou plusieurs plugins obsolètes :
1. Dans un navigateur internet, accéder à l’url suivante : http://<vcenter server name ou IP>/mob (où “vcenter server name ou IP” est le nom de votre serveur vCenter ou son adresse IP)
2. Cliquer sur Content
3. Cliquer sur ExtensionManager
4. Choisisser et copier le nom du plugin que vous souhaitez supprimer
5. Cliquer sur UnregisterExtension. Une nouvelle fenêtre apparaîtra.
6. Coller le nom du plugin que vous souhaitez supprimer et cliquer sur Invoke Method. Le plugin sera alors supprimé
7. Fermer la fenêtre
8. Faites un refresh de la fenêtre :
Managed Object Type:ManagedObjectReference:ExtensionManager afin de vérifier que le plugin a été correctement supprimé
Vous n’avez plus qu’à essayer 🙂
Veuillez suivre le lien suivant dans mon espace troubleshooting afin de connaitre les différentes méthodes possibles pour synchroniser au niveau NTP des machines virtuelles Windows implémentées sous vSphere 4 :
– Windows VM NTP Synchronization
En espérant que ce how-to vous soit utile 🙂