Difference between revisions of "Xen Best Practices/es"

From Xen
m (Algunos cambios menores en la traducción)
m
Line 23: Line 23:
 
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.
 
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.
   
== Why should I dedicate fixed amount of memory for Xen dom0? ==
+
== Por qué dedicar una cantidad fija de memoria para dom0 ==
Dedicating fixed amount of memory for dom0 is good for two reasons:
+
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.
First of all (dom0) Linux kernel calculates various network related parameters based on the boot time amount of memory.
 
   
  +
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.
The second reason is Linux needs memory to store the memory metadata (per page info structures), and this allocation is also based on the boot time amount of memory.
 
   
  +
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.
Now, if you boot up the system with dom0 having all the memory visible to it, and then balloon down dom0 memory every time you start up a new guest, you end up having only a small amount of the original (boot time) amount of memory available in the dom0 in the end. This means the calculated parameters are not correct anymore, and you end up wasting a lot of memory for the metadata for a memory you don't have anymore. Also ballooning down busy dom0 might have bad side effects.
 
   
 
== Xen credit scheduler domain weights and making sure dom0 gets enough CPU time to serve IO requests (disk/net) ==
 
== Xen credit scheduler domain weights and making sure dom0 gets enough CPU time to serve IO requests (disk/net) ==

Revision as of 10:50, 20 December 2011

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.

Languages Language: English  • Deutsch • español • français • 日本語 • 한국어 • português do Brasil • русский • 中文