Archives pour la catégorie ‘Virtualisation’

VirtualBox : augmenter la taille d’un disque

En premier lieu, coupez la VM et désassocier le disque à la VM depuis le VirtualBox Media Manager. Ensuite en CLI :

$ VBoxManage modifyhd vm-debian-disk1.vdi --resize 40000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

A noter que le système ne détectera pas la nouvelle taille du disque si des snapshots existent ; il faut donc tous les supprimer.

Xen : gestion des ressources CPU

Comme tout logiciel de virtualisation, il est possible sous Xen de spécifier le nombre de CPU (core) d’une VM. Pour ce faire on distingue, deux paramètres :

  • cpus : le nombre de cores disponibles
  • vcpus : la liste des cores affectés

En gérant ces deux paramètres, il est donc possible de dédier des cores CPU à chaque environnement virtuel.

Limiter les ressources CPU du dom0

root@manjula:~# nano /etc/default/grub
# HB: limit dom0 to 2GB and affect 2 CPU
GRUB_CMDLINE_XEN="dom0_max_vcpus=2 dom0_vcpus_pin dom0_mem=2048M"
root@manjula:~# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
done
root@manjula:~# shutdown -r now
root@manjula:~# xm vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0     0   r--     116.3 0
Domain-0                             0     1     1   -b-      16.6 1

Deux CPU sont donc ici alloués au dom0, affectés aux cores physiques 0 et 1.

Limiter les ressources CPU d’un domU

root@manjula:~# nano /etc/xen/auto/pria
vcpus = 2
cpus = '2,3'
root@manjula:~# xm create uma
root@manjula:~# sleep 4 && xm vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0     0   r--     116.3 0
Domain-0                             0     1     1   -b-      16.6 1
pria                                 1     0     2   -b-     153.7 2-3
pria                                 1     1     3   -b-      76.9 2-3

Le domU pria utilise donc 2 CPU, affectés aux cores 2 et 3.

Xen : réservation de RAM pour le dom0 et désactivation du ballooning

Lors du boot noyau Linux, la quantité de RAM détectée (visible par l’OS) est utilisée entre autres pour l’allocation des buffers servant à la gestion réseau et au marquage des pages RAM. Dans le cas d’un dom0 sous Xen, il n’y a aucun intérêt à rendre visible l’ensemble de la RAM physique, vu qu’elle sera scindée et utilisée par la suite par les domU.

Ce billet présente comment allouer et limiter une quantité de RAM fixe au dom0, ici de 2 Go.

Mise en place

root@manjula:~# nano /etc/default/grub
GRUB_CMDLINE_XEN="dom0_mem=2048M";
root@manjula:~# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
done
root@manjula:~# nano /etc/xen/xend-config.sxp
# dom0-min-mem is the lowest permissible memory level (in MB) for dom0.
# This is a minimum both for auto-ballooning (as enabled by
# enable-dom0-ballooning below) and for xm mem-set when applied to dom0.
(dom0-min-mem 2048)

# Whether to enable auto-ballooning of dom0 to allow domUs to be created.
# If enable-dom0-ballooning = no, dom0 will never balloon out.
(enable-dom0-ballooning no)
root@manjula:~# shutdown -r now
root@manjula:~# free -m
total       used       free     shared    buffers     cached
Mem:          2043        249       1794          0          8         50
-/+ buffers/cache:        190       1853
Swap:        15255          0      15255

Xen : sauvegarde d’un VM Windows par LVM + clonage NTFS

root@xen:~# apt-get install ntfsprogs kpartx

Sauvegarde

root@xen:~# lvcreate -s -L1G -nvm_backup /dev/vg/xen_vm
root@xen:~# kpartx -a /dev/vg/xen_vm_backup
root@xen:~# ls -l /dev/mapper/vg-xen_vm_backup*
lrwxrwxrwx 1 root root      7 Oct 24 12:21 /dev/mapper/vg-xen_vm_backup -> ../dm-6
lrwxrwxrwx 1 root root      7 Oct 24 12:22 /dev/mapper/vg-xen_vm_backup1 -> ../dm-9
root@xen:~# ntfsclone -s -o vm-20121024.img /dev/mapper/vg-xen_vm_backup1
root@xen:~# lvdisplay vg/xen_vm > vm-20121024.txt
root@xen:~# kpartx -d /dev/vg/xen_vm_backup
root@xen:~# lvremove vg/xen_vm_backup

Restauration

root@xen:~# kpartx -a /dev/vg/xen_vm
root@xen:~# ntfsclone -r -O /dev/mapper/vg-xen_vm vm-20121024.img
root@xen:~# kpartx -d /dev/vg/xen_vm

Debian : configuration du bridge réseau pour Xen

Les packages Xen de Debian ne touche en rien la configuration réseau du système, ceci légitimement pour éviter une perte d’accès. Dans le cas d’une configuration en bridge, le script network-bridge de Xen permet de créer un pont réseau nommé eth0, ce qui n’est pas très standard. Ayant eu quelques problèmes avec ce script (erreurs de configuration au démarrage + la non prise en charge d’IPv6), la solution la plus sûre et stable consiste à le désactiver. Le bridge réseau peut dans ce cas être configuré de cette façon :

root@manjula:/etc/xen# cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eth0 inet manual

auto br0
iface br0 inet static
        address 192.168.100.5
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.254
        up ip -6 addr add fdcb:9921:3552:afd6::5/64 dev br0
        up ip -6 route add default via fdcb:9921:3552:afd6::1
        down ip -6 addr del fdcb:9921:3552:afd6::5/64 dev br0
        down ip -6 route del default via fdcb:9921:3552:afd6::1
        bridge_maxwait 5
        bridge_ports noregex eth0 regex vif.*
        bridge_stp off
        bridge_fd 0

Au niveau de Xen, le script réseau se désactive de cette façon :

root@manjula:/etc/xen# cat /etc/xen/xend-config.sxp
#(network-script 'network-bridge bridge=xenbr0 antispoof=yes')
(vif-script vif-bridge)

Au niveau de chaque domU, il faut évidemment spécifier le nom du bridge à utiliser :

root@manjula:~# cat /etc/xen/sandeep

 

name = 'sandeep'
kernel = '/usr/lib/xen-4.0/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-4.0/bin/qemu-dm'

memory = 2048
shadow_memory = 8
vcpus = 1
pae = 1
acpi = 1
apic = 1

vif = [ 'bridge=br0,type=paravirtualised' ]

disk = [ 'phy:/dev/vg/xen_sandeep,xvda,w' ]

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

vnc = 1
usbdevice = 'tablet'

stdvga = 0
serial = 'pty'
ne2000 = "0"

Xen 4 : patch pour une configuration bridge IPv6

Le script de configuration réseau en mode bridge de Xen (/etc/xen/scripts/network-bridge) ne prend en compte que les adresses au format IPv4. Ceci est problématique puisque Xen ne se chargera pas et au final vos domU ne pourront démarrer automatiquement.

Ce patch vous sera alors nécessaire pour prendre en compte l’adressage IPv6 :

--- network-bridge.old    2012-05-03 19:45:13.890075051 +0200
+++ network-bridge    2012-05-03 20:03:54.362049925 +0200
@@ -105,6 +105,10 @@
get_ip_info() {
addr_pfx=`ip addr show dev $1 | egrep '^ *inet' | sed -e 's/ *inet //' -e 's/ .*//'`
gateway=`ip route show dev $1 | fgrep default | sed 's/default via //'`
+    # HB: fix IPv6 bridge
+    addr_pfx_6=`ip -6 addr show dev $1 | egrep -m 1 '^ *inet' | sed -e 's/ *inet6 //' -e 's/ .*//'`
+    gateway_6=`ip -6 route show dev $1 | fgrep default | sed -e 's/default via //' -e 's/ .*//'`
+    echo "DEBUG: $addr_pfx_6 $gateway_6"
}

do_ifup() {
@@ -119,6 +123,19 @@
fi
}

+# HB: fix IPv6 bridge
+do_ifup_6() {
+    if [ $1 != "${netdev}" ] || ! ifup $1 ; then
+           if [ -n "$addr_pfx_6" ] ; then
+            # use the info from get_ip_info()
+            ip -6 addr flush $1
+        ip -6 addr add ${addr_pfx_6} dev $1
+            ip -6 link set dev $1 up
+            [ -n "$gateway_6" ] && ip route add default via ${gateway_6}
+        fi
+    fi
+}
+
# Usage: transfer_addrs src dst
# Copy all IP addresses (including aliases) from device $src to device $dst.
transfer_addrs () {
@@ -249,6 +266,8 @@
fi
add_to_bridge2 ${bridge} ${pdev}
do_ifup ${bridge}
+    # HB: fix IPv6 bridge
+    do_ifup_6 ${bridge}

if [ ${antispoof} = 'yes' ] ; then
antispoofing
@@ -280,6 +299,8 @@
ip link set ${bridge} name ${tdev}
ip link set ${pdev} name ${netdev}
do_ifup ${netdev}
+    # HB: fix IPv6 bridge
+    do_ifup_6 ${netdev}

brctl delbr ${tdev}

Xen 4 : installation d’une VM Windows serveur 2008

Alors aujourd’hui c’est ma fête et à quoi j’ai droit ? Installer deux VM Windows. Merci, vraiment merci. Donc çà ne méritera pas plus qu’un article type copié/collé tout bête et deux / trois images pour mettre de la couleur. Allez, la mission du jour, l’installation d’un serveur Xen 4 sous Debian 6 / Squeeze et la configuration d’une VM paravirtualisée sous Windows Server 2008.

Installation des packages

# apt-get install linux-image-2.6.32-5-xen-amd64 xen-hypervisor-4.0-amd64 xen-qemu-dm-4.0 genisoimage

Il faut évidemment installer le noyau correspondant à l’architecture matérielle de votre serveur.

# dpkg -l | grep '^ii' | grep xen
ii  libxenstore3.0                      4.0.1-4                      Xenstore communications library for Xen
ii  linux-image-2.6.32-5-xen-amd64      2.6.32-41squeeze2            Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64            4.0.1-4                      The Xen Hypervisor on AMD64
ii  xen-qemu-dm-4.0                     4.0.1-2+squeeze1             Xen Qemu Device Model virtual machine hardware emulator
ii  xen-utils-4.0                       4.0.1-4                      XEN administrative tools
ii  xen-utils-common                    4.0.0-1                      XEN administrative tools - common files
ii  xenstore-utils                      4.0.1-4                      Xenstore utilities for Xen

Configuration de GRUB

Pour booter sur le noyau xenifié (dom0), l’ordre de détection du noyau Xen par Grub doit être modifié afin que l’entrée correspondante dans le menu de démarrage soit positionnée en premier :

# dpkg-divert --divert /etc/grub.d/08_linux_xen  --rename /etc/grub.d/20_linux_xen
# nano /etc/default/grub

Grub se chargeant de détecter les OS installés, cette fonction est à proscrire pour ne pas polluer le menu de démarrage :

# Disable OS prober to prevent virtual machines on logical volumes from appearing in the boot menu.
GRUB_DISABLE_OS_PROBER=true

L’installation peut être enfin être lancée avec la nouvelle configuration :

# update-grub

Configuration de l’hyperviseur Xen

La configuration globale de Xen est à adapter pour faire joujou (l’accès réseau serait inopérant) :

# nano /etc/xen/xend-config.sxp
(network-script 'network-bridge bridge=eth0 antispoof=yes')
(vif-script vif-bridge)
(dom0-min-mem 1024)
(enable-dom0-ballooning yes)
(keymap 'fr')
# shutdown -r now

Suite au redémarrage, on vérifie que le noyau Xen est actif, que l’hyperviseur de Xen est chargé et que le bridge réseau eth0 et son interface physique peth0 (conventions Debian) sont présents :

# uname -a
Linux manjula 2.6.32-5-xen-amd64 #1 SMP Thu Mar 22 21:14:26 UTC 2012 x86_64 GNU/Linux
# xm info
host                   : manjula
release                : 2.6.32-5-xen-amd64
version                : #1 SMP Thu Mar 22 21:14:26 UTC 2012
machine                : x86_64
nr_cpus                : 8
nr_nodes               : 1
cores_per_socket       : 4
threads_per_core       : 2
cpu_mhz                : 2533
hw_caps                : bfebfbff:28100800:00000000:00001b40:0098e3fd:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 16343
free_memory            : 613
node_to_cpu            : node0:0-7
node_to_memory         : node0:613
node_to_dma32_mem      : node0:609
max_node_id            : 0
xen_major              : 4
xen_minor              : 0
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : placeholder
cc_compiler            : gcc version 4.4.5 (Debian 4.4.5-8)
cc_compile_by          : waldi
cc_compile_domain      : debian.org
cc_compile_date        : Thu Jun  9 18:38:03 UTC 2011
xend_config_format     : 4
# brctl show

Configuration de la VM Windows

Le stockage des VM repose sur des volumes logiques LVM. Un volume de 20 Go devrait être suffisant pour cette VM (qui a dit qu’on faisait rien de toute façon sous Windows ?!) :

# lvcreate -L20G -npria vg

Au tour ensuite du fichier de configuration de la VM ; ici le serveur s’appellera pria :

# nano /etc/xend/pria
name = 'pria'
kernel = '/usr/lib/xen-4.0/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-4.0/bin/qemu-dm'

memory = 2048
shadow_memory = 8
vcpus = 1
pae = 1
acpi = 1
apic = 1

vif = [ 'bridge=eth0' ]

disk = [ 'phy:/dev/vg/xen_pria,hda,w','file:/opt/win2008.iso,hdc:cdrom,r','file:/opt/win2008_drivers.iso,hdd:cdrom,r' ]
boot='dc'

usbdevice = 'tablet'

vnc=1
vnclisten = '0.0.0.0'
vncunused = 0
vncconsole = 1
vncviewer = 0
sdl = 0

stdvga = 0
serial = 'pty'
ne2000 = "0"

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

J’utilise deux lecteurs CD : un pour l’image d’installation de l’OS et l’autre pour les drivers paravirtualisés. Cela évitera 1 redémarrage … Les drivers paravirtualisés ont pour intérêt de faire dialoguer directement le domU avec l’hyperviseur Xen et non plus avec le dom0. Pour Windows, des drivers GPL sont disponibles ici :

http://wiki.univention.de/index.php?title=Installing-signed-GPLPV-drivers

Seuls des packages MSI étant proposés, il faut créer une ISO CD avec genisoimage :

# genisoimage -o win2008_drivers.iso gplpv_Vista2008x32_signed_0.11.0.356.msi

Les ISO nécessaires sont donc copiées dans /opt. Pour mémoire, l’option usbdevice permet de corriger le problème de placement du pointeur de la souris dans la console VNC.

Installation de Windows

Pour débuter l’installation de Windows, un accès VNC est requis. Pour ce faire, je lance une redirection locale par SSH du port 5900 distant afin d’accéder à la console VNC de la VM :

$ ssh root@manjula -N -L 5900:127.0.0.1:5900

Un client VNC local est ensuite lancé depuis mon poste sur localhost:5900.

Installation des drivers paravirtualisés

L’ISO des drivers correspond donc au deuxième lecteur CD que je monte dans la VM, il reste à lancer le package MSI d’installation.

Une fois redémarré, une nouvelle carte réseau fait son apparition ; il s’agit de la carte paravirtualisée. La VM doit être reconfigurée pour utiliser cette carte réseau par défaut, ce qui désactivera la seconde carte (non paravirtualisée). Les deux lecteurs CD peuvent aussi à cet instant être supprimés :

vif = [ 'bridge=eth0,type=paravirtualised' ]
disk = [ 'phy:/dev/vg/xen_pria,hda,w' ]

Une fois l’adressage réseau effectué, l’accès VNC est évidemment à désactiver au profit de l’utilisation de l’accès RDP.

OpenVZ : accès IPv6 en mode Virtual Ethernet (veth)

Contrairement au mode routé venet, le mode virtual ethernet veth d’OpenVZ permet de mapper directement une interface virtuelle Ethernet depuis l’hôte réel dans un serveur virtuel. La virtualisation réseau ne s’effectue donc plus au niveau 3 (routage IP) mais au niveau 2 (Ethernet). Chaque interface virtuelle possède alors son adresse MAC., ce qui autorise le trafic multicast (par finalité DHCP, SMB) et la gestion iptables dans vos CT. Les interfaces réseaux sont d’ailleurs adressables dans le serveur virtuel, pour peu que le mappage soit effectué entre l’hôte réel et l’hôte virtuel.

Je vais expliquer  dans ce billet les points importants afin de configurer le mode veth en IPv4 mais surtout IPv6. Ceci ne vous empêche pas une configuration mixte venet & veth.

OpenVZ est installé sous un hôte réel Debian Lenny 64 bits. Au niveau de sa configuration réseau, une interface bridge vmbr0 est créée à laquelle j’ajoute les IP publiques du serveur  : une IPv6 et une IPv4 en alias. Par la suite, les interfaces réseaux virtuelles veth<CTID>.<ID> seront créées par OpenVZ, qui les ajoutera au bridge, tout en les mappant dans le CT considéré en interface eth<ID>.

root@HN:/# more /etc/network/interfaces
root@HN:/# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet6 static
 address  2001:1234:5678::2
 netmask  48
 gateway  2001:1234:5678::1
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0
auto vmbr0:0
iface vmbr0:0 inet static
 address  81.23.45.226
 netmask  255.255.255.224
 gateway  81.23.45.225

Les paramètres noyaux suivants sont à fixer pour pouvoir bénéficier du support IPv4 et IPv6 depuis l’environnement virtualisé :

root@HN:/# more /etc/sysctl.conf
kernel.sysrq = 1
net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.proxy_ndp = 1
net.ipv6.conf.all.proxy_ndp = 1
# custom
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.autoconf = 0

L’activation du forwarding IPv4 n’est nécessaire que si vos VPS sont susceptibles d’utiliser des adresses IP privées (le NAT devant être réalisé par un firewall). Le forwarding IPv6 est quant à lui obligatoire. Les deux dernièrs paramètres permettent de désactiver l’auto-configuration IPv6 des interfaces réseaux, ce qui sera répercuté dans les serveurs virtuels. Ceci n’est pas obligatoire, mais sécurise le tout en rendant obligatoire une configuration statique.

La création d’un CT en mode veth est simple, il suffit d’omettre la configuration réseau au moment de sa création :

root@HN:/# vzctl create 101 --ostemplate debian-6.0-standard_6.0-2_amd64

Par contre, il faut créer les interfaces réseaux par la suite :

root@HN:/# vzctl set 101 --netif_add eth0 --save
root@HN:/# vzctl set 101 --netif_add eth1 --save

Ici, j’ai créé la première interface pour son IPv6 et la seconde pour son IPv4. Le serveur virtuel peut maintenant être démarré :

# vzctl start 101
Starting container ...
Container is mounted
Setting CPU units: 1000
Setting CPUs: 1
Set hostname: vps101.interact.lu
File resolv.conf was modified
Setting quota ugidlimit: 0
Configure veth devices: veth101.0 veth101.1
Adding interface veth101.0 to bridge vmbr0 on CT0 for CT101
Adding interface veth101.1 to bridge vmbr0 on CT0 for CT101
Container start in progress...

OpenVZ a donc créé les interfaces veth101.0 (mappée sur eth0) et veth101.1 (mappée sur eth1), tout en les ajoutant à notre bridge vmbr0.

root@HN:/# vzctl enter 101

Avant de configuer les interfaces réseaux côté CT, il faut désactiver le forwarding :

root@HN:/# vzctl enter 101
root@CT:/# more /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.mc_forwarding = 0

Au niveau de la configuration réseau dans le CT, rien de spécial à spécifier mais il faut forcer les routes par défaut. En IPv6, la route par défaut n’est pas appliquée par l’option gateway (peut être une subtilité Debian, rien de dramatique).J’ai donc recours aux options up :

root@CT:/# more /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet6 static
   address 2001:1234:5678::3
   netmask 48
   up /sbin/ip -6 route add default via 2001:1234:5678::1
auto eth1
  iface eth1 inet static
  address 81.23.45.227
  netmask 255.255.255.224
  up /sbin/ip route add default via 81.23.45.225

Reste à appliquer la nouvelle configuration  :

root@CT:/# /etc/init.d/networking restart
Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces ... (warning).
Reconfiguring network interfaces...done.

Puis à vérifier l’accès réseau :

root@CT:/# ifconfig
eth0      Link encap:Ethernet  HWaddr 1a:a5:96:8c:72:91
 inet6 addr: fe80::18a5:96ff:fe8c:7291/64 Scope:Link
 inet6 addr: 2001:1234:5678::3/48 Scope:Global
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:68106 errors:0 dropped:0 overruns:0 frame:0
 TX packets:33712 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:98987770 (94.4 MiB)  TX bytes:2480372 (2.3 MiB)

eth1      Link encap:Ethernet  HWaddr 00:18:51:e2:0e:f8
 inet addr:81.23.45.227  Bcast:81.23.45.255  Mask:255.255.255.224
 inet6 addr: fe80::218:51ff:fee2:ef8/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:2194 errors:0 dropped:0 overruns:0 frame:0
 TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:101387 (99.0 KiB)  TX bytes:2743 (2.6 KiB)

lo        Link encap:Local Loopback
 inet addr:127.0.0.1  Mask:255.0.0.0
 inet6 addr: ::1/128 Scope:Host
 UP LOOPBACK RUNNING  MTU:16436  Metric:1
 RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
root@CT:/# ping6 -c4 2001:1234:5678::1
PING 2001:1234:5678::1(2001:1234:5678::1) 56 data bytes
64 bytes from 2001:1234:5678::1: icmp_seq=1 ttl=64 time=0.460 ms
64 bytes from 2001:1234:5678::1: icmp_seq=2 ttl=64 time=0.445 ms
64 bytes from 2001:1234:5678::1: icmp_seq=3 ttl=64 time=0.422 ms
64 bytes from 2001:1234:5678::1: icmp_seq=4 ttl=64 time=0.420 ms

--- 2001:1610:4::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.420/0.436/0.460/0.030 ms

Reste ensuite à sécuriser le tout en faisant votre parefeu iptables, mais ceci sera l’objet d’un article à venir.

OpenVZ : script de sauvegarde des CT

Voici le script que j’utilise pour dumper quotidiennement l’ensemble de mes CT OpenVZ. Outre les options de dump habituelles, il  est possible de préciser le nombre de dumps à conserver localement sur le HN et d’activer une copie des dumps par rsync sur un serveur distant, en vue de constituer un historique plus conséquent. Il est possible de limiter le débit I/O de génération des dumps (I/O disque) tout comme pour la copie (I/O réseau) afin d’éviter une perturbation conséquente de votre serveur.

Bref, c’est simple et efficace, donc à placer en cron très rapidement !

#!/bin/bash
#
# vzbackup.sh
#
# Boris HUISGEN <bhuisgen@hbis.fr>
#

PATH=$PATH:/usr/sbin

# backup settings

VZDUMP_DIR="/home/backup/vz"    # backup directory
VZDUMP_MODE="snapshot"          # dump mode (stop/suspend/snapshot)
VZDUMP_COMPRESS="yes"           # compress dump files (yes/no)
VZDUMP_MAXFILES="3"             # maximum backups per CT to keep in local
VZDUMP_BWLIMIT="0"              # limit I/O bandwith (unit kbytes/s, 0 to disable)
VZDUMP_EXTRA_OPTIONS=""         # extra options (man vzdump)

# remote copy settings

RSYNC_ENABLE="yes"              # copy backup directory to remote server (yes/no)
RSYNC_HOST="backup.my.domain"   # remote server host
RSYNC_USER="root"               # remote server user
RSYNC_DIR="/home/backup/mcbain" # remote server directory
RSYNC_DELETE="no"               # delete old backups on remote server (set to no to keep a remote historic)
RSYNC_BWLIMIT="0"               # limit I/O bandwith (unit kbytes/s, 0 to disable)
RSYNC_EXTRA_OPTIONS=""          # extra options (man rsync)

#
# DO NOT MODIFY AFTER THIS LINE !!!
#

VZLIST="$(which vzlist)"
VZDUMP="$(which vzdump)"
VZDUMP_OPTIONS="--stdexcludes"

RSYNC="$(which rsync)"
RSYNC_OPTIONS="-avz"

function log {
 echo "[" `date "+%Y-%m-%d %H:%M:%S"` "] $1"
}

# create backup directory
if [ ! -d $VZDUMP_DIR ]
then
 mkdir -p $VZDUMP_DIR;
fi

# set vzdump options
VZDUMP_OPTIONS="$VZDUMP_OPTIONS --$VZDUMP_MODE"

if [ $VZDUMP_COMPRESS = "yes" ]
then
 VZDUMP_OPTIONS="$VZDUMP_OPTIONS --compress"
fi

VZDUMP_OPTIONS="$VZDUMP_OPTIONS --maxfiles $VZDUMP_MAXFILES"

if [ $VZDUMP_BWLIMIT -gt "0" ]
then
 VZDUMP_OPTIONS="$VZDUMP_OPTIONS --bwlimit $VZDUMP_BWLIMIT"
fi

if [ -z $VZDUMP_EXTRA_OPTIONS ]
then
 VZDUMP_OPTIONS="$VZDUMP_OPTIONS $VZDUMP_EXTRA_OPTIONS"
fi

# set rsync options
if [ $RSYNC_DELETE = "yes" ]
then
 RSYNC_OPTIONS="$RSYNC_OPTIONS --delete"
fi

if [ $RSYNC_BWLIMIT -gt "0" ]
then
 RSYNC_OPTIONS="$RSYNC_OPTIONS --bwlimit=$RSYNC_BWLIMIT"fi
fi

if [ -z $RSYNC_EXTRA_OPTIONS ]
then
 RSYNC_OPTIONS="$RSYNC_OPTIONS $RSYNC_EXTRA_OPTIONS"
fi

# dump all CT
for CT in `$VZLIST -Ho veid`; do
 log "Starting backup of CT $CT..."

 # create CT directory
 VZDUMP_SUBDIR="$VZDUMP_DIR/$CT"
 if [ ! -d $VZDUMP_SUBDIR ]
 then
  mkdir $VZDUMP_SUBDIR
 fi

 # start vzdump
 $VZDUMP $VZDUMP_OPTIONS --dumpdir=$VZDUMP_SUBDIR $CT

 log "Backup done."
done

# copy backup directory to remote server
if [ $RSYNC_ENABLE = "yes" ]
then
 log "Synchronizing to remote server..."

 # start rsync
 $RSYNC $RSYNC_OPTIONS $VZDUMP_DIR/ $RSYNC_USER@$RSYNC_HOST:$RSYNC_DIR/

 log "Synchronization done."
fi

# end of script

Voici un exemple de sortie :

# ./vzbackup.sh
Starting backup of CT 101...
INFO: starting new backup job: vzdump --stdexcludes --snapshot --compress --maxfiles 4 --dumpdir=/home/backup/vz/101 101
INFO: Starting Backup of VM 101 (openvz)
INFO: CTID 101 exist mounted running
INFO: status = CTID 101 exist mounted running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating lvm snapshot of /dev/mapper/openvz-vz ('/dev/openvz/vzsnap-mcbain-0')
INFO:   Logical volume "vzsnap-mcbain-0" created
INFO: creating archive '/home/backup/vz/101/vzdump-openvz-101-2011_02_16-17_42_01.tgz'
INFO: Total bytes written: 2044569600 (2.0GiB, 8.9MiB/s)
INFO: archive file size: 1016MB
INFO:   Logical volume "vzsnap-mcbain-0" successfully removed
INFO: Finished Backup of VM 101 (00:05:24)
INFO: Backup job finished successfuly
Backup done.
Synchronizing to remote server...
sending incremental file list
101/
101/vzdump-openvz-101-2011_02_16-17_42_01.log
101/vzdump-openvz-101-2011_02_16-17_42_01.tgz
Synchronization done.

Réseau : firewall sur mesure pour installation Proxmox / OpenVZ

Malgré quelques solutions existantes ici et , j’ai opté pour un pare-feu spécifique afin de protéger mes serveurs virtuels sous Proxmox / OpenVZ. J’ai donc utilisé FirewallBuilder pour le générer.  Une template réutilisable est disponible au téléchargement en fin d’article.

Les serveurs virtuels (VPS) sont placés sur le réseau privé 192.168.0.0/24, où du NAT est appliqué pour la redirection de ports dans le cas où une seule IP publique est disponible. Ainsi, le bridge vmbr0 est utilisé pour l’accès public – vous y ajouterez vos IP publiques supplémentaires – et le bridge vmbr1 pour les communications entre les VPS et l’hôte.

De base, les flux sortants DNS / SMTP sont seulement autorisés pour l’hôte réel. Les VPS doivent donc utiliser le serveur DNS & SMTP de l’hôte réel. Par sécurité, j’ai mappé l’accès à l’interface Proxmox sur le port 4443 (le HTTPS standard étant alors récupéré par le VPS web). Une blacklist est configurée, que vous pouvez manipuler en éditant le fichier /etc/firewall-bad_hosts (règle n°0) afin de bloquer d’éventuels attaquants. N’oubliez pas de créer ce fichier !

Liste des interfaces réseaux :

  • eth0 : utilisée par vmbr0.
  • vmbr0 : bridge sur eth0, utilisé pour les IP publiques.
  • vmbr1 : bridge sans port, utilisé pour le réseau dédié aux VPS.
  • venet0 : interface réseau présente dans chaque VPS.

Listes des hôtes :

  • proxmox.my.domain (192.168.0.254) : IP privée de l’hôte réel, permettant aux VPS d’utiliser les services communs DNS et SMTP proposés par l’hôte réel.
  • vps-www.my.domain (192.168.0.1) : serveur virtuel dédiée aux sites Web.
  • vps-sql.my.domain (192.168.0.2) : serveur virtuel dédié au serveur SQL.

Listes des redirections de ports :

  • 80/TCP => vps-www.my.domain – 80/TCP
  • 443/TCP => vps-www.my.domain – 443/TCP
  • 2222/TCP => vps-www.my.domain – 22/TCP (accès SSH)
  • 4443/TCP => hôte réel 443/TCP (interface de gestion Proxmox)

Pour finir, une fois effectuées les adaptations à votre configuration réseau, je vous conseille de modifier la règle n°4 pour restreindre l’accès SSH + interface Proxmox à vos IP de connexion Internet. Une fois effectuée, vous pourrez d’ailleurs ajouter le flux VNC pour l’administration Proxmox.

Configuration réseau :

# cat /etc/network/interfaces
# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
 address  80.80.80.80
 netmask  255.0.0.0
 gateway  80.80.80.1
 broadcast  80.255.255.254
 bridge_ports eth0
 bridge_stp off
 bridge_fd 0
 network 80.0.0.0

auto vmbr1
iface vmbr1 inet static
 address  192.168.0.254
 netmask  255.255.255.0
 bridge_ports none
 bridge_stp off
 bridge_fd 0

Template firewall pour Proxmox / OpenVZ : [Téléchargement introuvable]

Haut de page