Le but de cet article est d'expliquer les différentes étapes nécessaires pour avoir un service de virtualisation sur la base d'un système linux.
- Serveur host : linux (machine physique)
- Serveur guest : Windows 2003 (serveur web virtuel)
- Vitualisation : VMWare 2.0
ModifierOVH: monter un serveur dédié Windows Server avec une licence déjà acquise par ailleurs via virtualisation VMWare
Auteur: Softlion (c)2009
Contact
Site:
http://www.softlion.com/
Historique:
17 juin 2009: ne pas activer "virtualization" dans les options kernel pour un host.
6 juin 2009: ne pas activer "guest paravirtualization support" pour un host
26 mai 2009: nouveau chapitre "Sécurisation du serveur"
Buts principaux:
- serveur dédié
- os windows server déjà acquis (ne pas repayer une location de licence à OVH). Typiquement dans le cadre du programme Bizspark.
- facile à déménager (à sauvegarder et à restaurer)
- sécurisé
Buts secondaires:
- le moins de coûts cachés possibles
- le moins de maintenance OS possible
- plusieurs IPs publiques pour plus tard pouvoir faire du load-balancing en round-robin sur plusieurs dédiés ou séparer des blocs fonctionnels
- un filer pour la même raison (espace disque commun à plusieurs serveurs/OS)
J'ai souhaité monter un serveur dédié chez OVH avec une licence Windows Server 2003 déjà acquise. Plutot que d'utiliser kVM qui permet d'installer un OS à distance chez OVH, je suis parti sur l'idée de virtualisation qui simplifie les backups et le déplacement de l'OS sur une machine plus puissante tout en perdant un minimum de vitesse, et d'éventuellement migrer tranquillement sur une autre version de Windows Server plus tard, voir d'essayer d'autres OS en parallèle sur la même machine.
J'ai choisi VMWare Server 2.0 qui est gratuit et s'installe sur un OS hôte (appelé host). Comme la machine a plus de 3Go de RAM il faut un OS 64bits pour en profiter. J'ai choisi un OS gratuit et éprouvé : "Debian Etch 64bits nue". Pourquoi nue ? Pour éviter d'avoir la version 1.0 de VMWare Server préinstallée avec l'option OVH correspondante.
Je vais expliquer ici comment installer VMWare Server 2.0 sur la debian etch 64bits OVH et comment configurer le réseau d'une machine virtuelle "Windows Server 2003" avec plusieurs "IP Failover" (ce sont des IP fixes publiques "virtuelle" dont l'IP réelle de destination et le reverse DNS sont configurables).
Note: l'os de la machine réelle est appelé host, l'os de la machine virtuelle est appelé guest.
Choix d'architecture:
- Host:
- Debian Etch 64bits
- Pour casser la limitation à 2Go de RAM des OS 32 bits.
- Version nue pour pouvoir mettre tranquillement le logiciel VMWare 2.0 non proposé par OVH.
- Dossier partagé "filer", accessible par les guests, via Samba sur le réseau privé
- Guest:
- Windows Server 2003 avec licence
- SQL Server Express 2008 (gratuit mais non accessible à distance)
- WinSSHD, serveur SSH pour windows avec licence (forward des ports SQL)
ModifierSommaire
1) Etat des lieux du serveur OVH à la livraison
2) Recompilation, changement, et mise à jour du noyaux Debian Etch
3) Installation de VMWare Server 2.0 avec les IP Failover
4) Configuration de VMWare et configuration réseau du guest
ModifierEtat des lieux
A la livraison le serveur a:
- 2 disques durs montés en raid 1 logiciel. Le disque résultant est partitionné en deux:
- une partition "OS" de 5Go qui contient tous les dossiers sauf /home
- une partition du reste de la place dispo monté dans /home
- Une Debian Etch 64its pré-installée avec le boot lilo mais sans le support des "modules" linux ni la gestion matérielle de l'horloge (/dev/rtc n'existe pas). Ces 2 éléments sont nécessaires à VMWare Server 2.0
- SSH actif sur le compte root avec SFTP et commandes à distance actifs.
Il nous faut tout d'abord récupérer les infos de notre serveur.
On s'y connecte en SSH et via les commandes à distance (shell):
host# cat /etc/network/interfaces
On note l'IP de la gateway. On en aura besoin pour configurer le guest.
host# cat /etc/resolv.conf
On note les IP des DNS (autre que 127.0.0.1)
ModifierRecompilation du noyau linux
Il faut commencer par ça avant d'installer VMWare sinon après c'est galère VMWare croit qu'il n'est pas installé alors que les fichiers n'ont pas été désinstallé et faut faire le ménage à la mano.
Le noyau par défaut des serveurs OVH n’inclus pas le support des modules et n'est pas optimisé pour la virtualisation. Il faut donc le recompiler.
Note: infos tirées du blog de
Guiguiabloc
- Récupérer les sources du noyau linux
host# cd /usr/src/
host# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/linux-2.6.28.4-ovh.tar.gz
host# tar -zxvf linux-2.6.28.4-ovh.tar.gz
host# ln -s linux-2.6.28.4-ovh linux
- Récuperer le .config standard (attention il y a une version 32 bits et une version 64 bits, prendre celle qui correspond à l'OS ici 64bits)
host# wget ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6-config-xxxx-std-ipv4-64
host# cp 2.6-config-xxxx-std-ipv4-64 linux/.config
host# cd linux
- Recompiler le noyau linux
host# make menuconfig
Cette commande affiche une interface pseudo-graphique moche. Utilisez les flèches, ENTRER et ESC pour naviguer et ESPACE pour activer/désactiver). Ne vous souciez pas des caractères bizarres qui apparaissent. Ne pas choisir "M" mais "*" pour sélectionner un élément. M signifie que l'élément sera installé en tant que module et * qu'il sera directement inclu dans le noyau. Ici la taille du noyau n'a pas d'importance, autant en mettre un max.
Dans l'interface, activer le support des modules :
“Enable loadable module support” -> “Module unloading” et “Automatic kernel module loading”
Activer le kernel userspace connector :
Device Drivers —> Connector - unified userspace <-> kernelspace linker
Activer le RTC (real time clock) :
Processor Type and Features -> High Resolution Timer Support
Processor Type and Features -> Processor Family -> Core 2/Newer Xeon (vérifier bien que ca correspond au processeur de votre serveur dédié !)
Mettez la fréquence du timer à fond (1000Hz au lieu de 250 par défaut) :
Processor Type and Features -> Timer Frequency
Ne PAS activer les fonctions de virtualisation GUEST :
Processor Type and Features -> Paravirtualized Guest Support (décocher)
Activer le support de la virtualisation hardware (support du mode hyperviseur) :
Virtualization -> (
cocher tout décocher tout ! L'hyperviseur est vmware, et pas KVM)
Sauver la config et fermer.
host# make
host# make modules_install
- Déployer le nouveau noyau
Attention de prendre celui dans le dossier i386 ou x86 pour la version 32 bits, ou celui dans x86_64 pour la version 64 bits. Copier-le dans /boot sous un nouveau nom au choix.
host# cp arch/x86_64/boot/bzImage /boot/vmlinux-2.6.28.4-xxxx-std-ipv4-64
host# cp Sytem.map /boot/System.map-2.6.28.4-xxxx-std-ipv4-64
Modifier /etc/lilo.conf et remplacer le nom du fichier noyau par le notre
Puis notifier à lilo d'utiliser ce nouveau noyau et redémarrer.
host# vim lilo.conf
(modifier la ligne image=/boot/vmlinux-2.6.28.4-xxxx-std-ipv4-64)
(Rappel: flèches pour se déplacer, i pour passer en édition, ESC pour valider l'édition, / pour chercher, :w pour sauver, :q pour quitter)
host# lilo -v -v
host# shutdown -r now
- Vérifier si tout s'est bien passé
Après reboot et reconnection du SSH, vérifier la version installée:
host# cat /proc/version
Linux version 2.6.28.4-xxxx-std-ipv4-64 (
[email protected]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2 SMP Wed Jan 28 23:30:12 CET 2009
Vérifier la présence de la rtc:
host# ls /dev/rtc
/dev/rtc
ModifierInstallation de VMWare Server 2.0
Note: guide tiré du blog de guiguiabloc
ici
But : Il s'agit de ne pas laisser la configuration par défaut de VMWare qui au niveau réseau est en bridge, c-a-d que tous les guest font transiter leurs paquets réseau via le host en NAT (dans ce cas les serveurs exterieurs ne verront qu'une IP: celle du host. Ce n'est pas ce qu'on veux ici.).
- Créer une fausse carte réseau dummy0 (VMWare veut absolument une interface réseau sur laquelle brancher son NAT)
Avant tout il faut créer un fausse carte réseau (dummy0) car VMWare Server 2.0 va en demander deux (appelées vmnet0 et vmnet1) dont une obligatoire dont nous ne voulons pas.
Ajouter à la fin du fichier /etc/network/interfaces :
auto dummy0
iface dummy0 inet static
address 10.0.0.1
netmask 255.0.0.0
Note: 10.0.0.1 peut être remplacé par n'importe quelle IP de classe PRIVEE uniquement.
Puis l’activer :
host# ifup dummy0
Et vérifier qu'elle est bien la :
host# ifconfig
- Télécharger VMWare Server 2.0
Ensuite on télécharge VMWare Server 2.0
Comme la bande passante d'upload est très faible chez moi VMWare Server est téléchargé directement du host. Comme chez VMWare il faut se logger pour accéder au téléchargement on est obligé d'utiliser le navigateur en mode texte "lynx".
host# apt-cache search lynx (pour chercher un package qui contient lynx)
host# apt-get install lynx
host# lynx
(naviguer)
sauvegarder les fichiers dans /home (n'oubliez pas que c'est le seul dossier avec suffisamment de place !)
Décompresser le fichier:
host# tar xzvf VMware-server-2.0.0-116503.i386.tar.gz
Cette action crée un nouveau sous-dossier vmware-server-distrib/
- Installer VMWare Server 2.0
Et on l'installe :
host# cd vmware-server-distrib
host# ./vmware-install.pl
Vous répondez aux questions qui s’affichent (en changeant selon vos désirs les réponses prédéfinies qui apparaissent entre crochets et qui sont validées par un simple ENTREE. Par exemple changer le chemin d'install par défaut : perso je m'ai mis dans /home/vmware pour utiliser la seconde partition du disque dur, surtout que les fichiers de machine virtuelles vont se retrouver dans un sous-dossier de celui-ci).
Jusqu'à la tomber sur la configuration du réseau :
Do you want networking for your virtual machines? (yes/no/help) [yes]
Configuring a bridged network for vmnet0.
Please specify a name for this network. [Bridged]
Your computer has multiple ethernet network interfaces available: dummy0, eth0 . Which one do you want to bridge to vmnet0? [eth0] dummy0
The following bridged networks have been defined:
. vmnet0 is bridged to dummy0
Do you wish to configure another bridged network? (yes/no) [no] no
Do you want to be able to use NAT networking in your virtual machines? (yes/no) [yes] no
Do you want to be able to use host-only networking in your virtual machines?
[no] yes
Configuring a host-only network for vmnet1.
Ici le guest n'est prévu que pour communiquer avec le host ou et les autres guest. Nous allons étendre cette possibilité pour que le guest puisse communiquer avec Internet comme s'il était un serveur tout seul en direct sur le net
Please specify a name for this network. [HostOnly]
Do you want this program to probe for an unused private subnet? (yes/no/help)
[yes] no
What will be the IP address of your host on the private
network? 192.168.1.1 [ATTENTION CHOISIR UNE IP DE CLASSE PRIVEE différente de celle du réseau dummy0]
What will be the netmask of your private network? 255.255.255.0
the following host-only networks have been defined:
. vmnet1 is a host-only network on private subnet 192.168.1.0
Do you wish to configure another host-only network? (yes/no) [no]
Après laisser VMWare compiler ce qu'il veux (répondre tout par défaut) sauf le nom de l'utilisateur à utiliser par défaut pour l'interface web VMWare: mettre root ! (sinon bugs). Vous enlèverez root et mettrez un autre utilisateur après via l'interface web VMWare.
- Accès à l'interface web VMWare
https://ip_du_serveur_dedie_ovh:8333
user: root
pass: ****
Si vous avez uploadé un fichier de machine virtuelle (guest) préalablement créé et configuré chez vous avec VMWare Workstation (version démo 30J ou payée) il apparait dans l'interface et vous pouvez l'ajouter et le reconfigurer facilement.
- Modifier les utilisateurs VMWare
Ajouter un utlisateur préalablement créé sur le host via l'onglet Permissions.
Attention il y a un bug qui ne permet pas d'ajouter 2 utilisateurs avant d'avoir fait une manip spéciale. Donc ajouter l'utilisateur choisi en administrateur, retirer l'utilisateur root, et reloggez vous sur l'interface.
Le fix du bug consiste à modifier le fichier /etc/vmware/hostd/authorization.xml et à remplacer la ligne
<NextAceId>11</NextAceId> par <NextAceId>12</NextAceId>
Après ca déconnectez-vous et reconnectez-vous à l'interface web VMWare et ajouter-y les utilisateurs voulus.
ModifierConfiguration de VMWare et du réseau du guest pour IP Failover
Note: ce guide reprends une partie du blog de guiguiabloc
ici
But: Le but est de configurer le guest avec un accès direct sur internet. Dans la pratique, les paquets traversent le host (forward) de façon transparente.
Configuation du host
D'abord créez vos IP failover via le "manager" d'OVH. Ca prends quelques minutes et vous les recevez par courriel.
Les IP pointent par défaut sur votre serveur physique. C'est parfait.
Sur le host, il faut :
- activer le forwarding IP et ARP (guest=>host)
- activer le routage des IP failover (host=>guest)
Rappel: L'ip failover pointe sur l'adresse ip du host
Note: ARP=address resolution protocol
La première action se fait en modifiant le fichier /etc/sysctl.conf
Ajouter ou activer les lignes suivantes:
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.vmnet1.proxy_arp=1
net.ipv4.ip_forward=1
Sauver le fichier de manière permanente :
host# sysctl -p
Vérification:
host# cat /proc/sys/net/ipv4/ip_forward
1
host# cat /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
1
Si une des valeurs reste à 0 l'activer:
host# /bin/echo "1" > /proc/sys/net/ipv4/ip_forward
host# /bin/echo "1" > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
La seconde action se fait en ajoutant des routes (ici 91.211.222.233 est mon P failover. Répéter autant de fois que nécessaire) :
host# route add 91.211.222.233 dev vmnet1
Note: dev=device
Vérification:
host# route -n
Note: la configuration des routes est perdue à chaque reboot du host. Pour rendre le changement permanent suivre les indications du blog de superkimkim
ici qui consiste à modifier le script de démarrage de vmware et invoquer les "route add" automatiquement.
Note2: sur mon dédié à chaque reboot la conf proxy_arp saute. Je n'ai pas trouvé pourquoi.
Configuation d'un guest windows
Une fois Windows démarré il n'a pas accès à internet et de chez vous il ne ping pas.
C'est normal.
Aller dans la config réseau windows / propriétés TCP/IP.
Dans "adresses DNS" saisir les adresses DNS notées dans le 1er paragraphe.
Dans adresse IP mettre une adresse IP privée 192.168.1.100 par exemple. VMWare Server 2 active un DHCP interne sur son réseau privé vmnet1 qui considère toutes les IP < 128 commes fixes.
Dans passerelle mettre l'IP de la gateway notée dans le 1er paragraphe.
Au même endroit cliquer sur avancé et dans la liste "Adresse IP" cliquer sur Ajouter et saisir une adresse IP failover. Mettre 255.255.255.0 comme masque de sous réseau. Recommencer avec les autres IP failover si besoin.
Valider et fermer les fenêtres.
Important: si vous laissez comme ca, Windows affichera le message "conflit d'adresse IP" et désactivera votre IP. En effet il faut forcer le masque à 255.255.255.255 mais l'interface refuse de l'accepter. Du coup on passe outre l'interface et on va direct modifier la base de registre:
démarrer / exécuter / regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{xxxxxxxx}
Trouver quelle clef {xxxxxxxx} correspond à votre carte réseau, par exemple recherchez la clef IPAddress qui contient l'IP failover.
Une fois trouvé modifier la clef SubnetMask et remplacer 255.255.255.0 par 255.255.255.255
Enfin redémarrer le réseau :
- soit en redémarrant Windows
- soit en désactivant puis réactivant la carte réseau via le "panneau de config" / "connections réseau" soit via le "device manager".
Vérifiez que le guest peux naviguer sur internet et qu'un ping de votre machine locale vers l'IP failover fonctionne.
Voila bon courage !
ModifierMise à jour du kernel après installation de VMWare
Après une mise à jour du kernel, VMWare Server 2 ne démarrera pas et vous demandera de relancer sa configuration "vmware-config".
Si vous le faite le script se terminera prématurément avec des "failed". (corrigé dans la version 2.0.1)
ModifierOptimisation du host pour vmware
Améliorer les perfs disques des guests (source: forum OVH)Mettre l'option elevator=cfq (dans grub, si vous avez grub)
Sinon à la main:
echo cfq > /sys/block/sda/queue/scheduler
echo cfq > /sys/block/sdb/queue/scheduler
Vérification (mode cfq):
cat /sys/block/sd*/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]
Avant la commande (mode deadline):
noop anticipatory [deadline] cfq
noop anticipatory [deadline] cfq
Pour la différence entre ces 2 modes ("Completely Fair Queuing" or "Anticipatory" IO schedulers) voir :
http://www.redhat.com/magazine/008jun05/features/schedulers/ModifierAutres infos utiles
Pour redémarrer vmware server 2:
/etc/init.d/vmware-server restart
Pour stopper vmware server 2:
/etc/init.d/vmware-server stop
Pour voir la config matérielle:
dmidecode | more
Pour voir le log de boot:
dmesg
Pour voir les périphériques sur bus PCI:
lspci
ModifierSécurisation du serveur
Restriction d'accès au port 111 (serveur sunrpc)
host# dpkg-reconfigure portmap
répondre oui pour restreindre le service sunrpc (port 111) à localhost.
Bannir temporairement les bots qui tentent de forcer l'accès a SSH (port 22)
host# apt-get install fail2ban
la commande installe le script fail2ban qui insère/supprime des règles de bannissement de clients (dans netfilter via iptables) dynamiquement en fonction de leur comportement, analysé via le log du service ssh (sshd).
Ensuite il faut fermer tous les ports et n'ouvrir que ceux qui sont nécessaires.
Créer un nouveau script:
host# vim /etc/init.d/firewall
#!/bin/sh
... (cf iptables)
host# chmod +x /etc/init.d/firewall
Tester le script
host# /etc/init.d/firewall
host# iptables -L -n -v --line-numbers
vérifier que les 2 nouvelles règles ont été ajoutées à la chaine INPUT de la table FILTER.
Rendre les changements permanents:
host# update-rc.d firewall defaults
Cf billet "
Sécurisation du serveur". Pour comprendre le principe des iptables cf le livre de O'Reilly "administration réseau sous linux" chapitre "Pare-feu tcp/ip" partie "Les concepts d'iptables".
ModifierContact
Auteur: Softlion (c)2009
contact
Site:
http://www.softlion.com/
Mise à jour: mars 2009