Entre ruedas y alas

Cambiar el Desktop Delivery Controller (DDC)

Cuando instalamos el cliente de VDA es necesario especificar de forma automática o manual, el DDC al que apuntará nuestro agente de XenDesktop.

En este post vamos a explicar como modificar de forma manual el DDC para incluir DDCs adicionales o para la modificación de los mismos.

Cabe tener en cuenta que el PATH dependerá de la arquitectura del sistema, y para ello, va a ser necesario, modificar el registro de Windows.

x32: HKEY_LOCAL_MACHINE\Software\Citrix\VirtualDesktopAgent\ListOfDDCs

x64:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Citrix\VirtualDesktopAgent\ListOfDDCs

Nota: no nos responsabilizamos del daño que pueda ocasionar-se de la modifcación del registro del sistema.

Unicamente es necesario incluir el FQDN o IP de los servidores DDC. Tras ello, reiniciar el agente VDA.

XenDesktop7: Gestión de Energia: PowerShell cmdlets

(ctxdom.com) Tal y como se explica en el manual de XenDesktop, por defecto, solo el 10% de escritorios esta levantado en horario pico en los Escritorio sin uso.

http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-control-power-management-rho.html

Esto puede suponer un problema (o no) y en caso de necesitar modificar-lo, como conprovareis, no disponeis de forma desde la GUI para realizar la modificación especifica. Así como lo hacemos? Vayamos a nuestro querido PowerShell.

Disponemos de dos características dentro del objeto de Catalogo que permiten la configuracion y comportamiento sobre el uso y administrador de Energia en XenDesktop.

El OffPeakBufferSizePercent y el PeakBufferSizePercent. Por defecto, ambos valores estan a 10%.

10% OffPeakBufferSizePercent: En los umbrales definidos como “fuera de horario pico” se establece que se deberá disponer de un 10% del total de escritorios del catalogo en estado “Running”.

10% PeakBufferSizePercent: En los umbrales definidos como “horario pico” se establece que se deberá disponer de un 10% del total de escritorios del catalogo en estado “Running”.

Para comprobar el estado de nuestro umbrales, podemos hacer uso del CMDLET:

Get-BrokerDesktopGroup -Name ‘CATALOG NAME’

Ello nos mostrará todos los objetos definidos en nuestro catalogo y su correspondiente valor. Podemos observar estas dos propiedades en el listado obtenido. Estas pueden ser modificadas de la siguiente forma (sin incluir %):

Set-BrokerDesktopGroup -Name ‘CATALOG NAME’ –OffPeakBufferSizePercent %NUM

Set-BrokerDesktopGroup -Name ‘CATALOG NAME’ –PeakBufferSizePercent %NUM

Adicionalmente, es importante tener en cuenta que hacen los Escritorios, tras la desconexion de los usuarios, o como actuan cada cierto tiempo en des-uso, tal y como vimos anteriormente en http://goo.gl/eiMVO0

Recursos:

XenDesktop eDocs Power Management: http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-control-power-management-rho.html

XenDesktop eDocs SDK cmdlets: http://support.citrix.com/proddocs/topic/xendesktop-7/cds-sdk-cmdlet-help.html

XenDesktop eDocs SDK cmdlets About Brocker PowerManagement: http://support.citrix.com/proddocs/topic/citrix-broker-admin-v2-xd7/about_broker_powermanagement-xd7.html

CTXDOM.COM Spanish Citrix Community: http://www.ctxdom.com

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”

Trabajando Logs de performance con Relog.exe

Relog.exe es una herramienta la cual nos permite trabajar sobre los ficheros .blg de contadores obtenidos mediante la heramienta de perfmon. Relog.exe crea nuevos logs de performance en base a un contador inicial pudiendo realizar varias tareas sobre el mismo, como acortar y/o convertir.

Podemos obtener la sintaxis completa de esta herramienta ejecutando desde CMD el siguiente comando:

rerelog.exe -?

Si se ejecuta obtenemos la siguiente salida:

Parameters:

<filename [filename …]> Performance file to relog.

Options:

-? Displays context sensitive help.

-a Append output to the existing binary file.

-c <path [path …]> Counters to filter from the input log.

-cf <filename> File listing performance counters to filter from the input log. Default is all counters in the original log file.

-f <CSV|TSV|BIN|SQL> Output file format.

-t <value> Only write every nth record into the output file. Default is to write every record.

-o Output file path or SQL database.

-b <dd/MM/yyyy H:mm:ss> Begin time for the first record to write into the output file.

-e <dd/MM/yyyy H:mm:ss> End time for the last record to write into the output file.

-config <filename> Settings file containing command options.

-q List performance counters in the input file.

-y Answer yes to all questions without prompting.

Veamos algunos ejemplos sobre lo que podemos hacer:

Convertir un Log: Convertir un Log nos permitirá ,por ejemplo, generar un CSV desde el blg original. Aunque el uso de blg es amigable para los administradores, puede ser necesario en muchas ocasiones trabajar en CSV sobre dichos ficheros. Este proceso es muy sencillo, simplemente ejecutamos:

Relog.exe FicheroLog.blg –f CSV –o NuevoNombre.CSV

Filtrar contadores determinados: Esta funcion es muy útil cuando se han sacado muchos contadores y solo queremos obtener y trabajar sobre un contador especifico. Imaginemos que queremos trabajar unicamente sobre los contadores de % tiempo de procesador. Podríamos generar un nuevo .blg con la siguiente linea de ejecución:

Relog FicheroLog.blg –c “\Processor(*)\%Processor Time” –o NuevoFichero_filtrado.blg

Este filtrado tambien podemos realizar-lo apoyados sobre un fichero txt con una lista de contadores concreta. El formato debe ser el siguiente:

\Memory\Pages/sec

\Hyper-V Hypervisor Virtual Processor(_Total)\% Guest Run Time

\Server\Logon Total

\PhysicalDisk(_Total)\% Idle Time

Un contador por cada linea. Y podemos ejecutar-lo de la siguiente forma:

Relog.exe FicheroLog.blg –cf ficheroContadores.txt –o NuevoFichero.blg

Filtrar un contador por tiempo: Este es el tipo de filtrado que mas utilizo. A menudo los clientes me envian contadores sin paradas durante varios dias. Ello implica un contador con poco detalle que abarca varios dias y con el que es sumamente dificil trabajar. Para estos casos, relog es la mejor herramienta, la cual nos permite seleccionar un periodo de tiempo del contador y generar un nuevo contador mas pequeño con la información necesaria. Para ello ejecutaremos:

Relog.exe fichero.blg –b “DD/MM/YYY HH:MM:SS” –e “DD/MM/YYY HH:MM:SS” –o nuevoFichero.blg

Input

—————-

File(s):

.\Performance Counter.blg (Binary)

Begin: 9/1/2014 13:11:24

End: 10/1/2014 13:11:22

Samples: 8641

100.00%

—————-

Output

—————-

File: PERFORMANCE_DAY1.blg

Begin: 9/1/2014 13:11:24

End: 9/1/2014 20:11:00

Samples: 2518

Consultar los contadores dentro de un blg. Relog nos permite obtener una lista de los contadores incluidos dentro de un fichero de perfomance sin la necesedida de abrir-lo. Ademas al sacar una lista, es facil exportar-la a un fichero para poder indicar-le al próximo cliente que contadores debe sacar ;). Para ello ejecutaremos:

Relog.exe –q fichero.blg

Filtar Registros según valor: Adicionalmente, sobre todo el procesamiento, podemos incluir el modificador –t<valor> el cual nos permite filtrar el contador BLG sobre cada x registro. Es decir, si disponemos de un contador que cada 10 sec. tenemos un registro del contador obtenido cada 10 sec.

Registro1 -> 10segundos despues -> Registro2 -> 10segundos despues -> Registro3 -> 10segundos despues -> Nregistro (…)

Este parametro (-t) nos permite escoger cada cuantos registros incluimos en el nuevo fichero. Es decir, si ponemos –t 2 diremos que obtenga unicamente 1 registro cada 2. Así pues obtendriamos:

Registro1(incluido) – Registro2(descartado) – Registro3(incluido).

De este modo simplificamos y reducimos el fichero blg para su uso, aunque tambien reducimos el detalle global del contador.

Tips: Ten en cuenta que todos los tipos de filtrajes pueden ser mezclados, asi pues podemos acortar en el tiempo un blg al mismo tiempo que seleccionamos contadores especificos y lo convertimos en CSV. ¿Fácil no?

Resources: http://technet.microsoft.com/en-us/library/bb490958.aspx

Error VDI (FAILURE 46) al arrancar nuestra VM

enero 27th, 2014 | Posted by cristiansan in CLI | ctxdom | TroubleShooting | XenServer - (0 Comments)

Tras un reinicio del HOST nos encontramos con alguna VM que no consigue arrancar. Al realizar el Start de la misma, aparece un error en la pestaña de Logs que indica que el VDI de la VM no esta disponible.

Este es un error conocido, que tiene fácil solución. Por desgracia el log de la pestaña de XenCenter no da mucha información útil, así que mi recomendación es ir siempre al CLI y ejecutar desde allí el comando.

xe vm-start uuid=UUID_VM

dando como resultado:

Error code: SR_BACKEND_FAILURE_46

Error parameters: , The VDI is not available [opterr=Error scanning VDI UUID=XXXXX]

Por alguna razón el VDI de la VM en cuestión no esta disponible. La solución es muy sencilla:

Primero de todo, vamos a localizar el disco de la VM afectada, para ello ejecutaremos:

xe vdi-list name-label=NOMBRE\ VM\ AFECTADA

Esto nos mostrará el uuid de los VDI que tiene asignada la VM en cuestión. Es importante también localizar en que SR esta dicho disco.

Tras ello, vamos a quitar dicho disco “fantasma” de la VM dónde se encuentra asignado, para ello ejecutaremos:

xe vdi-forget uuid=UUID\ VM\ COMANDO_ANTERIOR

Ello, quitará el disco con UUID de la VM asignada. Tras ello, realizaremos un Re-scan de los SR. Podemos realizar-lo desde la consola XenCenter o desde la CLI.

xe sr-scan

Una vez finalizado el proceso, incluimos de nuevo el disco sobre la VM. Desde XenCenter con la opción de atach y seleccionando el correspondiente disco de la VM (tengo la costumbre de dar nomenclatura especifica a cada disco aprovisionado para que sea mas fácil su localización por nombre, no es una mala practica 😉 )

También podéis realizar-lo desde cli, por supuesto 😉

Una vez finalizado, simplemente, arrancad la VM.

Cambiar el Desktop Delivery Controller (DDC)

XenDesktop7: Gestión de Energia: PowerShell cmdlets

Migraciones de un Pool de XenServer a 6.2

No aparecen contadores XD en los dispositivos VDA

Trabajando Logs de performance con Relog.exe

Error VDI (FAILURE 46) al arrancar nuestra VM

Meta

Categorías