En consolidant la charge de travail de 100 ou 200 serveurs sur une même machine, on augmente la criticité de celle-ci. Une panne de cette machine peut entraîner une véritable catastrophe.
Il y a ensuite les risques humains. Un administrateur peut d'un simple clic effectuer des manipulations qui correspondent dans la réalité à couper le circuit électrique dans un gros data center alors que dans le monde physique c'est difficilement possible car il faut accéder à la salle, aux baies et au disjoncteur qui sont protégés par des caméras et des systèmes de sécurité sophistiqués.
Il faut garder en mémoire qu'une erreur humaine peut provoquer la suppression d'un serveur virtuel et de ses données, ce qui dans la réalité correspond à la suppression physique d'un serveur.
Il y a également les risques liés à la malveillance. Un accès illicite peut avoir un impact très très important. Entrer sur un serveur physique c'est grave. Quand on peut accéder à l'équivalent de 100 ou 200 de ces serveurs c'est catastrophique.
VMware Guest Console (VGC) est une nouvelle console de gestion et d’administration capable de surveiller et de manipuler les fichiers et processus de n’importe quelle machine virtuelle. Bien utile quand on a plusieurs VMs sur différents ESX, ESXi, Workstation etc..
VGC se connecte à tous les systèmes d’exploitation, cela n’a pas d’importance si la machine virtuelle est hébergée sur ESX Server ou Workstation. Une fois connecté, VGC fournit un gestionnaire de tâches, un explorateur de fichiers, un gestionnaire de capture instantanée et un gestionnaire de machine virtuelle fonctionnant sous Windows et Linux.
Avec cet outil, un administrateur peut effectuer des tâches simples comme mettre fin à un processus en cours ou lancer un nouveau programme, ainsi que des choses plus complexes comme la copie du même fichier sur plusieurs VMs en même temps quelque soit l’OS Windows ou Linux… De la même façon, il peut manipuler les « Snapshots » de plusieurs machines virtuelles en même temps ou stocker des informations provenant de multiples systèmes d’exploitation de l’utilisateur à des fins d’inventaire.
[root@ks359552 ~]# cat xen_make_vm.sh
#!/bin/bash
#
# para-virtualized guest
#
# http://www.linuxtopia.org/online_books/centos5/centos_5_xen_virtualization/centos5_chap-Virtualization-Guest_operating_system_installation_processes.html
#
#
virt-install \
--name vmweb \
--paravirt \
--mac=02:00:00:08:f2:65 \
--ram=1024 \
--file=/home/xen.vms/vmweb.img \
--file-size=5 \
--location=ftp://mir1.ovh.net/ftp.centos.org/5.5/os/x86_64
# --location=/home/xen.vms/CentOS-5.5-x86_64-netinstall.iso
On the network setup screen of centos, I switched to manual configuration and set the IP and Gateway to the failover ip address (yep, the exact same ip in both fields), the netmask to 255.255.255.255 and the dns server to ovh's dns. At this point i could fetch the install files and proceed with my installation, it all worked fine using the xen defaults centos ships with. The issue turned out to be an acl problem on the switch. Good luck :)
IP v4 address: 87.98.167.123 / 255.255.255.255 Gateway: 87.98.167.123 Gateway: 91.121.158.254 Name Server: 213.186.33.99
xentop xm list xm create /etc/xen/vmweb xm list xm shutdown vmweb xm list
http://www.howtoforge.com/kvm-and-openvz-virtualization-and-cloud-computing-with-proxmox-ve
commands:
vzctl start 101 vzctl stop 101
HowTo
iptables=iptables private_network=192.168.200.0/24 # output_interface=eth0 #out_interface=vmbr0 out_ip=46.105.121.108 # $iptables -A FORWARD -o $output_interface -j ACCEPT # $iptables -t nat -A POSTROUTING -s $private_network -o $out_interface -j SNAT --to $out_ip $iptables -t nat -A POSTROUTING -s $private_network -j SNAT --to $out_ip
Créer le fichier
/etc/network/if-pre-up.d/iptables
et
chmod +x /etc/network/if-pre-up.d/iptables
puis ajouter
#!/bin/bash /sbin/iptables-restore < /etc/iptables.rules
ensuite mettre les règles issues de iptables-save dans le fichier
/etc/iptables.rules
Montée une image de VM au format RAW.
Sources pour l'exercice :
J'ai généré l'image raw à partir d'une image VDI (VirtualBox):
VBoxManage clonehd --format RAW zimage.vdi zimage.img
Ensuite:
mkdir zimage.fs loopdev=$(losetup -s -f openstreetmap.img) kpartx -a $loopdev # ceci créé une entrée "/dev/mapper/loop0p1", à vérifier s'il y a d'autres montage sur loop. # on peut aussi faire (j'ai pas essayé): mount /dev/mapper/$(basename $loopdev)p1 zimage.fs mount /dev/mapper/loop0p1 zimage.fs ls zimage.fs ...
Pour la machine Virtuelle d'OSM:
Récupération du template Ubuntu 10.04 en 32 bits avec l'aide de Google.
Création de la VM dans Proxmox.
Copie des fichiers:
rsync -arvpz --numeric-ids --exclude=/etc --exclude=/boot --exclude=/cdrom --exclude=/initrd.img --exclude=/vmlinuz --exclude=lost\+found --exclude=/media --exclude=/mnt --exclude=/opt --exclude=/root --exclude=/dev --exclude=/proc --exclude=/tmp --exclude=/var --exclude=/srv --exclude=/sys --exclude=/lib/modules --exclude=/lib/firmware osm.fs/ /vz/private/104/
Explication du NAT/SNAT/DNAT:
Il faut simplement activé l'IP Masquerading sur le host:
iptables -t nat -F POSTROUTING iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
Ne pas suivre ce tuto, trop compliqué et ne fonctionne pas en fait: