Welcome to Delicate template
Header
Just another WordPress site
Header

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»

WPShell1

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

Add-PSSnapin Citrix.XenApp.Commands

Los modulos cargados en el proceso són:

WPShell2

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»
}

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í

Veamos la versión actual de python en XS6.2

[root@xenserver62 ~]# python -V

Python 2.4.3

Vamos a utilizar YUM en primer momento, para instalar todos los paquetes necesarios para la instalación de Python3.

NOTA: Si al realizar un yum update aparece un error referente al repositorio de Citrix 6.2

* Deshabilitar el repositorio Citrix.Repo

* Habilitar el repositorio CentOS-base Repo

Sobre esto hable hace tiempo en el siguiente link: http://blogs.itpro.es/cristiansan/2012/05/23/xenserver-trick-linux-repository/

Instalando Requerimientos

Habilitados los repositorios. Procedemos a instalar Make y el compilador GCC.

Install Make.

# sudo yum install make

Install GCC

# sudo yum install gcc

Descargamos e instalamos Python3

Para ello, desde nuestra linea de comandos, ejecutamos:

wget http://www.python.org/ftp/python/3.3.2/Python-3.3.2.tgz

tar xf Python-3.3.2.tgz

cd Python-3.3.2/

./configure –prefix=/usr/local

make && make altinstall

ahora ya podemos ejecutar python3.3 sin problemas.

[root@xenserver62 bin]# python3.3
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

NOTA: Si ejecutamos python seguimos en versión 2.4.3

NOTA: No se recomienda el cambio del link symbolico, pues muchos programas realizados en Python apuntan a «python» como enlace de Python2. Modificar-lo puede suponer un problema para scripts que necesiten de python2.

TRICK: Para simpliciar las cosas, podemos crear un link simbólico “py” para ejecutar python3.

 # ln /usr/local/bin/python3.3 /usr/bin/py

De este modo, al ejecutar py, estaremos ejecutando python 3.3

[root@xenserver62 bin]# py -V
Python 3.3.2
[root@xenserver62 bin]# py
Python 3.3.2 (default, Jul 10 2013, 16:22:51)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux
Type «help», «copyright», «credits» or «license» for more information.
>>>

Y con esto, y un biscocho,  ya tenemos Python 3 en nuestro querido XenServer 6.2. 😉

En algunos entornos (laboratorios, servidores StandAlone, etc) disponer de una maquina para almacenar los repositorios ISO que compartimos en nuestro XenServer puede suponer un gasto de recursos adicionales que nos podriamos ahorrar.

En este breve artículo os enseñamos como crear vuestro propio repositorio local en XenServer que permita almacenar y utilizar ISO.

Tened en cuenta que utilizar un SR local hace que este repositorio no este disponible para el resto de host que componen un pool. Si dispones de un pool y quieres que estas ISO estén disponibles para todos los host, recuerda utilizar un recurso compartido como almacen.

Los pasos aquí indicados te ayudarán a crear un SR de ISOs Local y las propias ISO solo estarán disponibles únicamente sobre la máquina que almacena dichas imágenes.

Quieres saber como… continua leyendo aquí

Algunas veces existen quejas referentes al performance de red en entornos virtuales y su mal performance de red en relación a una maquina física. Articulos independientes muestran que el performance con xenserver, vmware e hyper-v es parecido al físico y ya no es una excusa para no virtualizar. Eso si, para ello, es necesario realizar ciertas acciones y aplicar todas las buenas practicas posibles en cada uno de los entornos siempre que sea posible.

Una de las mejoras realizables para mejorar el performance de red, es el relacionado con los paramétros de checksum y off-load (TCP Segmentation offload, Generic Segmentation offload y UDP Fragmentation Offload – Todas ellas explicadas en los recursos adicionales al final del artículo).

Para su configuración, podemos hacer uso de la herramienta ethtool-K, el cual nos permitirá realizar cambios sobre las tarjetas, sin que los cambios sean “permanentes”. Estos serán reseteados tras un reinicio.

Para ver los parámetros actuales podemos consultar-los de la siguiente forma:

ethtool –K “Interface”

Por ejemplo, podemos deshabilitar el tcp-offload de la Eth0 de la siguiente manera:

ethtool -K eth0 tso off

Para información ampliada sobre ethtool podemos consultar el manual en línea (man) de ethtool o desde http://linux.die.net/man/8/ethtool

Para establecer los cambios de forma permanente, deberemos utilizar nuestra herramienta en línea de comandos XE. Para ello, realizaremos:

xe pif-param-set uuid=<UUID of PIF> other-config:ethtool-tx=”off”

xe vif-param-set uuid=<UUID of VIF> other-config:ethtool-tso=”off”

La sintaxis genérica seria:

   xe [vif/pif]-param-set uuid=<uuid pif/vif> other-Config:KEY=”off”/”on”

dónde KEY:

ethtool-tx : TX Checksum

         ethtool-rx: RX Checksum

         ethtool-tso: Tcp Segmentation offload

ethtool-ufo:  UDP Fragmentation offload

ethtool-gso: Generic Segmentation offload

NOTA: no se recomienda la desactivación del TSO en los VIF. Las buenas practicas aconsejan desactivar la misma desde la propia VM, tal y como indica el http://support.microsoft.com/kb/904946/  y http://support.microsoft.com/kb/951037

NOTA: Ojo al aplicar en entornos productivos. Testear antes.

Resources:

TSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/tso

GSO: http://www.linuxfoundation.org/collaborate/workgroups/networking/gso

UFO: http://www.linuxfoundation.org/collaborate/workgroups/networking/ufo

 

Una vez establecido la URL de StoreFront, si no se establecio inicialmente con Https no es posible realizar la modificación desde la consola.

Para modificar-lo deberemos tirar de PowerShell.

Y como lo hacemos. Veamos-lo.

Requerimientos:

  • Correr PowerShell como Administrador y como Unrestricted

Se asume que el Administrador, ha creado un enlace HTTPS en IIS y que ha sido generado e instalado el correcto certificado para el Site.

1

Continua leyendo aquí