Por defecto cuando añadimos un SR, XenServer lo configura con un io-scheduler llamado “noop”, este planificador es generalista y da un rendimiento correcto en la mayoría de casos. Básicamente el planificador ofrece un repartimiento justo a las máquinas virtuales que compiten con el acceso a un mismo dispositivo
Los que hayáis usado Xen sin Xapi, seguramente conoceréis el comando xm, un toolstack para gestionar las operaciones básicas, (xm migrate) mover máquinas virtuales entre hosts, (xm create) crear máquinas virtuales, etc… Al menos yo, la primera vez que vi un XenServer, intente ejecutar xm y me encontré con el mensaje de error command not found
En un clúster o Pool, siempre tiene que haber un nodo designado como “Master”, mientras que los otros miembros, se denominan “slaves”. El rol master se caracteriza por “exponer” la administración del clúster de forma centralizada y reenvía los comandos a los otros nodos si es necesario. Por ejemplo, siempre que nos conectamos con XenCenter, la conexión se realiza contra el nodo master
En el primer momento que configuramos una LUN para que sea un SR (Storage Repository), desde XenCenter, quedan serializados de modo read-only los parámetros principales para la conexión ISCSI, la IP de la SP de la cabina de discos, su IQN, ISCSI_ID… Esto es un problema, si tenemos por ejemplo que cambiar las IPs de las controladoras, por motivos de crecimiento, o de reordenación
Hoy vamos hablar sobre el estado actual de actualizaciones de Citrix XenServer 6.1. Desde la aparición de la nueva versión ya se han detectado errores y se han desarrollado diferentes parches para solucionarlos
