Sorprendido me he quedado cuando he encontrado esta pequeña maravilla: el HDMI Dongle de Allways Innovating. Aunque está orientado al entorno doméstico/personal, la aplicación para entornos VDI me vino de inmediato a la cabeza. Primero veamos una imagen del juguete en cuestión:
Pues sí. Es justo lo que parece. Un dongle que conectamos a un monitor/televisor por HDMI, lo alimentamos por USB y.. ¡¡ voilá!!! todo un Android ICS (IceCream Sandwich) listo para funcionar. El juguete en cuestión viene equipado con lo siguiente:
Procesador Dual Cortex-A9 OMAP4, con velicidades de 1 a 1.8 Ghz
de 256 a 1 GB de RAM dependiendo del modelo
Almacenamiento MiniSD
SOporte Full HD y decodificación H.264
Wi-Fi 802.11 b/g/m, Bluetooth 2.1
Soporte NFC
Control de voz
Acelerómetro en el mando a distancia.
Las tripas del juguete nos muestran la simplicidad del dispositivo:
Y aquí el mando a distancia:
Nada más verlo, me imaginé conectándolo a mi televisor, asociando el teclado bluetooth y descargando el cliente PCoIP o ICA HDX.... el resto ya podéis imaginarlo.
Aquí os dejo un vídeo demostrativo de una demostración del juguete en cuestión en un televisor del hotel, hecha por Grègoire Gentil, CEO de la compañía.
Aparte del factor de forma, el uso de android como sistema operativo del thin client nos permite ofrecer un entorno autónomo, libre de licencias, sin plataforma de gestión propietaria y a un coste ridículo, a la vez que permitimos a nuestro usuario el uso de correo e internet (como poco) en su thin client (que sincronizará con su smartphone o tablet). Allways Innovating estima el coste entre los 50 y 80€, dependiendo de la configuración.
La portabilidad del mismo permite a los usuarios móviles acceder a su entorno profesional desde, por ejemplo, el televisor de un hotel.
Nunca he sido un fan de EMC. Siempre me pareció que esta
compañía, junto con otras, era el exponente de un almacenamiento sin término
medio: O excesivamente simple o extremadamente complejo. Adicionalmente, suelo
mirar con desconfianza las gamas de productos incompatibles entre sí, ya que
siempre me pareció todo un desperdicio tener que “jubilar” una unidad aún
usable porque cierta característica no estaba disponible. Si hay que migrar un
almacenamiento se migra… pero tener que migrarlo porque el actual no soporta
cierto tipo de disco o cierta característica me saca de quicio.
Por otro lado, el tema de los “añadidos” tampoco ayudaba a
tranquilizar mi conciencia (con el consiguiente impacto en mis merecidas noches
de descanso): Por un lado compras el disco puro y duro. Si quieres iSCSI, añade
tal modulito… si quieres CIFS, añade tal otro…. Si quieres deduplicar, ponle
tal appliance. Al final te das cuenta de que el módulo del CIFS no se entiende
con el de disco, sino que simplemente es un **ux + ***ba que usa la SAN como
dispositivo, sin más relación entre ellos que la que tiene un servidor Windows con
la SAN subyacente… con iSCSI, tres cuartas partes de lo mismo…. Lo que
significa que no hay integración real entre protocolos, sino que estos son
addendums colgados sobre un disco…. Un bug en la SAN y todo el edificio se cae.
La deduplicación es caso aparte, para peor…. Pones en medio
de tus servidores y el disco un cacharro que en tiempo real (en algunos casos)
deduplica o que de manera batch le da un repasón a la sopa de bits de la SAN
eliminando duplicidades. Pánico me da pensar qué pasa si el deduplicador falla
(fallo físico o un bug) o si la SAN lo hace… entre ambos dispositivos no hay
una relación íntima que de coherencia a todo el montaje. Por supuesto, esta es
la humilde opinión del que suscribe, totalmente discutible.
Filesystem vs RAW disk.
Que la SAN sólo entienda de RAIDs y que el dispositivo añadido
la use como tal plantea una dependencia que, a mi parecer, no es nada
tranquilizadora en entornos multiprotocolo. Son elementos no integrados en el
que uno de ellos (el añadido) tiene consciencia limitada del otro (La SAN) y el
otro ve al añadido como un cliente más al que servir disco. De ahí que las
soluciones basadas extremo a extremo en filesystem siempre me hayan parecido
más atractivas.
En el entorno filesystem la propia SAN gestiona el disco
como un sistema de ficheros, con todas las medidas de protección y corrección de
errores que un filesystem puede ofrecer, siendo consciente esta de todas las
operaciones que realizamos a nivel superior: Cuando ofrece LUNs, es la propia
SAN la que crea la LUN como un fichero en su filesystem y la que exporta vía
iSCSI o FC a los host conectados, controlando extremo a extremo (desde el
firmware del disco hasta las reservas SCSI) la comunicación. Cuando ofrece CIFS
o NFS, la propia SAN es la que habla ese idioma, coordinando todas las acciones
desde el cálculo de la paridad del RAID hasta el oplock CIFS. Cuando deduplica,
la SAN es consciente de la estructura y arquitectura del dato, de donde lo pone
y donde ha de ir a buscarlo.
Con esto no reniego de la SAN tradicional. Evidentemente hay
entornos donde el rendimiento es crucial y los IOPS son la única cuestión en
disputa. Nadie discute (salvo los PDF de
los fabricantes afectados) que la simplicidad (y gestionar bits y bites es más
sencillo que gestionar todo un filesystem) suele traducirse en rendimiento. Una
SAN tradicional suele requerir de menos mecanismos de mejora de rendimiento
(cachés, algoritmos de lectura, etc) que permiten volcarse en una única labor:
servir streams de datos vía FC o iSCSI, dejando los niveles superiores de
organización a los host. Evidentemente hay un modelo de SAN para cada
necesidad.
Vamos con VNX..
Tras la adquisición de Isilon, EMC presenta la series VNXe y
VNX, donde en boca de los analistas, unifica Clariion y Celerra, presentando un
producto dentro de la categoría denominada Almacenamiento Unificado. EMC presenta
el producto en tres versiones, cuyas diferencias se ilustra en la siguiente
tabla.
Como puede observarse, la serie VNX está orientada a cubrir
las necesidades de almacenamiento independientemente de los requerimientos de
tamaño o tecnología.
EMC se lo ha tomado en serio con VNX, ofreciendo un rango de
modelos que cubre desde lo más elemental (unidades departamentales y/o SMB)
hasta configuraciones multipetabyte.
Centrándonos en VNXe, además de las características
descritas, existen una serie de bundles de software que implementan
características avanzadas que compiten con el rey del almacenamiento unificado,
NetApp.
Al tajo..
Por aquí os dejo un par de vídeos disponibles sobre la configuración de la unidad.
El primero describe cómo configurar la unidad una vez instalada físicamente, mediante el uso de la utilidad "Connection nUtility"
Algo que resulta de agradecer es la configuración sin requerir acceso por consola. Así mismo, la posibilidad de guardar la configuración en un usb para aquellos dispositivos a los que no tengamos acceso a través del mismo segmento LAN supone una gran ventaja.
En segundo, veamos nuestro primer contacto con EMC Unisphere...
Para los acostumbrados a lidiar directamente con menús/CLI de configuración, el asistente de VNX puede parecer en extremo simple, pero salvo en la configuración de los pools (donde la VNXe impone sus criterios), resulta rápido y efectivo, guiando la entrada de los datos de configuración sin (casi) posibilidad de error.
Nótese la capacidad de configurar desde el asistente parámetros avanzados de los iSCSI targets y Servidores de ficheros como la interfaz que dedicamos e incluso la VLAN.
Una vez configurada, veamos uno de los aspectos más sorprendentes de la unidad: La capacidad de integrarse con los entornos que van a hacer uso del almacenamiento.
El siguiente vídeo muestra la asignación de almacenamiento a un entorno vSphere
La integración con vcenter resulta más que interesante a efectos de simplicidad de instalación y de configuración optimizada. Resulta interesante resaltar la posibilidad de decidir qué uso le daremos al datastore creado pudiendo permitir la creación o no de snapshots. Así mismo, la integración queda patente en la capacidad de la unidad para "ver" las VM que alberga.
Os invito a navegar por Youtube en la cantidad de vídeos demostrativos de las capacidades de la unidad (Buscad VNXe).
Mi impresión.
Rápida, sencilla, eficiente y BARATA! Una unidad VNXe3100 con doble controladora y el pack básico de software, equipada con doce discos SAS de 15K revoluciones ronda los 14K.
Rendimiento bajo iSCSI.
El rendimiento es fenomenal, incluso combinando cargas iSCSI y CIFS. Veeam machaca todos los días la infraestructura sin impacto aparente en el rendimiento. En procesos de clonado de VM, la unidad, con una sola interface por controladora dedicada a iSCSI, y la carga de producción, mueve del orden de 1GBytes por minuto, lo que nos da unos 230Mbit por segundo.
Rendimiento bajo CIFS.
También resulta impresionante, en especial cuando el acceso habitual de los usuarios coincide con procesos de copia (un backup con CA Arcserve y/o una copia sobre una unidad Iomega PX4.
Gestión.
La verdad es que para cualquier techie, la unidad es decepcionantemente simple de configurar (lo que supongo que tendrá sus consecuencias con el fine tunning, que por suerte no me ha tocado hacer). Respecto al CLI (Command Line Interface), parece que la unidad no lo ofrece directamente, sino a través de un aplicativo instalable en un equipo de gestión Windows o Linux (e incluso bajo ESX), el VNXe Unisphere CLI... no obstante, en las opciones de servicio, existe la posibilidad de activar ssh... no es que permita hacer demasiado, pero el banner de acceso es digno de verse. Otro aspecto sin duda sin desperdicio es como apagar la unidad (reproduzco literalmente):
"How to power cycle the VNXe system safely"
ID:
emc263167
Usage:
1
Date Created:
03/08/2011
Last Modified:
05/23/2011
STATUS:
Approved
Audience:
Customer
Knowledgebase Solution
Question:
How to power cycle the VNXe system safely
Environment:
Product: VNXe Series
Environment:
Product: VNXe3300
Environment:
Product: VNXe3100
Problem:
sp_power_cycle_dae
Problem:
sp_power_cycle_recovery
Problem:
Power cycle the system
Fix:
Power-cycle the entire VNXe system to attempt to resolve minor or moderate problems with the storage processors (SPs), I/O connections, disk-array enclosures, the system software, and other system components. Make sure that all system components are firmly seated in their proper position, and that all latches are closed and retaining screws are secure before you power cycle the system. This procedure involves placing the SPs in Service Mode. All hosts will lose access to the system. Ensure all host operations that require the VNXe system have completed to prevent data loss. Overview - This procedure involves doing the following in this order:
1.Place both SPs in Service Mode.
2.Disconnect the power cables from the power supplies on the disk-processor enclosure (DPE) to power down the SPs.
3.Disconnect the power cables from the power supplies on each disk-array enclosure (DAE) to power them down.
4.Reconnect the power cables to the power supplies on each DAE to power them up.
5.Reconnect the power cables to the power supplies on the DPE to power up the SPs.
6.Reboot each SP to return them to Normal Mode.
Prerequisites
Before performing this procedure, it is recommended that you disconnect all network shares and iSCSI virtual disks from each host to prevent data loss. Once the system is fully powered-up, you can reconnect the hosts to these storage resources.
Warning! Working with hardware may cause electrostatic discharge that could damage your hardware. Before working with any hardware, read the following VNXe online Help topic: "Precautions to follow before removing or replacing a component." Procedure
To power-cycle the entire system:
1.In Unisphere, click Settings > Service System.
2.Enter the Service password to access the Service System page.
3.Under System Components, expand Storage System.
4.Select the SP acting in the non-primary role. For assistance in determining which SP is primary and which is non-primary, see VNXe online Help topic "Determine a Storage Processor’s role" or reference Knowledgebase article emc265521. If your system has one SP, the name is SP A.
5.Under Service Actions, select Enter Service Mode.
6.Click Execute service action to place the SP in Service Mode.
7.In the confirmation dialog box, click OK. Do not perform any actions in Unisphere until this operation has completed.
8.Wait at least 10 minutes while the SP enters Service Mode.
9.Select the SP and the Mode field indicates that the SP is in Service Mode. By default, the Service System page will refresh every 60 seconds to display the current status and mode of the SP. Also, the Fault LED on the SP flashes amber and blue. For information about the LEDs, see VNXe online Help topic, LED indications. If your system has one SP, skip to step 15.
10.Under System Components, select the SP acting in the primary role.
11.Under Service Actions, select Enter Service Mode.
12.Select Execute service action to place the SP in Service Mode.
13.Wait at least 10 minutes while the SP enters Service Mode.
14.Select the SP and the Mode field indicates that the SP is in Service Mode.
15.Close your web browser to exit Unisphere. The next steps involve physically working with the VNXe system hardware. Optionally print this topic so that you can read the steps from a printed copy.
16.Disconnect the power cables from the DPE power supplies.
17.Wait at least 60 seconds to ensure each SP has fully powered-down. The green Power Status LED on each SP turns off.
18.Disconnect the power cables from the DAE power supplies.
19.Reconnect the power cables to each DAE power supply to power them up.
20.Reconnect the power cables to each DPE power supply to power up both SPs.
21.Wait at least 10 minutes while both SPs power up. The green Power Status LED on each SP turns on. The Fault LED on each SP flashes amber and blue to indicate that the SP is still in Service Mode.
22.Go to your computer and open a web browser.
23.Log in to Unisphere.
24.Enter the address for Unisphere. Because both SPs are in Service Mode, you can only log in with the Service password and only certain pages will be accessible.
25.Enter the Service password to log in to the Service System page.
26.Under System Components, expand Storage System.
27.Reboot SP A and wait 20 minutes for it to return to Normal Mode. When both SPs are in Service Mode, always return SP A to normal operation first, to avoid management software conflicts. Once SP A is operating normally, you can return SP B to normal operation.
28.Reboot SP B and wait 20 minutes for it to return to Normal Mode. For more information on rebooting an SP, see VNXe online help topic "Reboot a Storage Processor."
29.When both SPs are in Normal Mode, refresh your browser, or follow the on-screen instructions, to bring the system software out of Service Mode and restore Unisphere to full functionality.
30.Log in to Unisphere with your regular user account to gain access to all pages. If power-cycling the system does not fix the problem, go to the EMC Online Support website page for all support options. Also, see VNXe online help topic, "Getting assistance and information."
Como he dicho.... Sin desperdicio. !Procurad no tener que apagarla a menudo!
Resumen.
La serie VNX(e) es una buena compra, y un producto a evaluar tanto si tenéis necesidades de consolidación en oficinas remotas como en entornos centrales medios o grandes.
De la mano de Herminio Noguera Ruiz nos llega Openredes, un blog focalizado en networking Opensource, con una clara preferencia por Vyatta, un router basado en software que personalmente recomiendo. ¡¡Sin desperdicio!!
Si ha habido un producto disgresor y con una orientación
diametralmente opuesta a la de los “espadas” en esto de la virtualización del
desktop, ha sido Kaviza VDI in a Box.
En pocas palabras, frente a la necesidad de infraestructuras más o menos
pesadas que engloban las propuestas de fabricantes como Citrix, VMware y otros,
Kaviza apostó por la simplicidad.
Conocí kaviza de la mano de Guise Bule, uno de los grandes en esto de los virtual desktops, y de su compañia, tuCloud, que me invitaron a conocer y evaluar VDI in a Box cuando todavía era Kaviza. No sólo me invitaron a conocer el producto (cosa que jamás podré agradecer lo suficiente) sino a revisar su implementación como plataforma IaaS/DaaS en sus clientes, entre los que se cuenta el Laboratorio Nacional Lawrence Livermore (Lawrence Livermore National Laboratory), donde VDI in a Box gestiona un parque de más de 2000 desktops simultáneos que dan soporte a 5000 usuarios.
El producto se presentaba como un simple appliance virtual
que contenía todo lo necesario para echar a andar un entorno VDI clásico,
aportando la novedad de que no requería de infraestructura compartida. Por otro
lado, y bajo la filosofía de ¿para qué entrar en una guerra que es difícil
ganar?, llegaron a un acuerdo con Citrix para usar HDX como protocolo de
presentación de alto rendimiento, sin olvidar RDP para entornos menos exigentes
en lo que a presentación se refiere. Por otro lado, en lugar de apostar por
infraestructuras de virtualización centralizadas, heredadas de los entornos de
servidor y que el transcurso del tiempo ha demostrado que no siempre son
eficientes, Kaviza apostó por el VDI distribuído, donde para nada se hablaba de entornos
centralizados (tipo VMware View, Xendesktop o similares) sino en una malla de
infraestructuras independientes sincronizadas entre sí, con infraestructura de
bajo coste y sin tecnología compartida… básicamente algo en la filosofía del
desktop de usuario: máximo rendimiento al menor coste.
Kaviza fue adquirida por Citrix este año, dentro de la
impresionante campaña de adquisiciones de esta última, entre las que contamos,
además a Netviewer, EMS-Cortex, cloud.com, Ringcube y Sharefile.
Citrix ha renombrado el producto como Citrix VDI in a Box, y
lo ha posicionado en el tramo SMB, creando incluso una línea de negocio, donde
ha colocado a Krishna
Subramanian, anterior CCO de Kaviza, como responsable de la unidad.
Arquitectura de VDI-in-a-box.
A diferencia del resto de productos, VDI-in-a-box gestiona
hosts, no infraestructuras. Cada hypervisor dentro de un despliegue
VDI-in-a-box está gestionado individualmente por un appliance, que toma el
control del mismo y lo incorpora al Grid, unidad única de gestión del entorno.
Cada appliance gestiona y controla el hypervisor , integrando los recursos del
mismo dentro del conjunto de los hypervisores, asegurándose adicionalmente de
que ese hypervisor ofrece las VM, plantillas y configuraciones del conjunto de
la infraestructura. A este conjunto, VDI-in –a-box le llama Grid.
Despliegue típico de Citrix VDI in a Box
El grid es una entidad conjunta de gestión, por lo que no
importa en qué appliance configuremos qué parámetro o característica para que
todo el Grid quede configurado. Cuando definimos una imagen de un desktop, esta
es automáticamente replicada a los servidores miembros. Así mismo, el Grid es
tolerante a fallos, y no depende de ninguno de sus miembros para sobrevivir
(salvo, evidentemente, del último). Comparemos ahora con una estructura
tradicional que ofrezca el mismo nivel de tolerancia:
Despliegue típico VDI
Grid vs Entornos tradicionales.
Como observamos, los productos tradicionales requieren de
una total interrelación entre distintos subsistemas externos totalmente al
entorno VDI. Tradicionalmente, el bróker VDI no “habla” directamente con los
hypervisores (algunos, de hecho, no lo permiten), sino con la plataforma de
gestión de virtualización, que para alcanzar el entorno de redundancia
requerido, ha de usar productos de alta disponibilidad y/o almacenamiento
compartido (clásico cluster, que tampoco ofrece el nivel tolerancia requerido:
las bases de datos y la configuración siguen estando en un solo sitio). Así
mismo, es necesario cierto nivel de tolerancia en los brokers, ya sea mediante
su clusterizado o mediante la réplica de la base de datos.
Por otro lado, existe la dependencia del bróker respecto a
Directorio Activo. Si este no autentica a un usuario que intenta acceder a su
desktop, no hay credenciales cacheadas que valgan…. Aunque posteriormente el
desktop sí te deje acceder con ellas. También el uso mandatorio que algunos
brokers realizan de Active Directory incrementa la complejidad de los entornos,
especialmente aquellos donde AD no se usaba o donde sólo se usaba por las
capacidades de gestión del desktop (Despliegue o control con GPO’s), que dentro
del mundo VDI pueden no ser necesarias. Recordemos que Active Directory
requiere CAL (Client
Access Licenses)
Al gestionar una infraestructura común, el uso de
almacenamiento compartido es poco menos que mandatorio: Ya sea SAN o NAS, tanto
las templates, las imágenes y los propios desktops deben ser accesibles por
todos los hipervisores. Evidentemente un entorno tan crítico como el desktop
del usuario debe tener cierta protección en lo que al almacenamiento se refiere.
Todos estos elementos complican la gestión e incrementan los
costes, lo que a veces obliga a integrar el entorno VDI dentro de nuestro
entorno de virtualización de servidores, lo que no suele ser buena idea, como
apunté en la serie Repensando VDI
cuando hablé de, entre otras cosas, de los requerimientos de entrada/salida de
un entorno VDI.
VDI in a box, en resumen, opera en un modo muy similar a
active directory: Ningún servidor es imprescindible para el funcionamiento
del entorno, algo a mi parecer muy de
agradecer.
Gestión.
Otro de los aspectos diferenciales de VDI in a Box es la
capacidad de gestión. Al eliminar elementos compartidos, se elimina,
consecuentemente, su gestión. No hay SAN/NAS que gestionar (si quieres que no
la haya, claro), ni servidores de gestión de infraestructura virtual (vCenter,
SCVMM or XenCenter)… simplemente desktops y usuarios. Esto tiene capital
importancia cuando hay que delegar loa gestión del entorno VDI a personal no
familiarizado con la infraestructura virtual. Al no compartir más
infraestructura que la red, los administradores del entorno virtual como los
del almacenamiento no tienen que dedicar tiempo extra a la supervisión de la
infraestructura de escritorios. En pocas palabras, cada uno a lo suyo y en lo
suyo.
El viernes pasado Google presentó la beta de Chrome Remote
Desktop , un plug-in para chrome que permite acceder a la consola de un equipo
remoto desde otro sin necesidad de instalar un agente.
La versión actual requiere la presencia de un usuario a ambos
lados de la conexión, es decir, tando del equipo controlador como del
controlado. La conexión está autenticada por una clave de un solo uso que se
genera en el extremo controlado y que debe ser comunicada al usuario del extremo
controlador. Según indica Google, esta aplicación no es más que un demostrador
de tecnología que demuestra las capacidades de Chrome, pero no deja de parecer
un “aviso a navegantes”, especialmente después de probarlo y observar que el
rendimiento es superior a otras tecnologías de control remoto.
Para los más versados en las intimidades de desarrollo,
parece que este plugin se basa en una conexión P2P establecida con libjingle, combinado
con una implementación de PseudoTcp
en libjingle para proveer conexiones estables, todo sobre SSL. En lo referente
a la presentación, usa protobuf para datos estructurados y framing y los
gráficos con codificados mediante el formato VP8.
Independientemente de la tecnología, queda claro que Google
ha desplegado todo su arsenal de armas en Chrome para demostrar que lo suyo no
sólo es la nube.
La tecnología en sí no es nueva: Ericom, Citrix, Installfree
y ThinVNC (por nombrar algunos que ya disponen de cliente) ofrecen algo
similar. Otros, como VMware, están trabajando en ello. Lo curioso es que todas
estas compañías trabajan en cierta manera para el sistema operativo, por lo que
no es de extrañar que ofrezcan el producto. Sin embargo, Google, salvo por Android y Chrome OS, nunca se ha embarcado en este “percal”, fijando su objetivo claramente en la red... Entonces ¿A qué viene esto?
Por lo pronto, LogmeIN y Teamviewer ya tienen un competidor
a la altura (por mi experiencia, hasta superior), aunque no creo que la
intención de Google sea, precisamente, embarcarse en este mercado. ¿Estaremos a
las puertas de un Windows en la nube de mano de Google?
Tras un par de semanas peleándome con unos cuantos brokers de vDesktops que me han consumido hasta el extremo, volvemos con las aplicaciones virtuales.
Decíamos que la virtualización de aplicaciones mantiene una íntima relación con los entornos VDI, especialmente si requerimos que tanto las aplicaciones como los perfiles de usuario se independicen del sistema operativo del vDesktop con objeto de evitar personalizaciones que nos eviten reproducir en entorno virtual los problemas de los entornos físicos. Por otro lado, la necesidad de que el usuario acceda al software que necesita cuando lo necesita y donde lo necesita puede ser solventada sin necesidad de instalar todas las aplicaciones en la imagen maestra.
Como efecto colateral, y dependiendo del producto usado, podemos darle al usuario una versión "para llevar" de una aplicación y sus configuraciones; es decir, el usuario puede llevarse en un pen drive su outlook con su configuración o sus PST. Adicionalmente, virtualizar las aplicaciones en modo de aislamiento permite el movimiento de esta entre un entorno de desktop virtual y desktop físico.
En mi caso particular, y en el de más de un cliente, la coexistencia de múltiples entornos de trabajo (Desktop virtual, el irrenunciable desktop físico y el portátil), junto con la necesidad de instalación de aplicaciones no corporativas o de uso personal, la posibilidad de virtualizar, por ejemplo, Google Chrome (con sus capacidades offline) hacen de esta opción una manera fácil y simple de mantener para permitir desktops limpios de configuraciones y aplicaciones de usuario.
Profundizando, si ejecutamos la aplicación virtualizada en una unidad de red (y hemos configurado el VOS para que use la misma carpeta que el ejecutable), nos bastará un simple copy para mantener actualizado el VOS (que al fin y al cabo es lo que nos interesa) en un dispositivo extraible o nuestro portátil. Si usamos dropbox, podemos mantener nuestras vApps disponibles en cada uno de nuestros dispositivos.
En un entorno más corporativo, podemos usar ficheros sin conexión para el mismo fin.
Con un poco de trabajo (siempre digo que para eso nos pagan), podemos separar nuestro perfil, tanto de usuario como de aplicaciones), del PC que usamos.
Virtualizar las aplicaciones con productos como Cameyo puede ser una manera de reducir los costes de implementación de infraestructura de desktop virtual.
En mi particular caso, tengo versiones virtuales con Cameyo del vSphere client (un ENORME paquete con todas las versiones desde la 2.5 a la 5), putty (por esa mala costumbre de guardar los host en el registro que tiene este), Bitvse Tunnelier (lo uso cono "gateway" SSH). En el paso de el putty virtualizado, descansa en mi dropbox, con lo que consigo mantenerlo replicado entre todos mis desktops. Así mismo, y en otro escenario de aplicación quizá más mundano, mantengo una copia local de mi correo usando un Thunderbird virtualizado, que descarga periódicamente mis cuentas (profesionales y particulares) de Google (La nube mola, pero la nube con copia local mola más).
Os animo a probar Cameyo. Desde luego no es ThinApp.... pero da el tipo.
Para los que tenéis plantilla optimizada para VDI donde esté desactivado el firewall y Media Center, recordaros que es necesario que tanto el firewall (y los servicios de los que depende) estén en ejecución cuando instaléis el agente de desktop virtual de Kaviza.
Este se compone de dos elementos: Uno, el Agende VDI de Citrix y el propio de Kaviza.
El componente de Citrix requiere que el Firewall de Windows esté en ejecución, y el agente de Kaviza requiere que el componente Media Center esté instalado.
De no estar el firewall activado, la instalación del Agente VD de Citrix fallará, dando las habitualmente claras, concisas y nada extensas a las que Citrix nos tiene habituados.
