pascals.blog : Linux

Migration d’Hyper-V vers 2008 R2, et problèmes de carte réseau sur les VM Linux

pascals — Thu, 08 Oct 2009 14:45:04 GMT

J’ai finalement migré mon serveur Hyper-V, de Windows Server 2008 à Windows Server 2008 R2, pour tomber sur un problème délicat avec des machines virtuelles Linux et la disparition de leur carte réseau.

Je n’ai pas forcément pris le chemin habituel. Certains auraient simplement mis à jour le système après avoir pris soin d’arrêter les machines virtuelles. D’autres auraient exporté les VM, réinstallé le système, puis réimporté les VM. Personnellement aucune de ces deux solutions ne me convenait : je suis réticent aux upgrades de systèmes, préférant repartir à chaque fois sur une installation “propre”. Et le mécanisme d’export/import de VM change la structure de stockage des fichiers sur le disque, ce qui ne me convient pas non plus. A tord !

Bien évidemment, les problèmes que j’ai rencontrés ne me seraient pas arrivés si j’avais suivi l’une ou l’autre des solutions “normales”. J’ai donc procédé comme ceci (ce que je ne recommande donc pas si vous êtes pressé) :

Vérifier qu’aucune VM n’a de snapshot.
Eteindre toutes les VM.
Note : dans ma configuration, le système est sur un disque, les VHD sur un autre, et les sauvegardes sur un troisième.
Sauvegarder les VHD –à noter que ce sont les seuls fichiers que je conserve dans la manipulation, car j’ai l’intention de définir les nouvelles machines virtuelles avec ces mêmes VHD.
Noter la définition des VM et des réseaux virtuels.
Installer Windows Server 2008 R2 comme une nouvelle installation (en supprimant la partition existante sur le disque réservé au système). Installer les mises à jour, les comptes utilisateurs, l’adresse IP, etc.
Activer le rôle Hyper-V et utiliser le script HVremote pour mettre en place l’administration à distance.

A ce stade, j’ai donc un système 2008 R2 propre sur le disque système, Hyper-V opérationnel, et mes fichiers VHD d’origine sur le disque d’origine qui leur était dédié.

Réinitialiser les ACL sur tous les fichiers VHD (icacls *.vhd /reset), ceci principalement par souci de détail. Voir ici pour une explication des ACL qu’Hyper-V ajoute sur les VHD. Nettoyer les ACL des permissions laissées par un ancien Hyper-V n’est pas obligatoire, mais c’est une bonne idée, lorsque l’on réutilise un disque sur un nouveau système, de faire le ménage sur les ACL.
Créer les réseaux virtuels tels qu’ils existaient auparavant.
Créer chaque VM avec la même configuration qu’auparavant : mémoire, carte réseau (normale ou legacy selon les cas), VHD... Au passage, Hyper-V 2008 R2 inclut par défaut un contrôleur SCSI dans chaque nouvelle VM : on peut le supprimer si la VM n’en avait pas auparavant.

Jusqu’ici tout va bien, il ne reste plus qu’à démarrer les VM.

Premier déboire : un Windows XP nécessite une réactivation, à cause du changement de matériel. Puis, après mise à jour des composants d’intégration, la carte réseau est vue comme une nouvelle carte, paramétrée par défaut en DHCP. Si une adresse fixe est nécessaire, il faut la redéfinir, ce qui produit un avertissement classique :

Ce qui aurait dû me mettre la puce à l’oreille pour le problème des machines Linux...

Venons-en donc à une machine virtuelle Linux, plus exactement un Debian 4.0 (etch). L’erreur est immédiatement visible au boot :

et à la commande ifconfig :

Plus de carte réseau... alors que la commande dmesg montre que le driver Tulip (la carte Legacy network adapter n’a pas changé entre les versions d’Hyper-V) est bien chargé et reconnait bien la carte et sa nouvelle adresse MAC :

Après quelques recherches et essais divers, il s’avère que la nouvelle carte est bien présente, mais le noyau l’a nommé eth1 au lieu de eth0 :

Pour remettre les choses en place, trois solutions sont possibles :

Première possibilité, dans le fichier /etc/network/interfaces, remplacer eth0 par eth1. C’est le plus simple, le plus rapide.

Deuxième possibilité, si l’on souhaite appeler eth0 la nouvelle carte, il faut savoir que Linux maintient une correspondance entre les adresses MAC et les noms d’interfaces. Ce fichier se trouve dans /etc/udev/rules.d. Sur un de mes systèmes il s’appelle 70-persistent-net.rules, sur un autre : z25-persistent-net.rules. La règle semble être que le fichier s’appelle <préfixe>-persistent-net.rules :

On voit bien dans ce fichier l’historique des adresses MAC rencontrées par le système, et comment la nouvelle a été numérotée eth1.

Il suffit alors d’éditer ce fichier pour attribuer le nom eth0 à la nouvelle adresse MAC :

Troisième possibilité : dans Hyper-V, configurer la machine virtuelle pour donner à la carte réseau la même adresse MAC que l’ancienne machine virtuelle... Ce qui explique pourquoi il aurait été judicieux de faire un export et un import de la VM, et conserver l’adresse MAC d’origine.

J’espère que cela évitera des déboires à certains, et dépannera ceux qui perdent leur carte réseau.

Et je remercie mon collègue Youssef, et Bing pour avoir trouvé le fichier 70-persistent-net.rules à la vitesse de l’éclair !

Rentrée virtuelle

pascals — Sun, 30 Aug 2009 18:45:36 GMT

La rentrée est riche sur le front de la virtualisation !

Du coté client :

Windows 7 RTM est disponible pour les abonnés Technet et MSDN.
Windows Virtual PC RC. Ce n’est pas encore la version finale, mais cela s’en rapproche. En téléchargement gratuit pour Windows 7 Home Basic, Home Premium, Professional, Enterprise et Ultimate. Voir également le site et le blog. Pour situer le produit : Windows Virtual PC est le successeur de Virtual PC. Il ne fonctionne que sous Windows 7 et bénéficie de nouveautés que j’aborderai plus tard.
Windows XP Mode RC. Pour Windows 7 Professional, Enterprise en Ultimate, une machine virtuelle Windows XP prête à l’emploi, pour en finir avec les problèmes de compatibilité en entreprise.

Du coté serveur :

Windows Server 2008 R2 RTM est disponible pour les abonnés Technet et MSDN. Des VHD d’évaluation sont en téléchargement en version Enterprise et Enterprise Core.
Hyper-V Server 2008 R2. L’hyperviseur est disponible en téléchargement gratuit.
Linux Integration Components for Windows Server 2008 Hyper-V R2. Ces composants sont disponibles en version 2.0 finale pour SUSE Linux Enterprise Server 10 SP2 et 11, x86 et x64. Ils supportent Windows Server 2008 (et 2008 R2) Hyper-V, ainsi que Hyper-V Server 2008 (et 2008 R2).
Remote Server Administration Tools (RSAT) for Windows 7. Ces outils d’administration à distance sont nécessaires pour administrer un serveur Hyper-V depuis un poste Windows 7.
HVRemote. Ce script est indispensable pour l’administration distante d’Hyper-V dans un environnement workgroup ou mixte.
System Center Virtual Machine Manager (SCVMM) 2008 R2. Le produit d’administration est RTM est disponible en version d’évaluation.

Pour tout savoir :

Toutes les questions techniques sont abordées dans ces deux blogs :

Mise à jour 31/8/2009 : RSAT, HVRemote et le Microsoft Virtualization Team Blog.

Plus de détails sur les sources des ICs Hyper-V pour Linux

pascals — Sun, 26 Jul 2009 03:09:54 GMT

Suite à l’annonce de lundi 20 sur la contribution au noyau Linux des sources des composants d’intégration Hyper-V, quelques détails ont été publiés par Hank Janssen sur le blog Port25 :

More on the Hyper-V Linux Integration Components – quelques éléments sur l’histoire du projet.
Introduction to the Linux Integration Components – quelques détails techniques sur l’architecture des composants publiés.

Pour référence, voir également l’annonce de Greg Kroah-Hartman à la communauté Linux, ainsi que les patches dans son arborescence de test.

Composants d’Intégration Linux RC2 pour Hyper-V R2

pascals — Wed, 22 Jul 2009 16:56:39 GMT

La RC2 des Composants d’Intégration Linux (Linux IC’s v2 RC2) pour Hyper-V vient d’être mise à disposition sur le site Connect. Il s’agit ici de la version binaire de ces composants, pour les distributions supportées par Microsoft :

Red Hat Enterprise Linux 5.2 (x86/x64)
Red Hat Enterprise Linux 5.3 (x86/x64)
SUSE Linux Enterprise Server 10 SP2 (x86/x64)
SUSE Linux Enterprise Server 11 (x86/x64)

Ces composants en version RC2 fonctionnent pour :

Windows Server 2008 Hyper-V
Hyper-V Server 2008
Windows Server 2008 R2 Hyper-V RC
Hyper-V Server 2008 R2 RC

Cette sortie n’est pas liée à l’annonce précédente sur la mise à disposition des sources de ces composants : en attendant leur intégration dans le noyau de Linux, ces composants binaires seront maintenus pour les distributions indiquées.

Notez que le support de la souris n’est pas inclus dans ces composants. Pour cet aspect, reportez-vous au Projet Satori de Citrix.

Drivers Linux pour Hyper-V sous GPL

pascals — Mon, 20 Jul 2009 20:06:32 GMT

Grande nouvelle ! Microsoft vient d’annoncer à l’occasion de l’OSCON (Open Source Convention) 2009 la mise à disposition du code source des drivers pour Linux dans l’environnement de virtualisation Hyper-V, représentant environ 20 000 lignes de code. Ces composants sont fournis sous licence GPLv2 pour compatibilité avec la licence du noyau de Linux. Outre le fait que c’est la première fois que Microsoft fournit du code sous cette licence, l’intérêt technique est que cela va permettre le fonctionnement de toute distribution Linux de façon optimisée dans Hyper-V.

Ces drivers représentent l’équivalent des composants d’intégration qui permettent aux machines virtuelles Windows d’utiliser les composants synthétiques fournis par Hyper-V : SCSI, IDE et Ethernet. Les machines virtuelles Linux pourront donc bénéficier des mêmes performances, quelle que soit leur distribution. J’attends avec impatience la mise en œuvre sur Debian et ses dérivés...

Ils sont fournis à la communauté Linux dans le cadre du Linux Driver Project, sous licence GPLv2.

Voir l’annonce.

Mise à jour 21/7/2009 : Voir également ce post pour les infos sur l’intégration de ce code dans le noyau Linux.

Devoir de vacances : un routeur léger pour Hyper-V

pascals — Mon, 20 Apr 2009 19:35:20 GMT

Les congés sont faits pour changer d’air. Et, si le temps le permet, creuser quelques petits sujets mis de côté. C’est le cas de celui-ci, qui peut intéresser tous ceux qui utilisent la virtualisation pour monter des maquettes un peu conséquentes. Prenons par exemple ce que je viens de mettre en œuvre : un réseau géré par SBS (Small Business Server) 2008. Pour plus d’infos sur SBS 2008, jetez un œil chez mon collègue Pierre ou sur Technet. Pour une telle maquette, il faut un réseau privé isolé, derrière un routeur NAT avec des fonctions de redirection de port (port forwarding) : dans mon cas, il est nécessaire de rediriger un certain nombre de ports vers le serveur SBS.

Hyper-V ne fournit pas de fonction de routeur, ni de NAT, ni de redirection de port. Il est donc nécessaire d’ajouter à notre maquette une machine virtuelle dédiée à la fonction de routage, configurée avec une carte réseau externe (sur le réseau physique) et une carte réseau interne (sur le réseau privé dédié à la maquette). Une machine Windows avec le service RRAS, ou le produit ISA Server, ferait l’affaire. Mais à quel prix sur les ressources du serveur Hyper-V ?

Voici un schéma de principe (notez mes talents de graphiste), dans lequel Routeur 2 est mon objectif :

      Internet
          |
      ____|____
     |         |
     |Routeur 1|
     |_________|
          |
      ____|___________réseau_physique__
               |
     _ _ _ _ _ | _ _ _ _ _ _ _ _Hyper-V_
    |      ____|____                    |
          |Routeur 2|
    |     | virtuel |                   |
          |_________|
    |          |                        |
      _________|_________réseau_privé__
    |      |           |                |
       ____|____   ____|____
    | |         | |  Autre  |           |
      | Serveur | | machine |
    | | virtuel | |virtuelle|           |
      | interne | | interne |
    | |_________| |_________|           |

    |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|

Il existe plusieurs solutions à base d’autres OS (c'est-à-dire Linux) et j’ai choisi pour cet usage bien précis le « firewall sur une disquette » : floppyfw. Ses caractéristiques intéressantes sont :

Il tient sur une disquette (donc une disquette virtuelle) en lecture seule et fonctionne en RAM : pas d’état à maintenir, il est possible de l’arrêter brutalement sans l’endommager.
Il fonctionne avec 12 Mo de RAM ! Qui dit mieux ? D’autant qu’avec un serveur SBS demandant au moins 4 Go, on économise la RAM comme on peut (Vista fonctionne très bien avec 384, voire 256 Mo.)
Configuration simple depuis une machine Windows : la disquette est formatée en FAT et les fichiers de configuration sont éditables depuis Windows.
Il assure le routage, le NAT, un serveur DHCP optionnel et la redirection de ports vers un serveur interne.

Voici comment procéder :

Commencez par télécharger la dernière version de l’image de floppyfw (fichier .img) et parcourir la documentation disponible. Renommer ou copier le fichier floppyfw-version.img en quelquechose.vfd (vfd est l’extension des images de disquettes pour Hyper-V, mais le format est le même.)

Chargez la disquette virtuelle dans une machine virtuelle Windows. Il y a deux fichiers à éditer : config et firewall.ini. Le second doit être édité uniquement s’il doit y avoir redirection de port vers une machine interne. Les fichiers sont au format Unix : le bloc-note (notepad.exe) de Windows ne sera pas adapté car il ne reconnaît pas les fins de lignes de type Unix (CR). Utilisez plutôt Wordpad, ou un éditeur de texte comme Notepad++.

En supposant que vous n’ayez pas besoin du serveur DHCP puisque vous utilisez le votre dans le réseau interne, et si la carte externe du routeur est cliente DHCP, alors il y a une seule modification à faire dans le fichier config. Dans la section INSIDE settings, modifiez l’adresse IP de la carte interne : INSIDE_IP=<adresse interne>. Le fichier est assez clair si votre configuration est différente.

S’il y a besoin de rediriger des ports vers un serveur interne, alors il faut éditer le fichier firewall.ini : en premier lieu l’adresse IP du serveur interne est à placer dans la ligne SERVER_IP=<adresse IP>.

Toujours dans firewall.ini, chercher la section Forwarding outside ports to an internal server. Cette section contient des exemples en commentaire. Il suffit de s’inspirer de ces exemples pour construire vos propres règles de redirection avec iptables. Par exemple dans mon cas pour SBS j’avais besoin de rediriger les ports 25, 80, 443 et 987 vers le serveur interne 192.168.20.2.

Vers le début du fichier :

SERVER_IP=192.168.20.2

Et un peu plus loin, ce n’est qu’un peu de copier-coller, pour chaque port à rediriger :

# SMTP (Internal mail server): 
  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 25 -j DNAT --to ${SERVER_IP}:25 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 25 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 25 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Web: 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 80 -j DNAT --to ${SERVER_IP}:80 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 80 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 80 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Port 443: HTTPS Web traffic 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 443 -j DNAT --to ${SERVER_IP}:443 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 443 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 443 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP} 

  


  
# Port 987: HTTPS Web traffic for Windows SharePoint Services through Remote Web Workplace 

  
iptables -A PREROUTING -t nat -p tcp -d ${OUTSIDE_IP} --dport 987 -j DNAT --to ${SERVER_IP}:987 

  
iptables -A FORWARD -p tcp -d ${SERVER_IP} --dport 987 -o ${INSIDE_DEVICE} -j ACCEPT 

  
iptables -A POSTROUTING -t nat -p tcp -d ${SERVER_IP} --dport 987 -s ${INSIDE_NETWORK}/${INSIDE_NETMASK} -j SNAT --to ${OUTSIDE_IP}

Pour finir, il s’agit de construire le routeur. La VM doit avoir deux cartes réseaux de type Legacy Network Adapter, la première sur le réseau externe (physique) et la seconde sur le réseau interne (privée). Pour le reste : 12 Mo de RAM, aucun disque dur, et la disquette virtuelle chargée, sans oublier la configuration du BIOS pour que la VM démarre sur la disquette :

Pour vérifier que le routeur est correctement configuré, démarrez et connectez-vous à la VM. Ouvrez une session avec root, sans mot de passe (ce n’est pas un article sécurité !)

La commande ifconfig eth0 vous donnera l’IP externe, et ifconfig eth1 l’IP interne :

Fermez la session (Ctrl+D).

Une fois la VM du routeur prête, vous pouvez la démarrer et l’arrêter (turn off) à volonté, sans risquer de compromettre sa disquette virtuelle. Et à 12 Mo de RAM le routeur, pourquoi se priver ?

Bon test !

Rapport sur les vulnérabilités des OS clients pour le premier semestre 2008

pascals — Mon, 27 Oct 2008 13:24:14 GMT

Jeff Jones vient de publier le rapport sur les vulnérabilité des OS clients pour le premier semestre 2008 :

Download: H1 2008 Desktop OS Vendor Report - Vulnerabilities and Days-of-Risk

Sans surprise, Windows Vista est encore le mieux placé en nombre de vulnérabilités, nombre de jours de risque et atténuation des vulnérabilités. À lire.

Linux sur Hyper-V

pascals — Thu, 17 Jul 2008 02:00:02 GMT

C'est, semble-t-il, un sujet qui vous intéresse. J'ai déjà commis quelques articles ici sur les éternels problèmes de l'installation de Linux sur Virtual PC 2007. Manifestement, Cela se passe beaucoup mieux sur Hyper-V, et pas uniquement avec les versions supportées, à savoir SUSE Linux Enterprise Server 10.

Sean Earp explique dans un article récent comment se passe l'installation dans Hyper-V de OpenSuse 11, Ubuntu 8.04 x64 et Fedora 9 x64. Bonne nouvelle, ces systèmes fonctionnent, et plutôt bien !

Lire l'article : Linux on Hyper-V.

Heure correcte dans une VM Linux dans Hyper-V : la fin

pascals — Wed, 11 Jun 2008 20:06:04 GMT

Suite et fin de ce sujet : soit un Linux non supporté par Hyper-V, donc sans Integration Components pour le maintenir à l'heure. Comment faire en sorte que son horloge ne dérive pas trop dans le temps ? J'ai deux VM dans ce cas à la maison : une Debian 4.0r3 sans interface graphique très peu chargée (en fait ce n'est qu'une passerelle SSH) et une Ubuntu LTS Server 8.04 un peu plus sollicitée, puisqu'elle héberge toute la pile LAMP (Apache, MySQL, PHP). Le premier constat est que la seconde dérive beaucoup plus rapidement que la première. Mais l'application qu'elle héberge nécessite une horloge relativement fiable.

Comme souvent, la solution est extrêmement simple. Il s'agit simplement de remettre la machine à l'heure régulièrement. Dans mon cas, une fois par jour suffit amplement. Comme vu dans les articles précédents, le démon ntpd n'est pas adapté à l'environnement virtuel, et l'option clock=pit est nécessaire sur les noyaux récents. D'autre part vsntp est une possibilité mais il y a plus simple "dans la boîte", comme indiqué ci-dessous. Ces instructions doivent être réalisées dans le contexte de root : dans Ubuntu, utilisez la commande sudo -s pour obtenir un shell dans le contexte de root.

Rappel : mon expérience se limite à Debian et Ubuntu.

Etape 1 : option clock=pit

il faut ajouter l'option clock=pit dans le fichier /boot/grub/menu.lst, à la fin de la ligne kernel par défaut. Il s'agit de la première ligne kernel suivant la ligne ## ## End Default Options ##. Exemple :

## ## End Default Options ## title Ubuntu 8.04, kernel 2.6.24-18-server root (hd0,0) kernel /boot/vmlinuz-2.6.24-18-server root=UUID=d2cd13e1-bc9e-4657-86eb-26f150b41aaf ro quiet splash clock=pit initrd /boot/initrd.img-2.6.24-18-server quiet

Remarque : si, lors de l'installation de mises à jour, le noyau est mis à jour, alors il faut réappliquer cette modification au fichier menu.lst.

Etape 2 : programmer une mise à l'heure quotidienne avec ntpdate

Vérifier ou installer ntpdate :

# apt-get install ntpdate

Vérifier que ntpdate fonctionne comme prévu et remet votre système à l'heure :

# ntpdate fr.pool.ntp.org

Créer un fichier /etc/cron.daily/ntpdate contenant les lignes suivantes :

#!/bin/sh /usr/sbin/ntpdate fr.pool.ntp.org

Ajouter à ce fichier l'attribut exécutable :

# chmod a+x /etc/cron.daily/ntpdate

Dans mon exemple, j'utilise fr.pool.ntp.org comme nom de serveur NTP, qui donne en réalité un serveur parmi un pool de serveurs français (voir http://www.pool.ntp.org/ pour plus d'infos). Vous pouvez bien sûr le remplacer par celui qui vous ira le mieux.

Terminé ! Reste à vérifier de temps à autre que l'heure est correcte (attention, la commande est date, pas time comme sous Windows.) Et de toutes manières, vous mettez à jour vos systèmes (apt-get update et apt-get dist-upgrade sont vos amis), donc vous redémarrez régulièrement vos Linux à cause des mises à jour du noyau, parce que vous vous souciez plus de votre sécurité que de votre uptime. Non ?

Vulnérabilités des OS clients : Vista, XP SP2, Linux, Mac OS... et Windows 2000 dans tout ça ?

pascals — Fri, 16 May 2008 16:45:07 GMT

Jeff Jones vient de publier deux papiers comparant pour le premier les vulnérabilités de Windows Vista et de Windows XP SP2 en 2007, et, pour le second, les vulnérabilités du premier trimestre 2008 pour Vista, XP SP2, RHEL Desktop v5 client, RHEL WS v4, Ubuntu 6.06 LTS Desktop, Mac OS 10.4 et 10.5.

Le premier papier évoque de façon très intéressante le rôle d'UAC dans la réduction de la menace liée aux vulnérabilité.

A propos (cela date de la semaine dernière), il paraît que Windows 2000 serait plus sûr que Windows Vista... Ce genre d'auto-promotion sensationnaliste (qui avait entendu parler de PC Tools auparavant ?) ferait juste sourire si elle n'était pas reprise à tour de bras par tous les sites d'informations technologiques de la planète. Une réponse n'était pas vraiment nécessaire, mais voici tout de même :

Windows Vista and Malware

Ubuntu 8.04 dans Virtual PC

pascals — Sun, 04 May 2008 13:51:08 GMT

En décembre dernier je décrivais une méthode pour faire fonctionner Ubuntu 7.10 Desktop dans Virtual PC 2007. La nouvelle version 8.04 LTS vient de sortir, est-ce que cela va être mieux ou pire ? D'après ce que l'on peut lire les expériences sont très variées, aussi voici comment j'ai procédé sur un test.

Déjà coté serveur, pas de problème. Ubuntu 8.04 LTS Server Edition fonctionne correctement dans Hyper-V (sans oublier UTC=no dans /etc/default/rcS et clock=pit dans les options du noyau dans /boot/grub/menu.lst.)

Venons-en à Ubuntu 8.04 LTS Desktop Edition (qui se moque des noms des produits Microsoft ? :)) dans Virtual PC.

Mes premiers tests n'ont pas été concluants, puisque chacune de mes tentatives se soldait par l'erreur suivante :

Puis je suis tombé sur cet article et ses commentaires très utiles, et voici la méthode qui fonctionne sur ma machine (Intel Core 2 Duo E6400). Notez que, comme toujours avec Linux dans Virtual PC 2007, il faut veiller à ce que la virtualisation matérielle soit activée :

Tout d'abord, téléchargez le alternate desktop CD (case à cocher en base de la page de téléchargement) : ubuntu-8.04-alternate-i386.iso.

Démarrez la machine virtuelle, chargez l'iso, redémarrez si nécessaire.

La première chose à faire est de choisir la langue, puis <F3> et choisir le clavier :

Point très important puisque c'est cela qui a supprimé le message d'erreur sur ma configuration : tapez <F6> et ajoutez l'option vga=771 (ou 791 si vous préférez plus grand) :

Avec l'option Install Ubuntu sélectionnée, tapez <Entrée>.

Si la machine virtuelle plante encore avec le même message d'ereur, recommencez depuis le début, mais en ajoutant cette fois les trois options : noapic nolapic vga=771.

Choisir ensuite :

la langue
la localisation géographique

Puis, après quelques instants de détection matérielle :

le nom de la machine
le partitionnement du disque

L'installation du système se déroule alors sans intervention, jusqu'à ce que l'on vous demande :

un nom et un mot de passe pour un premier utilisateur
le proxy, si nécessaire

C'est le moment d'aller voir dehors s'il fait beau... A votre retour on vous demandera :

Est-ce que l'horloge système est à l'heure UTC ? Répondez Non.
Redémarrage

On n'a pas fini... Au redémarrage, tapez <Echap> pendant que Grub est visible :

Tapez directement e pour éditer la première entrée :

Sélectionnez l'entrée kernel /boot/vmlinuz... et tapez une nouvelle fois e.

Tapez <espace> puis : noapic nolapic vga=771<entrée>

Tapez b. Le système démarre en principe correctement...

On reconnaît bien là un Linux dans Virtual PC non ? :-)

Reste alors à suivre à peu près la méthode précédente :

Tapez Ctrl+Alt+F1 pour ouvrir une session en mode texte.
Editez (sudo nano ou sudo vim selon les goûts) le fichier /boot/grub/menu.lst, trouver la ligne kernel vers la fin du fichier et ajoutez les options : noapic nolapic vga=771.
Dans le fichier /etc/X11/xorg.conf, ajoutez une ligne DefaultDepth 16 dans la section "Screen".
Tapez Ctrl+Alt+F7 pour retourner sur l'écran graphique, puis Ctrl+Alt+<Backspace> pour redémarrer X.

Tadaaaaa !

Il reste à activer le réseau en cliquant sur l'icône adéquate et en choissant Wired Network.

Mise à jour 5/5/2008 - Correction mineure et mise à jour des dernières copies d'écran. Je confirme également que la méthode fonctionne sur une deuxième machine (Lenovo X61).

Mise à jour 16/7/2008 - J'ai reçu par mail la suggestion d'utiliser l'option noreplace-paravirt au démarrage depuis le CD. Consultez l'article suivant qui part de cette solution également. Merci !

Bitlocker et Linux sur la même machine

pascals — Wed, 30 Apr 2008 21:09:29 GMT

Mon collègue Cyril Voisin vient de publier un webcast sur la configuration d'un dual boot Linux et Vista avec Bitlocker et un TPM. Ce webcast complète par une démonstration détaillée et un livre blanc ses précédents articles sur le sujet.

Le webcast, la présentation et le livre blanc :

Installer une machine en double démarrage (dual boot) avec Linux et Windows Vista protégé par BitLocker et un TPM

Les articles :

Merci Cyril !

Mise à jour 14/05/2008 - Cyril a posté sur son blog un article plus détaillé avec des copies d'écrans et le minutage des séquences de la vidéo.

Heure correcte dans une VM Linux dans Hyper-V

pascals — Mon, 28 Apr 2008 21:19:38 GMT

Récemment j'écrivais ici que le démon ntpd suffisait pour maintenir l'horloge d'une VM Linux sous Hyper-V. En fait, j'avais tord. Et pas qu'un peu. A l'usage, mes deux VM (Debian 4.0r3 et Ubuntu LTS Server 8.04) ne s'avèrent pas à l'heure du tout. Comment résoudre ce problème simplement ? Comme je l'indiquais aussi précédemment, il y a vsntp : aujourd'hui le meilleur candidat.

A noter également : le problème est pire avec les noyaux récents 2.6. Une raison et un contournement (option clock=pit) sont indiqués dans cet article :

The system time runs too fast on a Linux-based virtual machine that is hosted in Virtual Server 2005 R2.

Manifestement le sujet n'est pas encore clos, et mérite encore quelques tests.

Heure correcte dans une VM Linux, le cas d'Hyper-V

pascals — Mon, 21 Apr 2008 17:47:13 GMT

Suite de mes expérimentations sur l'heure dans une machine virtuelle Linux. Je viens donc de migrer de Virtual Server (sur un Pentium 4, sans virtualisation matérielle), vers Hyper-V (sur un Intel Core 2 Quad Q6600) et évidemment il me fallait des machines virtuelles Linux à l'heure !

Comme indiqué précédemment, j'utilisais vsntp dans mes VM Linux sous Virtual Server et Virtual PC. Lors de la migration, j'ai reconstruit une VM Debian 4.0r3 version i386 (2.6.18-6-686). Comme prévu, l'heure de la VM a immédiatement tendance à être en avance. J'ai toutefois testé une solution plus classique, à savoir installer le package ntp :

# apt-get install ntp

Dans sa configuration par défaut, le package ntp installe le démon ntpd avec un fichier de configuration /etc/ntp.conf qui provoque la synchronisation par rapport à des serveurs de temps de pool.ntp.org :

# pool.ntp.org maps to more than 300 low-stratum NTP servers.
# Your server will pick a different set every time it starts up.
#  *** Please consider joining the pool! ***
#  *** <http://www.pool.ntp.org/join.html> ***
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

Après quelques jours de fonctionnement, le résultat est très satisfaisant pour mon usage, à savoir que les fichiers de log du système soient à peu près cohérents. Je ne m'avancerais pas ici sur des besoins plus exigents...

Cela dit, si vous utilisez SUSE Linux Enterprise Server 10 SP1 (x86 ou x64), vous pouvez tenter les Linux Integration Components for Hyper-V.

Heure correcte dans une VM Linux, la suite

pascals — Sat, 12 Apr 2008 18:42:00 GMT

Puisque j'ai attaqué le sujet de l'heure dans les VM Linux, voici un un autre souci classique : sans "aditions" Virtual PC / Virtual Server pour Linux, l'horloge des VM n'est pas fiable et diverge très rapidement : cela peut se compter en heures par jour. Le problème est que l'horloge des VM n'a pas une "vitesse" constante au cours du temps, et que donc les outils classiques de synchronisation ne fonctionnent pas.

J'utilise un outil gratuit spécialement conçu pour cet usage : vsntp. Il utilise le protocole NTP (123/udp). Etant donné que la synchronisation devra se faire assez fréquemment (toutes les quelques minutes en fonction de l'environnement), vous devrez utiliser un serveur NTP que vous contrôlez. Un contrôleur de domaine par exemple, ou tout Windows Server sur le quel le service w32time aura été configuré en serveur NTP.

J'utilise vsntp v1.1.1 sur deux VM Debian et Ubuntu Server qui tournent en permanence, sans aucun problème et avec un résultat très satisfaisant. La synchro se fait chaque minute avec la machine hôte - pour l'instant un Windows Server 2003 SP2 avec Virtual Server 2005 R2 SP1.

Je l'ai également utilisé plusieurs fois lors de démos en public sur l'intégration de Linux dans Active Directory : l'authentification Kerberos nécessite une synchronisation d'horloge telle que, sans vsntp, la démo était impossible.

Etant donné que ma migration vers Hyper-V est en cours (plus d'infos à venir), nous verrons si le problème subsiste ou non.

Références :