Configurer le serveur hôte

pas utiliser IIS sur le système hôte,
vous pouvez configurer le site Web Virtual Server sur un serveur alternatif
(le fichier d’aide online explique comment
faire cela). Si vous ne pouvez absolument
pas utiliser IIS, Microsoft recommande
d’utiliser Microsoft Virtual
PC au lieu de Virtual Server pour
contrôler vos VM (Virtual PC est moins
robuste que Virtual Server, mais il n’a
pas besoin d’IIS).
Comme les VM consomment des
ressources de la même manière que
les serveurs physiques, assurez-vous
qu’il y a suffisamment de RAM et de
disque dur sur le serveur hôte pour satisfaire
le nombre de VM que vous envisagez
d’utiliser simultanément sur
l’hôte. Ainsi, si vous songez à  allouer
128 Mo de RAM virtuelle pour chacune
des trois VM serveur NT, il vous faudra
installer 384 Mo de RAM en plus de la
quantité de mémoire que l’OS hôte et
ses applications actives demandent.
Veillez aussi à  allouer suffisamment
d’espace disque pour les disques durs
virtuels de chaque VM. Il n’est pas nécessaire
de créer des partitions séparées
pour les disques durs parce que
les disques durs virtuels sont stockés
dans des fichiers dotés de l’extension
.vhd.
Après avoir mis de côté assez de
ressources pour les VM, il faut les
mettre en réseau. Vous pouvez soit
leur faire partager l’adaptateur réseau
de l’ordinateur hôte et les connecter
directement au réseau de production,
soit les configurer pour utiliser un réseau
virtuel qui ne se connecte qu’au
système hôte. Je préfère cette dernière
méthode principalement parce qu’elle
isole les VM des systèmes physiques
sur le réseau de production. De plus,
en créant une connexion réseau virtuelle,
on élimine les erreurs de conflit
NetBIOS pendant la migration et on
peut tester et configurer entièrement
les VM sans affecter les serveurs NT
physiques de production.
Pour établir un réseau virtuel, il
faut ouvrir l’applet Control Panel
Add/Remove Hardware sur le système
hôte, pour installer le Microsoft
Loopback Adapter. Une fois l’adaptateur
installé, modifiez ses paramètres
TCP/IP pour attribuer la première
adresse IP à  l’adaptateur sur un réseau
unique, du genre 10.1.0.1/24. Quand
vous installez les VM sur le serveur
hôte, vous pouvez configurer leurs interfaces
réseau pour utiliser d’autres
adresses IP sur le même subnet virtuel.
Bien entendu, un réseau virtuel visible
par le seul hôte VM ne sert à  rien
si les utilisateurs ne peuvent pas accéder
au serveur NT virtuel. Pour faciliter
l’accès utilisateur tout en gardant
toutes les VM sur leur propre réseau
privé, je configure Routing and
Remote Access sur le système hôte
pour se comporter comme un routeur
de réseau. Vous pouvez utiliser le snapin
Microsoft Management Console
(MMC) Routing and Remote Access
Service pour mettre en place rapidement
le service en utilisant le wizard de
configuration qui apparaît après votre
première tentative de configuration du
service. Pour que tout administrateur
puisse accéder au réseau virtuel et aux
VM actives, vous pouvez utiliser la
commande Route Add pour ajouter
des routes statiques aux systèmes des
administrateurs. Par exemple, pour accéder
au réseau virtuel 10.1.0.0/24 rattaché
à  un système hôte avec une
adresse IP de 172.16.12.34, vous exécuterez
la commande

route add p 10.1.0.0
mask 255.255.255.0 172.16.12.34

Quand vous serez prêt à  mettre de
façon permanente toutes vos VM en
production, en remplacement des serveurs
NT physiques, il vous suffira de
mettre à  jour les tables de routage de
vos routeurs de production puis de
modifier les enregistrements hôte A de
chaque VM sur le serveur DNS de production.
Si vous ne voulez pas suivre le chemin
du routage, vous pouvez toujours
configurer les interfaces réseau de vos
VM pour se connecter aux interfaces
réseau physiques de l’un des systèmes
hôte. Cette configuration permettra
aux VM de se connecter directement
au réseau de production et exigera
simplement que leurs interfaces réseau
virtuelles aient une adresse IP de
production unique. Si vous adoptez
cette méthode, pensez à  isoler votre
VM du serveur de production qu’elle
remplace, afin de ne pas obtenir les erreurs
NetBIOS qui se produiraient si les systèmes identiques pouvaient se
voir entre eux sur le même segment de
réseau physique.