admin

Un petit post pour annoncer une prochaine série de posts décrivant le projet JinFeng.

JinFeng est un nom chinois signifiant « Phoenix doré ».

C’est le nom que j’ai choisi pour la plateforme d’intégration et de tests que je suis en train de construire à base d’outils open-source et de scripts écrits en python/jython.

Cette plateforme repose principalement sur les outils Jenkins/TestLink/RobotFramework/Selenium/Sikuli, fonctionnant ensemble grâce au plugin Jenkins/Testlink de Bruno P. Kinoshita et des scripts de ma composition.

Une version 0.2 est déjà packagée mais je ne la trouve pas d’un niveau suffisant pour être diffusée.
J’ai également prit un peu de retard sur la rédaction des articles décrivant la plateforme, pour des raisons d’ordre « professionnel ». Mais tout devrait bientôt rentrer dans l’ordre. D’ici là, voici déjà un schéma général de l’architecture de la plateforme JinFeng.JinFeng

 A très bientôt pour plus de détails.

Olivier

TestLink est un outil de gestion de tests open source.

Il permet de créer des projets de tests, composés de plans de test, suites de tests, cas de test.

Il permet également de définir des exigences, ainsi que des Builds, Platforms…

Enfin, il peut générer tout un ensemble de métriques et de rapports permettant de suivre la couverture des tests, les campagnes de tests, les anomalies découvertes…

TestLink offre la possibilité d’automatiser un certain nombre d’opérations via une API qui utilise le protocole XML-RPC.

Dans le cadre du projet JinFeng, j’ai donc eu le besoin d’utiliser l’API de TestLink en utilisant le langage Python, qui est l’un des composants choisi pour développer JinFeng.

Le principe de JinFeng est de créer une plateforme de tests permettant d’effectuer toutes les étapes de l’industrialisation de tests (déploiement des environnements, installation des AUT, gestion documentaire des tests, gestion des campagnes de tests, exécution des campagnes de test de charge/fonctionnelles/techniques/etc…, collecte des résultats, création de métriques et de rapports, suivi des anomalies), tout ceci automatiquement, et si possible en utilisant des ordres en langage naturel. Chacune de ces tâches étant réalisée par un outil open source différent, le lien est réalisé par un « noyau » écrit en Python. Utiliser le même langage pour l’ensemble de la plateforme me semble être une des conditions primordiale pour la réussite de ce projet.

Ne trouvant pas de librairie open source complète en Python permettant d’accéder à l’API de TestLink, j’ai donc été obligé d’en démarrer le développement.

Je la met à disposition en open source sur github, pour tous ceux qui souhaitent à leur tour améliorer leur utilisation de TestLink en automatisant des tâches avec Python.

La librairie (TestLinkAPI.py) est disponible ici:

https://github.com/orenault/TestLink-API-Python-client

Je fourni également un exemple d’utilisation, permettant de créer :

– un nouveau projet

– un plan de test

– 3 suites de test

– 2 cas de tests composés chacun de 5 étapes de test

Dans un prochain article, je détaillerai le contenu de la librairie ainsi que son fonctionnement.

Remerciements à:

Bruno P. Kinoshita (pour son développement de l’API en Java)

James Stock (dont l’ébauche de client m’a inspiré : testlink-api-python-client R7)

 

Pour un certain nombre de raisons, vous pouvez être amenés à vouloir visualiser l’arborescence des objets (Hosts, Datacenters, VM, Pool, Resource Pool, etc…). Par exemple, si vous souhaitez automatiser certaines tâches, il vous faudra reconstituer la branche permettant d’atteindre un template, un pool de ressources…

C’est une action assez facile à réaliser, mais comment ?

Ouvrez tout simplement un navigateur Web, avec l’URL suivant :

https://xx.xx.xx.xx (avec xx.xx.xx.xx correspondant à l’adresse IP de votre vCenter).

Vous obtiendrez alors la page d’accueil suivante :

 En bas à gauche, vous pouvez cliquer sur le lien « Parcourir les objets gérés par vSphere » :

Vous obtiendrez alors un popup d’identification (il faut utiliser un compte utilisateur de la VM de votre vCenter) :

Si la connexion s’établit correctement, vous allez obtenir la « Home » suivante :

 Pour parcourir les objets de votre vCenter, vous pouvez alors cliquer sur « content »:

Nous obtenons alors la page « ServiceContent », qui représente l’objet de plus haut niveau, à partir duquel nous pouvons commencer l’exploration.

 

Un peu plus bas dans cette page, nous avons par exemple le rootFolder qui est notre « Centre de données ». Son identifiant interne est « group-d1 ».

 Cliquez sur « group-d1 », et vous pourrez lister les datacenters de votre vCenter :

 A partir d’un datacenter, vous pourrez lister tous les objets qui y sont rattachés : datastores, host, etc…

Parcourons par exemple le groupe « host » (group-h23), nous obtiendrons la liste des Clusters de notre Datacenter.

Continuons l’exploration de notre arbre d’objets, via le cluster « domain-c95 » (il s’agit toujours de l’Id et non du nom du cluster tel que vu dans vCenter).

 Dans les éléments listés de notre cluster, nous avons notamment un « Resources » (resgroup-96) qui semble intéressant:

Nous voyons apparaitre alors nos Pool de resources ! Un clic sur l’un d’eux (le resgroup-237 par exemple) nous le confirme, en affichant la liste des VM qui sont associées à notre pool de ressources « resgroup-237 ».

A quoi cela sert il ?

Un exemple concret est celui du déploiement d’une VM à partir d’un template. La commande cloneVM demandera en paramètre le ResourcePool auquel la nouvelle VM doit être rattachée.

Le parcours précédent nous permet de déterminer le chemin décrivant l’accès au pool de ressources :

Datacenter/Host/Resources/

 

Premiers pas avec : robotframework (et python/jython)

RobotFramework, Test Automation Platform Commentaires fermés sur Premiers pas avec : robotframework (et python/jython)
Sep 202011

Dans une série d’article  » Premiers pas avec … « , je vais vous montrer comment installer et utiliser un outil (ou un concept) en 5 minutes (parfois un peu plus).

Le présent article va traiter de robotframework.

Introduction

Qu’est ce que robotframework ? Il s’agit d’un framework d’automatisation de tests, respectant une démarche  » Keyword Driven Testing  » c’est à dire  » Tests pilotés par les mots clés « . En bref, il s’agit de s’affranchir de l’écriture de scripts de tests automatisés pour se consacrer à la rédaction des cas de tests.

Ceux-ci contiendront les mots-clés et les données de tests, et c’est robotframework qui se charge de faire la correspondance entre ces mots-clés et le script qui réalise leur « implémentation technique ».

La force de robotframework, c’est que cette implémentation technique peut être effectuée dans de nombreux langages et outils. Cela peut être par exemple du Java, du Python, un script Selenium… etc. 

J’ai choisi de vous présenter robotframework car c’est un des composants majeurs de la plateforme de tests automatisés open source que je suis en train de créer, et à laquelle je vais consacrer une longue série d’articles.

Dans la suite de cet article, je vous propose une implémentation en python, c’est probablement le plus rapide pour faire une POC (Proof of Concept).

Disclaimer

Les étapes suivantes seront déroulées sur un environnement windows, mais peuvent être réalisées également sur linux, vous devrez juste choisir les packages d’installation adaptés à votre environnement préféré (et peut-être modifier qq chemins/scripts).

Préparation

Téléchargez les différents éléments qui seront nécessaires :

robotframework 2.6.0 (‘windows 32b)

python 2.7.2 (windows 32b)

jython 2.5.2

JDK Java (par exemple le 1.6u27)

 (remarque : Java 7 est disponible depuis fin juillet pour ceux qui étaient en vacances et qui ont manqué l’info!)

Lancez l’installation du Java SDK si vous ne l’aviez pas déjà sur votre poste. Et nous allons pouvoir commencer.

Premiers pas… (déclenchez le chrono) !

1- Commencez par créer un répertoire. Par exemple c:\Tapos (Test Automation Platform Open Source).

2- Lancez l’installation de Python 2.7.2, afin de l’installer dans le répertoire créé précédemment. Déroulez l’installation comme suit :

     

 3- Lancez l’installation de Jython 2.5.2, afin de l’installer dans le répertoire créé précédemment. Déroulez l’installation comme suit :

        

4- Lancez l’installation de Robotframework, celui-ci va se positionner directement dans le répertoire d’installation de Python.

   

(remarque : regardez l’écran 4… il y aura toujours besoin d’experts en Assurance Qualité Logiciel!)

5- Mettez à jour vos variables d’environnement JAVA_HOME, CLASSPATH ainsi que PATH.

De sorte que :

CLASSPATH = C:\Program Files (x86)\Java\jdk1.6.0_27;

JAVA_HOME = C:\Program Files (x86)\Java\jdk1.6.0_27;

PATH = (votre PATH existant) + C:\Program Files\Java\jdk1.6.0_17;C:\tapos\jython2.5.2\;C:\tapos\Python27\;C:\tapos\Python27\Scripts;

6- Créez un sous-répertoire « core », dans le répertoire « Tapos »

7- Créez un sous-répertoire « lib », dans le répertoire « core »

Vous devez obtenir l’arborescence suivante :

(vous pouvez changer les noms, mais il faudra penser à répercuter cela par la suite)

A ce niveau, nous avons installé le « moteur » de notre plateforme de test, aussi surprenant que cela puisse paraitre !

Passons à la phase suivante, qui va nous permettre de vérifier si le moteur fonctionne.

8- Créez, dans le répertoire « c:\Tapos\core\lib », un fichier « TechLib.py », qui va contenir les lignes suivantes :

#Created on 17 sept. 2011
#@author: sqaopen

import subprocess
from socket import gethostbyaddr

def lookDNS(ip):
      lDNS = subprocess.Popen([‘nslookup’,ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]
      DNS=lDNS[lDNS.find(‘Nom’)+9:(lDNS.rfind(‘Address’)-2)]
      return DNS

def lookPING(ip):
      lPING = subprocess.Popen([‘ping’, ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]
      PING=lPING[lPING.find(‘perte’)+6:lPING.rfind(‘%’)]
      return PING

9- Créez, dans le répertoire « c:\Tapos\core\lib », un fichier « Network.py », qui va contenir les lignes suivantes :

#Created on 17 sept. 2011
#@author: sqaopen

import TechLib

class Tools(object):
 
  def checkComputer(self, *args):
      ip = args[0]
      print ‘DNS: %s’ %(TechLib.lookDNS(ip),)
      print ‘perte: %s’ %(TechLib.lookPING(ip),)

 10- Créez, dans le répertoire « c:\Tapos\core\ », un fichier « TestSuites.txt », qui va contenir les lignes suivantes :

***Settings***
Library  Network.Tools  WITH NAME  Tools

***Test Cases***
Check the computer « 127.0.0.1 » with ping and nslookup
      check Computer        127.0.0.1

 10- Créez, dans le répertoire « c:\Tapos\core\ », un fichier « launcher.bat », qui va contenir les lignes suivantes :

@echo off
set JYTHONPATH=C:\tapos\jython2.5.2\Lib
jybot –pythonpath=lib –outputdir=results –loglevel=DEBUG %*

Et voilà, c’est fini. Nous venons d’implémenter notre premier mot-clé !

Comment exécuter notre test ?

Ouvrez une ligne de commande, allez dans le répertoire core et tapez la commande :

> launcher.bat TestSuites.txt

Vous devriez obtenir le résultat suivant :

 

Voilà, vous venez de réaliser votre premier test orienté BDD, ou « Keywoard Driven Testing ».

Explications !

Le fichier « TestSuites.txt » permet de décrire votre scénario de test, en utilisant un ensemble de mots clés ainsi que les jeux d’essais à utiliser pour vos tests. Dans cet exemple, nous avons un seul cas de test composé d’un seul step de test, et qui consiste à controler l’ordinateur « 127.0.0.1 » (c’est à dire le localhost, vous-même).

Le fichier « Network.py » est une sorte de dictionnaire. C’est la description « technique » de vos différents mots-clés. Dans ce « premier pas », nous n’avons défini qu’un seul mot clé pour faire simple. Mais il est évident qu’une plateforme de test automatisée doit disposer de centaines, voire milliers de mots-clés disponibles. Notre mot clé « check machine » a donc comme instruction d’écrire (directive ‘print’), le résultat des commandes ping et nslookup sur l’adresse IP contenue dans le cas de test.

Le fichier « TechLib.py » est la bibliotheque technique, c’est à dire la véritable implémentation du test automatisé. Dans notre exemple, il s’agit simplement de l’appel de deux commandes dos et du traitement de leur retour. Pour le ping, on ne conserve que le % de paquets perdus, et pour le nslookup on récupère le nom DNS de l’ordinateur.

Le découpage proposé ici permet de découpler in fine la responsabilité de l’écriture des différents composants de notre plateforme de tests automatisés. Ainsi, nous pourrons faire appel à des développeurs pour la rédaction de la bibliothèque technique, à des experts d’automatisation de test pour le dictionnaire, tandis que des experts métiers fonctionnels peuvent écrire maintenant les cas de tests automatisés, indépendamment de tout outil (ils ne sont contraints que par le dictionnaire existant mais qu’ils peuvent faire amender).

Pour finir, vous remarquerez que Robotframework a généré des fichiers de log/report, que l’on peut consulter avec un navigateur Web. On y retrouve toutes les informations écrites par nos fonctions :

 Bluffant n’est-ce pas ?

Conclusions : l’automatisation de tests par mots-clés peut s’avérer facile à mettre en oeuvre avec un outil open-source tel que robotframework. Nous verrons dans un prochain article comment améliorer notre moteur pour lui donner la capacité à piloter nos environnements de tests (connexions SSH, pilotage de VM vmware, etc…) toujours dans un mode mots-clés.

Ayant une plateforme de qualification basée notamment sur la virtualisation vmware, et permettant de faire des tests sur des machines avec les OS windows, linux (red hat, debian, ubuntu…), Solaris, j’en profite pour déployer aussi tôt que possible les nouveaux OS virtualisables.

J’ai par exemple récemment ajouté un serveur ESXi vsphere 5 (sortie fin août 2011), afin d’améliorer mon architecture qui comprend actuellement des ESX 3.5, ESXi 4.1 et ESX 4.0.

Et cette semaine, apprenant la sortie de Windows 8 en version developer preview, je me suis donc attelé à la tâche.

J’ai comme beaucoup de monde commencé par échouer, avant de trouver une méthode un peu tirée par les cheveux mais qui me permet d’atteindre mon but : faire tourner un windows 8, sur une infra vSphere 4.1 ou vSphere 5 (les deux ayant été testées sur des ESXi).

Je présente ci-dessous les essais infructueux puis celui qui a fonctionné, et qui vous semblera finalement évident.

Etape 1 : récupérez les ISO d’installation. On les trouvent tout simplement ici en version 32 bits et 64 bits (respectivement 2.8Go et 3.6 Go). A noter : une 3ème version comportant de plus les outils développeurs, faisant 4.8 Go.

Mon conseil : placez ces ISO sur un NAS, accessible depuis n’importe quel PC/VM de votre réseau. Téléchargez à minima l’ISO 32 bits. 

Etape 2 : créez une VM sur votre ESXi 4.1 ou 5, en vous basant sur l’OS invité «Windows 7» (32b ou 64b en fonction de l’ISO que vous avez téléchargé). Ensuite, démarrez la VM, attachez l’ISO de «Windows 8» via le bouton «connecter» et lancez l’installation. Je ne détaille pas plus, car c’est la procédure classique que vous devez probablement maitriser.

Et là… C’est le drame : un magnifique écran de la mort que l’on pensaient disparu à jamais :

HAL_INITIALIZATION_FAILED

Alors vous aurez beau redémarrer la VM, refaire l’installation, en 32b ou en 64 b, changer les paramètres vmware… toujours ce satané  HAL_INITIALIZATION_FAILED. A noter un espoire : sur un vsphere 5, vous devez choisir « Windows 7 » lors de la création initiale de la VM mais vous voyez apparaitre «Windows 8» dans la liste des OS invités si vous éditez les paramètres d’une VM déjà existante. Hélas, cela ne change rien… Toujours le même plantage.

J’ai parcouru le web sans trouver de secours providentiel à ce propos. Par contre, cela m’a permis d’apprendre la sortie de vmware Workstation 8, lequel supporte l’installation de  «Windows 8». Passons donc à l’étape suivante :

Etape 3 : téléchargez vmware Workstation 8. Ce produit est payant, et pour le télécharger vous devez vous connecter avec votre compte vmware. La bonne nouvelle, c’est que l’on peut créer un compte gratuitement pour ceux qui n’en ont pas, et que vous pouvez obtenir une licence d’essai de 1 mois pour vmware workstation 8. Donc sur la page de download, vous avez d’abord la licence puis 3 versions : les packages d’installation windows 32 et 64 bits, puis linux 32 et enfin linux 64 b.

Mon conseil : téléchargez la version « windows 32 et 64 bits » (474 MB) sur votre ressource réseau et créez au même endroit un fichier texte dans lequel vous ferez un copier/coller de la licence.

Etape 4 : Installez Workstation 8 sur votre PC ou bien sur un serveur physique disponible. Les séquences sont les suivantes:

Lancez l’installer, Choisissez le mode « Typical »,  l’installation se déroule. puis saisissez le numéro de série temporaire (utilisez le fichier texte précédent), et validez la licence d’utilisation.

 

Etape 5 : Installez « Windows 8 ».

Les étapes là encore, sont assez simples. L’approche est semblable à ce que vous avez l’habitude de faire sur vSphere 4.1 : créer une « enveloppe » de VM, connecter un ISO et lancer l’installation. Il y a juste une étape « fondamentale » à respecter. Allons-y :

Commencez par lancer vmware Workstation 8, et vous aurez l’écran du décompte de la licence temporaire qui s’affichera en premier.

Après l’avoir validé, vous arriverez sur la HOME :

Cliquez sur « Create a New Virtual Machine » et vous aurez l’écran suivant :

Validez par un « Next »…

Et sur l’écran ci-dessous, sélectionnez « I will install the Operating System later ». C’est l’étape « fondamentale » que j’évoquais précedemment. Si vous conservez l’option par défaut et débutez l’installation directement, vous obtiendrez des erreurs de fichier de licence et vous n’irez pas au bout.

Après un « Next », vous continuerez sur :

Là, sélectionnez « Windows » puis la version «Windows 7» ou « Windows 7 (x64) ».

Validez par « Next », et vous devrez définir la taille disque et le type de fichier.

Mon conseil : un minimum de 25 Go me semble nécessaire, et sélectionnez « Store disk as a single size », nous verrons plus loin l’utilité de cette option. Cliquez sur « Next ».

Voilà nous y sommes… Cliquez sur « Finish ».

Vous obtenez votre VM dans la liste des VM disponibles (j’en ai deux dans cet exemple, j’ai fais plusieurs types de tests).

Si vous cliquez sur « Edit Virtual Machine Settings », vous obtiendrez l’écran ci-dessous qui vous permet de régler des paramètres dont ceux de la mémoire allouée (on retrouve l’environnement familier de vsphere).

Mais cliquez sur la ligne « CD/DVD (IDE) » puis  sélectionnez « Use ISO image file: » puis cliquer « Browse » pour aller connecter le fichier ISO de windows 8 que vous souhaitez installer :

Validez par « Ok » ce qui vous ramène sur la HOME et la liste de VM disponibles. Cliquez alors sur « Power On this Virtual Machine ». La VM démarre alors et va booter sur l’ISO…

 

 Passons sur la phase de configuration initiale (création d’un compte user), ce n’est pas le sujet de cet article.

Vous obtenez alors votre premier aperçu de la nouvelle interface utilisateur de  «Windows 8» : Metro !

A la fin de cette longue étape 5, nous avons donc un «Windows 8» installé (et qui fonctionne) dans une VM. Mais nous n’avons pas atteinds notre but car si vous êtes perspicaces, cette VM tourne sur un Serveur Physique équipé de « Workstation 8 » et non sur une infrastructure basée sur un vSphère 4.1 ou 5.0. Continuons notre quête.

Etape 6 : Transférer notre VM «Windows 8» qui fonctionne, de vmware Workstation 8 à vsphere 5. 

J’ai pensé (naïvement) qu’au vu des dates de releases très proches entre vsphere 5 et workstation 8, il y avait de fortes chances que la VM créée sous workstation 8 puisse fonctionner également sous vsphere 5. Pour cela, le plus naturel est d’utiliser « vmware converter » qui comme son nom l’indique, permet de convertir des VM entre les différents produits vmware. 

Vous voici donc à télécharger converter, l’installer et le configurer. L’installation se fait en mode standalone sur le poste qui fait tourner Workstation 8. Vous sélectionnez comme source votre VM  «Windows 8» puis fournissez les informations de connection à votre vcenter 5 (bien le vcenter, pas l’ESX!) et lancez la conversion/migration. Car comme c’est un outil « magique », il convertit et copie la VM sur votre vcenter 5.

 

 

Je passe sur les différentes étapes et les paramétrages. Car comme vous l’avez compris, quand j’ai démarré la VM  «Windows 8» dans mon vcenter 5, elle a commencé à booter mais n’a finalement pas démarré. Donc étape 6 inutile en l’état (à moins que quelqu’un connaisse des manipulations spécifiques pour la mener à bout).

Etape 7 : désespoir… Là, j’en étais arrivé prêt à faire n’importe quoi. Donc j’ai tenté le remplacement de disque virtuel.

En gros, la démarche a été la suivante :

Créer sur un vcenter 5, une VM identique à celle utilisée pour monter la VM  «Windows 8» sur le « workstation 8 » :

– même OS invité de base (windows 7), mêmes caractéristiques mémoires et disque

– suppression du disque virtuel présent sur le datastore du vcenter 5.

– upload du disque virtuel de la VM «Windows 8», depuis le serveur physique vers le datastore vcenter 5 (d’où l’utilité de sélectionner « Store disk as a single size » lors de la création de la VM initiale, car il est plus facile de déplacer un seul gros fichier!).

– utilisation de la commande « vmkfstools » pour importer le disque virtuel sur l’ESX

Il fallait s’y attendre, le démarrage de la VM sur le vcenter 5 n’a pas donné de meilleurs résultats que précédemment. On voit bien un message « Windows Developper Preview » mais la VM s’interrompt en cours de boot. Peut-être que l’étude des logs permettraient à un admin vmware à trouver des modifications de paramétrage? J’ai pour ma part abandonné cette piste.

Etape 8 : l’upgrade de version. Je me suis dit que le plus simple était finalement de faire l’upgrade d’une VM existante et fonctionnelle, pour la passer en «Windows 8». J’ai donc pris une de mes VM de test en  «Windows 7» qui me parait être le plus proche techniquement de la version  «Windows 8». Et j’ai lancé un simple upgrade après avoir connecté l’ISO d’installation.

    

J’avoue qu’à la vue du quatrième écran, j’étais plein d’espoir. Puis « l’écran bleu de la mort ».      :(

Etape 9 : Une bonne nuit de sommeil. La nuit portant conseil, j’ai finalement combiné ce qui fonctionnait :

– installer  «Windows 8» dans une VM sous « Workstation 8 ».

– installer « Workstation 8 » dans une VM sous vSphere 5.

Et oui, c’est aussi « simple » que cela au final. Dans un vSphere 5, commencez par construire (ou réutiliser) une VM en  «Windows 7» 32b ou 64b. Modifiez cependant ses paramètres pour :

– augmenter la mémoire à 4096 Mo

– attribuer des ressources mémoire et CPU importantes (le plus que peut vous autoriser votre ESXi)

– attribuer 2 CPU

– avoir au moins 20 GO de libres (rajoutez de la taille disque dans vcenter puis resizez le « à chaud » sous windows si nécessaire)

Allumez votre VM, et rebootez là à nouveau pour la prise en compte des nouveaux paramètres. Maintenant, suivez les étapes 3, 4  et 5 sur votre « VM windows 7 ». Installez une version de windows 8 en 32 bits, vous risquez de ne pas pouvoir déployer la version 64 bits en fonction des caractéristiques de vos serveurs physiques.

Vous obtiendrez alors un  «Windows 8» tournant (dans une VM  «Windows 7») sur votre ESXi 5.0.

Mon conseil : pour faire toutes les manipulations sur la VM  «Windows 7», s’y connecter en mstsc -console, et pas en utilisant le mode console vmware !

Au final, nous avons bien atteinds notre objectif : faire tourner un  «Windows 8» sur une infrastructure vSphere 5. Même s’il est encapsulé dans un  «Windows 7», vous n’avez pas besoin de monopoliser de ressources physiques autres que celles de votre infrastructure vmware.

Etape 10 : Faire la même chose sur un vCenter 4.1 ?

La simplicité avec laquelle cela s’est déroulé sur un vCenter 5 m’a poussé a tenté la même opération sur un vCenter 4.1, qui représente la majorité de mon infrastructure de qualification, et qui est le plus répandu actuellement (vSphere 5 venant juste de sortir). J’ai donc appliqué la démarche de l’étape 9 (la nuit de sommeil en moins) mais j’ai buté sur une erreur lors de la création de la VM dans « Workstation 8 » :

Grâce à ce post, j’ai pu résoudre le problème. Il faut modifier les paramètres de la VM qui fait tourner « Workstation 8 », pour activer un mode spécifique. Pour cela, éteignez la VM  «Windows 7», et dans vCenter 4.1, cliquez sur « Modifiez les paramètres » pour cette VM. Allez sur l’onglet « Options », la ligne « Avancé » / « Général » et cliquez alors sur le bouton « Paramètres de configuration… » qui va apparaitre en bas à droite.

 

 

 

 

 

 

 

 

Sur la nouvelle fenêtre, cliquez sur « Ajouter ligne » et insérez les 3 lignes suivantes (ou modifiez la valeur si la ligne existe déjà):

deploymentPlatform = « vmkernel »

monitor_control.vt32 = « TRUE »

monitor_control.restrict_backdoor = « TRUE »

Refermez tout, relancez la VM  «Windows 7», relancez « Workstation 8 » et là vous devriez voir de nouveaux messages lors de la création d’une VM :

 

 

 

 

 

 

Voilà, c’est gagné ! Vous pourrez démarrer l’installation de « Windows 8 Developper Preview » sur votre ESX 4.1.

Nous avons atteinds notre objectif : déployer un « Windows 8 Developer Preview » sur un vSphere 4.1 et sur un vSphere 5.0. Cette installation est suffisamment standard pour que l’on puisse utiliser cette VM pour faire des tests même si elle est encapsulée dans une VM Windows 7.

Et maintenant ?

Je suppose que vmware va « rapidement » communiquer un workaround sur le moyen de faire fonctionner une VM en  «Windows 8» directement sur un vCenter, sans passer par le mécanisme décrit ci-dessus. Même si « Windows 8 » n’est pas sorti officiellement (la GA ne devrait pas avoir lieu avant une bonne année), l’intérêt de la virtualisation me semble notamment être dans la capacité à pouvoir facilement et rapidement créer de nouvelles plateformes de test prenant en compte les dernières évolutions techniques, sans attendre que tout soit figé.

Si vous avez apprécié ce post, n’hésitez pas à revenir souvent car ce site devrait rapidement s’enrichir de nouveaux articles.

Voilà, depuis le temps que j’y songe, je lance enfin ce site dont le thême principal sera la qualité du logiciel, plus particulièrement évoquée sous un angle « ouvert ».

C’est donc ce qui explique son titre : SQA Open.

Pour les néophytes, SQA = Software Quality Assurance, c’est à dire Assurance Qualité Logiciel (AQL) en français.

Pourquoi « ouvert » ? Parce que je souhaite « vulgariser » ce domaine et le rendre accessible au plus grand nombre, et cela passera notamment par la présentation et l’utilisation de concepts et outils ouverts, open source, que chacun pourra utiliser simplement.

Le domaine de la qualité du logiciel est un domaine vaste et étendu, et j’espère pouvoir vous servir de guide pour vous en faire découvrir qq aspects intéressants.

Ce site sera certainement amené à évoluer énormément dans les semaines et les mois à venir alors n’hésitez pas à revenir souvent, faire des contributions et/ou des commentaires.

Olivier

 

© 2011 SQA Open Suffusion theme by Sayontan Sinha