Xen Best Practices/es

Buenas Prácticas con Xen

Esta página de la wiki lista varias de las mejores prácticas para ejecutar el hypervisor de Xen.

La información siguiente es aplicable a la versión opensource de Xen xen.org, no necesariamente implica a Citrix XenServer o XCP.

Memoria dedicada (dom0) y cómo prevenir el efecto ballooning de memoria (dom0)

Se debe fijar siempre una cantidad fija de memoria dedicada de RAM para el dom0.

Esto se hace especificándolo en la opción "dom0_mem=512M" del hypervisor de Xen (normalmente en xen.gz) del menu del grub.conf/menu.lst. Esto asegura que la cantidad de memoria asignada para el dom0es de 512MB (sustitúyala con la cantidad de memoria que quiera), y el resto de la RAM se queda disponible para otros invitados que maneje el hypervisor de Xen. A continuación, un ejemplo de grub.conf con GRUB1:

title Xen 4.1.0 / pv_ops dom0 kernel 2.6.32.36
        root (hd0,0)
        kernel /xen-4.0.gz dom0_mem=512M loglvl=all guest_loglvl=all
        module /vmlinuz-2.6.32.36 ro root=/dev/sda2 console=hvc0 earlyprintk=xen nomodeset
        module /initrd-2.6.32.36.img

El siguiente paso es configurar xend para asegurar que la memoria del dom0 nunca disminuye tanto por el efecto de ballooning, al iniciar un nuevo invitado.

Esto se consigue editando /etc/xen/xend-config.sxp y modificando la opción "dom0-min-mem" como (dom0-min-mem 512) y también cambiando la opción "enable-dom0-ballooning" a (enable-dom0-ballooning no). Estas opciones asegurarán que xend nunca se lleve la memoria del dom0.

Después de hacer estos cambios al grub.conf y al xend-config.sxp, reinicie el sistema. Después de reiniciar, se dará cuenta de que el dom0 sólo tiene 512 MB de memoria, y el resto de la RAM está disponible en el hypervisor de Xen como memoria libre. Ejecute "xm list" para verificar la cantidad de memoria que tiene dom0, y "xm info" para verificar la cantidad de memoria libre en el hypervisor de Xen.

Por qué dedicar una cantidad fija de memoria para dom0

Asignar una cantidad fija de memoria al dom0 es bueno por dos razones:

Primero, el kernel de Linux (dom0) calcula varios parámetros de red según la cantidad de memoria que se le deje en el arranque del sistema.

Lo segundo, es que Linux necesita memoria para guardar los metadatos de memoria (estructuras de información por página), y esta asignación se hace en base a la cantidad de memoria que encuentra al arrancar el sistema.

Entonces, si se arranca el sistema dejando visible toda la memoria al dom0, después de se disminuye la memoria del dom0 cada vez que se arranca un invitado, y el dom0 termina quedándose con muy poca de la memoria que originalmente tuvo al arranque primero. Esto hace que los parámetros calculados no sean los correctos, y se desperdicie mucha de la memoria para los metadatos de una memoria a la que yo se tiene alcance. El hecho de disminuir la memoria del dom0 como consecuencia del efecto ballooning, puede que tenga otros efectos no deseados.

Xen credit scheduler domain weights and making sure dom0 gets enough CPU time to serve IO requests (disk/net)

For smooth operation and good guest performance you need to make sure dom0 always gets enough CPU time to process and serve the IO requests for guest VMs.

This can be guaranteed by setting up Xen credit scheduler domain weights and caps. See [[[CreditScheduler]]] wiki page for more information.

Some background: As a default Xen gives every guest (including dom0) the default weight of 256. This means all guests (including dom0) are equal, and get the same amount of CPU time. This can be bad for dom0, since it needs to be able to serve and process the IO requests for other guests. You should give dom0 more weight, so it will get more CPU time than the guests, when it needs it.

Example commands:

• use "xm sched-credit -d Domain-0" to check the current Xen credit scheduler parameters for Dom0.
• use "xm sched-credit -d Domain-0 -w 512" to give dom0 weight of 512, giving it more (up to twice as much) CPU time than the guests.

Note that you need apply this setting after every reboot! It's not persistent setting. You can place the "xm sched-credit" to rc.local or other script that is executed late in the boot process. Make sure the command is executed after xend is started, since the xm command needs to talk to xend.

Dedicating a CPU core(s) only for dom0

If you're running IO intensive guests or workloads in the VMs it might be a good idea to dedicate (pin) a CPU core only for dom0 use. Please see [[[XenCommonProblems]]] wiki page section "Can I dedicate a cpu core (or cores) only for dom0?" for more information.

Dom0 network configuration

You should configure and set up networking on Xen dom0 using the networking scripts provided by your dom0 distribution, ie. "/etc/network/interfaces" on Debian and Ubuntu, and "/etc/sysconfig/network-scripts/ifcfg*" in RHEL/CentOS/Fedora. The "distro-method" is much better than using the xen "network-bridge" script, which is troublesome on many configurations due to renaming tricks it uses.

If using XL / LIBXL toolstack (Xen 4.1+) you're actually required to set up the networking using distro network scripts!

To use distro networking scripts/tools:

• If using xm/xend toolstack disable the Xen network-script in "/etc/xen/xend-config.sxp", ie. comment out the "network-script" line, or make it be "/bin/true".
• Configure network settings (bridges etc) using the networking scripts available on your dom0 distribution. See the documentation of your distro for more help.
• Reboot.

You can still use the default Xen vif-bridge script to attach VM vifs to the bridges you have configured using the distro networking tools, so no changes are required to the domU configuration files in "/etc/xen/<domU>".

See HostConfiguration/Networking: wiki page for examples how to use the distro network scripts.

Common problems with Xen

Also check the XenCommonProblems wiki page for answers to many common problems related to using/running Xen.