Entre ruedas y alas

Migraciones de un Pool de XenServer a 6.2

febrero 13th, 2014 | Posted by cristiansan in Citirx | ctxdom | Upgrade | XenServer - (0 Comments)

Durante las migraciones de nuestros servidores de XenServer a nuevas versiones recomendamos tener en cuenta lo siguiente:

– No es posible migrar VMs a una version mas vieja. Solo igual o superior.

– No se recomienda tener un entorno mixto por largos periodos. En este caso, siempre funcionara con el nivel funcional mas viejo y puede haber opciones que no esten disponibles.

– Si actualizamos un pool, siempre debe actualizar-se el Master primero.

– Los SR no son tocados durante el proceso de upgrade.

– Se recomienda un backup del statedb del Pool (xe pool-dump-database).

– Antes de empezar, descargar la última version de XenCenter, ya que tras actualizar XS solo podremos conectar a él con la última versión de XenCenter

– Quitar los CDs/DVDs asignados a todas las VMs.

– Des-habilitar el HA.

Además, debemos tener en cuenta, que durante la migración a XS6.2 de un pool…

– Todos los servidores del mismo pool disponen del mismo número de NICs y configuradas igual si es posible.

XS6.2 puede configurar las redes a nivel de Pool. Ello implica que todos los servidores deben tener la misma configuracion de red, tanto en número de NICs como en las configuraciones especificas del mismo, si no queremos tener problemas no controlados durante el proceso de upgrade:

Tal como indica la documentación…

“Before creating networks, note that the cabling must match on each host in the pool. That is, the NICs on each host must be plugged in to the same physical networks as the corresponding NICs on the other hosts in the pool “

“All XenServer hosts in a resource pool should have the same number of physical network interface cards (NICs), although this requirement is not strictly enforced when a XenServer host is joined to a pool.”

“If one XenServer host has a different number of NICs than other hosts in the pool, complications can arise because not all pool networks will be valid for all pool hosts. “

Cabe tener en cuenta que cualquier host añadido al Pool, recivira la misma configuración de red establecida en el pool y por ello la importancia de asignar igual las redes del host. Así, es imperativo esta recomendación?

NO, pero se recomienda si queremos evitar problemas no controlados durante los procesos de migración o/e inclusión de los servidores de XenServer en el Pool.

En la FAQ de XS6.2 podemos observar:

«What types of configurations can be made at the Resource Pool level?

Shared remote storage and networking configurations can be made at the resource-pool level. Once a configuration is shared on the Resource Pool, the master system automatically propagates configuration changes to all of the member systems.

Will new host systems added to a Resource Pool automatically be configured with shared settings?

Yes. Any new host systems added to a Resource Pool automatically receive the same configurations for shared storage and network settings.»

Así, pues antes de llevar a cabo una actualización de nuestro Pool de XenServer, comprobad las recomendaciones y planificar el proceso de Upgrade para evitar al máximo problemas conocidos del proceso.

Adicionalmente, entre las Release notes de XS6.2 encontramos:

If the Rolling Pool Upgrade Wizard discovers storage that is detached and cannot be reattached, it will fail (even when no VMs are using the storage). Customers should either fix the access to the storage repository or remove it from the XenServer pool before restarting the wizard. [CA-72541]

The XenCenter Rolling Pool Upgrade wizard should not be used with Boot from SAN environments. For more information on upgrading boot from SAN environments, see Appendix B of the XenServer 6.2.0 Installation Guide .

If a Rolling Pool Upgrade fails when upgrading a pool of XenServer hosts, customers should avoid migrating VMs with shared storage from an upgraded host to a non-upgraded host. Performing such migrations can cause the VMs to hang or crash. [CA-108234]

After upgrading XenServer hosts from version 6.0.2 and earlier to version 6.2.0, customers using Single Root I/O Virtualization (SR-IOV) with Intel NICs will be unable to start VMs. Customers should follow the procedure in CTX134054. [CA-89008].

The vSwitch Controller may fail to show dependant (slave) networks that had been bonded when NIC bonds are deleted. To resolve this issue, refresh the status of the pool or restart the vSwitch Controller. The networks should then reappear. [CA-65261]

iSCSI paths that are not available when a XenServer host is booted, do not get established automatically later. This can be resolved by either performing another host reboot or by detaching and re-attaching the SR. [CA-73867]

vCPU pinning information is not respected when VMs are migrated. [CA-96952]

After an upgrade to XenServer 6.2.0, details on the date and time VMs were started at may be lost. There is no workaround for this. However, the operation of the VM will be unaffected. [CA-97869]

After installing the XenServer Tools, customers should reboot their hosts when prompted by the Citrix XenServer Tools installer. After the XenServer Tools installer has closed, all paravirtualised drivers and the XenServer Tools are installed and a further reboot is not required. Customers can safely ignore any pop-up window requesting a further reboot. [CA-107094]

Customers upgrading from XenServer 5.6x who have not upgraded the XenServer Tools in their Windows VMs, will not be able to use quiesced snapshots. Customers should upgrade their XenServer Tools after host upgrade, to restore this functionality. [CA-108370]

Storage XenMotion is only possible on live VMs with XenServer Tools installed. In the event that a VM crashes during Storage XenMotion, the Storage XenMotion operation will abort. [CA-85053]

Para mas detalles consultar las Release notes de XS6.2.

Resources:

FAQ XenServer 6.2 http://support.citrix.com/article/CTX137836

Manual de Administrador XenServer 6.2 http://support.citrix.com/article/CTX137828

Release Notes XenServer 6.2 http://support.citrix.com/article/CTX137826

No aparecen contadores XD en los dispositivos VDA

Tal y como ocurría en los servidores con XenApp instalados, puede ocurrir que existan dispositivos en los cuales, cuando nos es necesario incluir en perfmon métricas de rendimiento para la supervisión del entorno, estas no se encuentren disponibles.

Ello afecta a los equipos de Escritorio VDA, y la solución pasa por el correcto registro de las DLLs necesarias. Cabe indicar, que la falta de estos contadores afecta directamente a herramientas de monitorización tales como podrían ser HDX Monitor, EdgeSight, Director, etc.

Para solventar el problema únicamente deberemos registrar de forma manual la DLL ICAperf.dll tal y como hacíamos en xenapp.

regsvr32 “%programfiles%\Citrix\ICAService\icaperf.dll”

Reinicio automático tras Logoff en XenDesktop 7.x

Al realizar logoff en una maquina virtual de XenDesktop, este, por defecto, reinicia la maquina.

Para modificar los reinicios de escritorio, no es posible utilizar directivas ni opciones especificas desde Citrix Studio. Para ello, tendremos que hacer uso de nuestro querido Power-Shell.

Primero, vamos a consultar como ver el estado del Shutdown de un Desktop Group concreto:

Get-brokerDesktopGroup | fl name,ShutdownDesktopsAfterUse

Name : Desktop_Group_Name

ShutdownDesktopsAfterUse : True

Ello implica, que cada vez que desconectamos de nuestra VM, esta sea reiniciada.

Para evitar este reinicio en proceso de logoff y poder reiniciar las VMs únicamente cuando nosotros queramos, deberemos utilizar PowerShell para modificar dicho parámetro.

Para ello ejecutaremos:

Set-BrockerDesktopGroup –Name “Desktop_Group_Name” –ShutdownDesktopsAfterUse $False

Localizar el Servidor Master del Pool de XenServer

noviembre 25th, 2013 | Posted by cristiansan in Citirx | CLI | tricks | XenServer - (0 Comments)

Existe un método rápido para localizar el Master de un Pool de XenServer?

De echo, existen, como mínimo, tres métodos para ello.

Vamos a empezar, del mas difícil, pero mas «molón» al mas sencillo.

Método 1: Using CLI: XE commands

xe pool-list params=uuid,master

Ello nos mostrara la lista de host, con su UUID y el UUID del Master. Tras ello, ejecutamos:

xe host-list uuid=UUID_Master

Substituimos UUID_Master, con el UUID suministrado el anterior comando. Ello nos mostrara el host master del actual pool de XenServer.

Método 2: Using CLI: Cat file

El servidor master actual se almacena en un fichero dentro de los host de XenServer. Este es llamado Pool.conf. Así que un sencillo «cat» sobre el fichero, nos mostrará el nombre del Master del Pool de XenServer

cat /etc/xensource/pool.conf

Método 3: Using XenCenter

El método mas sencillo. El primer host aparecido, bajo el nombre del Pool de XenServer… es el servidor maestro de XenServer.

Pues eso es todo, ¿se os ocurre algún método mas?

PowerShell: Añadir usuarios en XenApp 6/6.5

Vamos a ver como obtener detalles y añadir usuarios sobre aplicaciones publicadas en XenApp desde PowerShell.

Lo primero que debemos realizar es instalar SDK de CITRIX XenApp.

URL: http://community.citrix.com/display/xa/XenApp+6.5+Powershell+SDK

Arrancar «PowerShell With Citrix XenApp»

o arrancar PowerShell y cargar Snap-Ins de Citrix XenApp SDK.

Add-PSSnapin Citrix.XenApp.Commands

Los modulos cargados en el proceso són:

Lanzamos los primeros comandos:

Get-XAApplication

Ello mostrará una lista con todas las aplicaciones y sus detalles.

Si queremos obtener la lista de aplicaciones de una carpeta de publicación determinada, podemos ejecutar:

El campo que nos ocupa en este caso a consultar es:

FolderPath : Applications/Folder1/Folder2/

Para realizar la consulta sobre las aplicaciones de una carpeta, ejecutaremos:

Get-XAApplication –FolderPAth “Applications/Folder1/Folder2”

Con ella, también obtendremos un detalle de todas las apps. Si a esta consulta, queremos obtener únicamente los nombres de las aplicaciones, filtraremos del siguiente modo:

Get-XAApplication –FolderPAth “Applications/Folder1/Folder2” | Format-Table –Autosize –Property BrowserName (o DisplayName)

Obtenida la lista de las aplicaciones que queremos modificar, es el momento de empezar a realizar modificaciones.

Add-XAApplicationAccount Application Domain\User

Ello incluirá el usuario domain\user sobre la aplicación “Application”.

Y si queremos incluir el usuario a todas las aplicaciones de la carpeta?

Hagamos-lo!

foreach($application in Get-XAApplication –FolderPath “Applications/Folder1/Folder2”) {
Add-XAApplicationAccount $application.DisplayName «Domain\test1»
}

Tunning Dom0 en XenServer (memoria y vcpus)

XenServer permite el “tunning” del Dom0 de cara a mejorar la escalabilidad del entorno cuando es necesario, poniendo de este modo el rendimiento de nuestro hypervisor al máximo.

Cabe indicar, que no siempre estas recomendaciones son aplicables y que habrá que ver cada entorno, para saber si es o no es aplicable. De echo, normalmente estas recomendaciones no serán aplicables ya que la configuración por defecto de XenServer es en la mayoría de casos suficiente.

Pero si tenéis problemas de rendimiento a pesar de tener suficiente CPU y memoria, ello puede estar ocasionado por un cuello de botella es nuestro dominio de control y los siguientes ajustes podrían solventar en algunos casos dicha perdida de rendimiento.

Cuando un host XenServer arranca, el hypervisor carga una pequeña VM invisible para los usuarios; incluso para los administradores en algunos casos. Esta VM es conocida como Dominio de Control o Dom0. Dom0 se ejecuta en la pila de gestión y proporciona servicios básicos al resto de las VMs, como el acceso físico a los dispositivos.

No existe un número determinado de VMs en las cuales podamos asegurar que la vcpu0 de dom0 se colapse, ocasionando un cuello de botella. Dependerá también en gran medida del tipo de VMs que estemos rodando, pudiendo ser necesario realizar cambios en dom0 a partir de 60-70 vms o no siendo necesario realizar incluso con 100 vms rodando. Por ello, es importante no tener una referencia numérica en este aspecto, y revisar los contadores y el estado de nuestro Dom0 para asegurar un correcto tunning. En el 99% de los casos, no serán necesarias modificaciones en Dom0.

Si durante el uso de nuestro host, observamos problemas de rendimiento, y mediante xentop comprobamos un uso excesivo (llegando al 100% constante) de recursos, se recomienda, en estos casos, el tuning de dom0, ampliando memoria o asignando vcpus, según corresponda.

Ya hemos hablado de ampliar el número de vcpus de nuestro dominio de control, pero también la memoria se puede ver afectada en estos problemas de cuello de botella. Sobretodo en entornos con mas de 50 Vms corriendo por host. En estos, se recomienda la ampliación de memoria hasta 2’96GiB, y decimos 2’96GB y no 4 ya que mas de 2’96GiB queda fuera de soporte, además de ser arriesgado.

Si quieres saber mas, continua leyendo aquí