Archives pour la catégorie ‘Xen’

Amazon EC2 : fix de configuration Xen avec instance HVM

# dmsg
[335773.344080] xen:balloon: Cannot add additional memory (-17)
[335805.413385] xen:balloon: Cannot add additional memory (-17)
[335837.536078] xen:balloon: Cannot add additional memory (-17)
 
# cat /sys/devices/system/xen_memory/xen_memory0/info/current_kb > /sys/devices/system/xen_memory/xen_memory0/target_kb

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.

Haut de page