Hola soy Miguel Ángel Alonso, y aquí estoy como cada martes con vosotros para contarte algún nuevo tema sobre el maravilloso mundo de la virtualización.

En el Post de hoy voy hablar sobre el uso de TAGS (Etiquetas) dentro de nuestros entornos VMware View.

Con la entrada al mercado de VMware View 4, se introdujo la función de etiquetado (Asignación de TAGS) para permitir especificar el acceso a un grupo, o grupos de usuarios a los pool de escritorios de nuestro entorno corporativo, diferenciando a estos por el tipo de conexión WAN o LAN en pools internos y pool externos.

Existen unos pequeños puntos a tener en cuenta antes de usar la función de TAGS en tu entorno, y que voy a comentarte en las siguientes líneas como las más importantes premisas a tener en cuenta:

1. Los TAGS son exclusivos de los Connection Server y no son aplicables a nuestros Security Servers.
2. Cualquier Security Server que tengas en modo Paired (emparejado) con un Connection Server, trabajará exactamente igual que dicho Connection Server.
3. Si tienes un balanceador de carga delante de tu grupo de Security Servers o Connection Servers, deberán ser etiquetados exactamente de la misma manera.
4. Un solo Connection Server o pool podrían tener múltiples etiquetados (TAGS)
5. Los pools de escritorios que no tengan asociado ningún TAG, podrán ser accedidos por los usuarios con permisos necesarios, a través de cualquier Connection Server.
6. El Connection Server que no tenga TAGS, podrá solo acceder a los pools de escritorios que no tengan ningún TAG
7. Los TAGS tienen la prioridad más alta a a la hora de asociar (entitlement) los pools

Esta función me resulta muy beneficiosa y creo que en general a todo el mundo que dispone de VMware View en cualquiera de sus versiones 4.X, ya que de esta manera podrás asignar servidores de tu organización a tareas diferentes como son las conexiones externas (Usuarios Móviles) o las internas de dentro de la compañía.

No olvides que puedes asignar TAGS de internal y external a un mismo Connection Server si lo requieres de este modo por las necesidades de tu propio negocio.?

Estos son los 4 pasos que hay que dar apara asignar TAGS a tu entorno de VMware View:

Ves a la consola de tu Broker y en el apartado: View Configuration>> Servers, elige el servidor al cual le vas a asignar los TAGS. Luego pulsa sobre la opción Edit.

Una vez pulsado Edit, te aparece una pantalla donde te dará la opción de añadir tus TAGS a tu Connection Server. En mi caso, y como se ve a simple vista, he elegido INTERNAL.

Seguidamente, ves a la sección: Inventory>>Pools y pulsa nuevamente sobre la opción Edit.

Te aparecerá esta pantalla desde la consola de tu Broker y sobre la pestaña de configuración: Pool Settings >> Browse podrás acceder a la opción final que te permitirá asociar dicho pool al TAG del Broker que previamente he configurado.

Finalmente, elige el TAG adecuado a las necesidades de tu entorno VMware View.

Bueno, hasta aquí por hoy. Espero que te haya resultado de alguna utilidad y me despido de ti hasta la semana que viene con un nuevo tema sobre la virtualización.

Hasta la semana que viene.

Ya esta disponible online el episodio #12 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en español.

Virtualizacion.TV es nuevo programa de televisión web que ayuda a profesionales y usuarios de la virtualizacion de sistemas como tú, a virtualizar el centro de datos y no morir en el intento.

Esta semana tenemos una gran lección de HP, compartire un documento excelente de VMware vSphere pare resolver problemas avanzados, contestare a una gran pregunta de un usuario relacionada con las latencias de FC .vs iSCSI en entornos SAN y descubriremos el nuevo cliente de VMware vSphere virtualizado.

Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, hazlo ahora en virtualizacion.tv. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.

¿Y tú, qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Crees que la latencia es un factor lo suficientemente crítico en este caso como para desechar la opción de iSCSI frente a FC? Deja tu comentario en virtualizacion.tv o charlemos sobre ello en twitter.

Hola amigos, soy Florián Murillo. Antes de nada quiero agradecer que me hayáis acompañado por este camino hacia el “futuro” con vuestros comentarios y opiniones.

En este último capítulo quiero hacer hincapié en los 10 puntos claves para no morir en cualquier pasillo frío de algún datacenter:

1. Implanta plataformas de gestión orientadas al coste de la infraestructura: CAPEX y OPEX. Mide lo que cuesta mantener el datacenter encendido. Tu objetivo es disminuir los costes continuamente, no solo en la foto inicial. Los triunfos puntuales duran poco en la memoria.
2. Automatiza. Después sigue automatizando y cuando lo hayas automatizado todo, continua automatizando.
3. Mide la capacidad de tu datacenter. Anticípate a las necesidades de crecimiento o morirás con el negocio.
4. Forma a tu equipo. Transfórmalos en expertos multidisciplinares en las tecnologías involucradas en la evolución al cloud y estimula y gestiona el potencial de ideas que pueden generar. Es el activo mas importante del equipo de TI.
5. Educa al negocio en los beneficios del cambio. Convence a la dirección, a los departamentos, a los clientes, ellos no saben lo importante que es para el negocio hacerte caso… Aprende a conquistar sus corazones, es decir dinero, medio ambiente y responsabilidad social.
6. Crea un clima de seguridad alrededor de los cambios. El miedo a los cambios genera inseguridad.
7. Revisa todos los procedimientos de TI. Nuevos paradigmas requieren nuevos procedimientos.
8. Revisa las plataformas de desarrollo existentes. Integra SOA y REST en tu middleware corporativo para la comunicación entre sistemas.
9. No corras. Los cambios han de llegar de forma natural, la gravedad es la fuerza que rige el mundo, y es gratis!!!! de todas maneras, no dejes de caminar.
10. Cuidado con las tecnologías elegidas. Entramos en terrenos con sobredosis de marketing y productos inmaduros, no quieras ir más deprisa que la tecnología.

Bueno amigos, si creíais que vuestro trabajo es bonito, os equivocáis, es maravilloso.

La mayoría de nosotros estamos más o menos acostumbrados a oír hablar de soluciones de backup para entornos virtuales, del tipo Veeam Backup & Replicator para VMware o Altaro para Hyper-V, comentada en un post anterior no hace mucho por mi compañero Miguel Ángel Alonso.

Estas soluciones son espectaculares y funcionan de maravilla en general, pero suelen tener un “pequeño” problema asociado, su coste. Como consultor experto en virtualización me tengo que enfrentar a proyectos tanto para grandes empresas como para pequeñas, y en este último caso, cuando llega la parte del backup se suele plantear un problema con el tema de los costes.

En esta ocasión no voy a hacer ningún análisis de ninguna herramienta comercial, sino que he decidido compartir con vosotros un pequeño proyecto personal que estoy llevando a cabo, una solución de backups gratiuta basada en scripts.

Este pequeño grupo de scripts permite realizar backups en caliente de una lista de máquinas virtuales, comprimirlos, almacenar una copia en el datastore local, enviar el backup a un repositorio remoto FTP y enviar una alerta mediante correo electrónico del proceso del backup.

El script está escrito para PowerShell y depende de tener activado el “RemoteTechSupport (SSH)” en nuestro ESXi y por supuesto de un servidor FTP donde almacenar las copias.

La configuración del script se realiza ajustando algunos parámetros dentro del propio script y creando un par de ficheros previos. A continuación, os pongo los pasos necesarios para poder hacer uso del script en vuestra infraestructura:

1. Editar el fichero Crear-VMBackup.ps1 y modificar las siguientes variables:

$PLINK = “C:\bin\PLINK.EXE” #Ubicación del programa Plink.exe usado para la inyección de comandos en el servidor ESXi
$DataStore = “” #Datastore que será usado para almacenar el backup local
$tmpDir = “C:\tmp” #Directorio temporal usado para general los scripts temporales que será inyectados en los comandos plink y ftp
$emailFromDir = “” #Direccion email del remitente
$emailToDir = “” #Dirección email del destinatario
$smtpServer = “” #Servidor SMTP que va a ser usado para enviar el informe final
$smtpUser = “” #Usuario de conexión al servidor de SMTP en caso de que requiera autenticación
$stmpPassword = “” #contraseña para la autenticación con el servidor SMTP, en caso necesario

2. El script trata en todo momento de trabajar de la forma más segura con las credenciales de acceso a los servidores, tanto ESXi como FTP. Para ello hace uso de unos cmdlets creados por Hal Rottemberg que permiten almacenar credenciales encriptadas y en formato xml. Para poder crear estos ficheros tendremos que hacer lo siguiente:

• Importar la librería de autenticación de Hal: PS1> . .\Crear-VMBackup.ps1 El propio script ya hace la importación de la librería de Hal PS1>Export-PSCredential –Path creds.xml Después de esto nos aparecerá una venta pidiendo usuario y contraseña. Estos datos se almacenarán en el fichero creds.xml que hemos especificado y que posteriormente usaremos para ejecutar el script de backup. Este paso hay que hacerlo solo una vez por cada credencial que vayamos a usar y es necesario indicar ficheros diferentes para credenciales distintas.

3. Crear un fichero de texto plano con el listado de máquinas virtuales a las que queremos hacerles el backup. Un nombre de máquina virtual por línea, tal y como aparece en el vSphere Client.

4. Ejecutar el script de backup:

PS1>Crear-VMBackup -VIServer 192.168.1.100 -ServerCred (Import-PSCredential -Path .\esx.enc.xml) -vmlist .\vmlist.txt) -BackupPath “192.168.2.30/backups” -BackupCred (Import-PSCredential -Path .\backup.enc.xml))

En este caso particular los parametros significa:

• VIServer: Servidor ESXi. En nuestro caso 192.168.1.100 (también podemos indicar el nombre dns del servidor)
• ServerCred: Credenciales de acceso al servidor ESXi. En este caso las credenciales se obtienen del fichero esx.enc.xml ubicado en el mismo directorio donde se ejecuta este script.
• BackupPath: Indica tanto el servidor FTP donde se va a almacenar el backup, (192.168.2.30 en nuestro caso) como la ruta dentro del servidor (“backups” en nuestro caso)
• BackupCred: Credenciales de acceso al servidor FTP donde se va almacenar el backup. En este caso se obtienen del fichero backup.enc.xml

Existen otras soluciones de backup gratuitas como pueda ser ghettoVCB, en la que me he inspirado para crear este script. Sin embargo, estas soluciones tienen una pega importante, y es que dependen de una licencia ESXi no free para poder sacar los backups fuera del servidor ESXi.

Este script no necesita de una licencia no free para funcionar, ya que hace uso de comandos internos de ESXi para enviar por ftp el backup y de plink para inyectar aquellos comandos que por limitaciones de licencia no pueden usarse de forma remota.

El script está en constante desarrollo, por lo que está aún tiene fallos y faltan funcionalidades que quisiera ir implementando poco a poco, por lo que cualquier sugerencia o comentario será siempre bienvenido.

Update: Puedes descargar el script en este enlace.

StarWind Software es el líder global de administración de bases de almacenamiento y desarrollo de software de SAN para pequeñas y medianas empresas.

El ejemplo más representativo de productos de StarWind es el software de SAN que convierte cualquier servidor estándar de Windows en una SAN iSCSI segura y tolerante a fallos. El programa está diseñado para su uso como almacenamiento en una red con VMware, Hyper-V, Microsoft SQL Server, Microsoft Exchange, Microsoft SharePoint y otras aplicaciones de servidor que se configuran en los clústeres de servidor.

La compañía StarWind Software está orientada a las pequeñas y medianas empresas ofreciéndoles la tecnología barata de alta disponibilidad que hace poco solamente estaba disponible en los productos prestigiosos y caros de almacenamiento.

Las características avanzadas de sus productos incluyen creación de espejos síncronos con tolerancia a fallos y recuperación automática, replicación remota en una WAN, protección continua de datos y puntos de recuperación, thin provisioning y administración de cintas virtuales.

En el año 2003 StarWind lanza su primer programa de SAN iSCSI convirtiéndose en el producto favorito para más de 30.000 usuarios de todo el mundo en más de 100 países, desde pequeñas y medianas empresas, hasta gobiernos y compañías de Fortune 1000.

Aprenda más sobre las soluciones de productos StarWind registrándose en nuestros seminarios web gratuitos:

Hola de nuevo, soy Miguel Ángel Alonso y aquí estoy como cada martes para contaros algo nuevo sobre el maravilloso mundo de la virtualización.

Hoy nos centraremos en como instalar un certificado en nuestro entorno VMware View para poder utilizarlo en nuestras conexiones WAN, y así de esta manera poder cifrar nuestros datos de conexión.

Lo primero de todo, tendrás que ir a las propiedades del equipo de tu servidor Broker en “Configuración avanzada del Sistema” – “Opciones Avanzadas” – “Variables del entorno”, para seleccionar el campo llamado “Path” y añadir el siguiente path:

C:\Program Files\VMware\VMware View\server\jre\bin

El segundo paso a seguir en tu servidor Broker o connection server, es abrir una sesión desde la línea de comandos con “cmd” y asegurarte que estas en el irectorio raíz “C:”. Después, escribe la siguiente línea de comandos:

Keytool –genkey –keyalg “RSA” –keystore keys.p12 –storetype pkcs12 –validity 360

Esta linea de comando, generará una clave privada llamada keys.p12 en algoritmo RSA usando el formato PKCS12 y válida por un año: Tendrás que rellenar los datos de formulario que te pide, como por ejemplo, nombre FQDN de tu organización, Ciudad, País y etcétera.

En el siguiente paso, crearas un archivo de requerimiento de certificado, el famoso CSR, para ser enviado a la CA correspondiente, tanto sea de tu entorno Microsoft si es que dispones de ella como si es un CA correspondiente a una de las autorizadas en Internet y conocidas, como por ejemplo, THAWTE, GLOBALSIGN o VERISIGN.

El comando para generar el archivo CSR es el siguiente:

Keytool –certreq –keyalg “RSA” –file micertificado.csr -keystore keys.p12 -storetype pkcs12 -storepass p@sswOrd

Donde micertificado.csr será el nombre de tu ”csr” y p@sswOrd, será la contraseña que utilices para tu certificado.

Una vez hecho todo esto, nos generará el archivo .csr el cual como he indicado antes deberás enviar a la entidad de certificados CA que hayamos elegido.

En mi caso será una CA interna de Microsoft Windows 2008 y la cual dispongo dentro de mi entorno de laboratorio. Nos conectamos mediante http://servidorCA/certsrv

Entonces, eliges la opción de enviar una solicitud de certificado con un archivo codificado en base64 CMC o PKCS#10, o una solicitud de renovación con un archivo codificado en base64 PKCS#7, donde en “plantilla de certificado” pondrás “Servidor Web” y “pegaras” el archivo csr que he generado anteriormente en formato texto.

Luego, descarga los archivos por defecto Certnew.crt y Certnew.p7b (obligatorio en formato pkcs#7) a tu direcrorio raíz C:

Vuelve a la línea de comando para importar tu root CA y teclea el siguiente comando:

Keytool –import –trustcacerts -keystore “C:\Program Files\VMware\VMware View\jre\lib\security\cacerts” -storepass changeit –alias Root -import -file c:\Certnew.crt

Después, importa tu archivo Certnew.p7b (formato pkcs#7) mediante la siguiente línea de comando:

Keytool -import -keystore keys.p12 -storetype pkcs12 -storepass p@asswOrd -keyalg “RSA” -trustcacerts -file Certnew.p7b

Te preguntará si confías en este certificado: por supuesto le dices que sí.

Como últimos pasos, lo que harás será ir a tu Security Server y en el directorio: C:\Program Files\VMware\ViewManager\Server\sslgateway\conf modificas, o creas sino dispones de este, un archivo llamado Locked.properties. Ánade las dos lineas siguieres:

Keyfile=keys.p12
Keypass=p@sswOrd

Seguidamente, y en ese mismo directorio, importa la clave keys.p12 que generaste en tu servidor Broker anteriormente, y reinicia el sevicio View Security Service con los siguientes comandos:

Net stop VMware View Security Server
Net start VMware View Security Server

Como nota final, recuerda que el archivo locked.properties y la importación de la clave privada keys.p12 deberías hacerlo en todos tus Security Server.

Bueno, hasta aquí por hoy. Espero haberos contado algo de vuestro agrado y me despido de vosotros hasta la semana que viene. Os emplazo hasta el próximo martes con un nuevo tema sobre la virtualización.

Ya esta disponible online el episodio #11 en virtualizacion.tv, el programa de televisión web que ayuda a profesionales como tú, a entender la virtualización de sistemas y el cloud computing en español.

Virtualizacion.TV es nuevo programa de televisión web que ayuda a profesionales y usuarios de la virtualizacion de sistemas como tú, a virtualizar el centro de datos y no morir en el intento.

Esta semana tenemos una gran lección de la ciudad de Boston, hablaremos del nuevo Amazon EC2 VM Importer pluging para VMware vSphere, contestaremos a una gran pregunta de un usuario relacionada con el uso de VMware en entornos SAN y descubriremos una utilidad increíble de Vkernel que te ayudara a analizar y detectar cuellos de botella en tu entorno virtual.

Gracias a todos los que dejaron su comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, hazlo ahora en virtualizacion.tv. Tu apoyo permitirá que este programa de televisión web sobre la virtualización de sistemas y el cloud computing en español, pueda continuar beneficiando a muchas personas.

¿Y tú, qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Crees que estamos preparados y que hay herramientas para poder exportar e importar máquinas virtuales de un proveedor de cloud computing a otro? Deja tu comentario abajo en este video en virtualizacion.tv o charlemos sobre ello en twitter.

Hola amigos, soy Florián Murillo. La semana pasada acabamos construyendo un cloud privado para atender las demandas crecientes de servicios nuevos; nos basamos en una capa de gestión y, por debajo, varios “motores” que convertían nuestro VDC en una nube privada. Los podemos resumir en:

a. IP Address Management (IPAM).
b. Equipamiento con una arquitectura pensada para ser aprovisionada automáticamente.
c. Un motor de automatización para unir todas las piezas del puzzle.
d. Herramientas de balanceo a varios niveles.
e. Un mecanismo de gestión de identidades y acceso.

Los beneficios para el negocio son importantes:

• El mismo equipo de TI es capaz de administrar una infraestructura mucho mas grande, la cual empezó a crecer al entrar en el mundo de la virtualización gracias a la libertad de despliegue que nos ofrece.
• Los automatismos nos garantizan la fiabilidad de los procesos, por tanto menos errores.
• Los automatismos también nos garantizan el cumplimiento normativo que está implícito en los procesos automatizados, por tanto no hay que prepararse para las auditorías. Quien ha participado en alguna sabe el coste “energético” que suponen al equipo de TI.
• La tecnología se adapta a las necesidades del negocio. Es capaz de absorber picos aprovisionando nuevas máquinas virtuales o aprovisionar servicios nuevos en minutos.
• Establece un mecanismo standard de comunicación entre aplicaciones incompatibles, a través de SOA, XLM y REST. Integrando datos de la aplicación A en la aplicación B, incluso si son aplicaciones que se encuentran en “otras nubes”.

Una característica del cambio es que necesitamos mas especialistas de nivel 2 que técnicos de nivel 1, ya que mucho de su trabajo se ha automatizado invirtiendo la pirámide de personal existente en los departamentos de TI y esto sí es un reto organizativo.

Podríamos concluir que hemos rentabilizado las TI a cambio de sofisticarlas, con múltiples capas de tecnologías nuevas.

Pero hemos conseguido una cosa importante: Hemos dado la vuelta a una forma de hacer TI en la empresa. No ha sido fácil. Hemos tenido que demostrar paso a paso la validez de nuestros argumentos tecnológicos con rentabilidad y mejora permanente del negocio. Hemos cambiado la forma de ver las TI en muchas empresas y solo así podemos llegar hasta aquí.

Ahora nos queda el siguiente paso: extender nuestra nube privada con un “trozo” de nube pública. Probablemente empezaremos con alguna aplicación en modalidad SaaS, como Salesforce, que se integrará con nuestras aplicaciones gracias a nuestra experiencia en SOA, XML y REST.

Quizás sigamos llevando nuevos desarrollos en .NET, Java o Ruby a la red y, poco a poco, crearemos nuestra red híbrida formada por una parte privada y una parte pública.

Para que extendamos nuestra nube privada con éxito necesitamos extender nuestros procesos de control y seguridad hasta la nube pública. Algunos proveedores de nubes públicas ya están preparados para adaptarse ¿lo estamos nosotros?

Pero la pregunta es ¿por qué he de cambiar y ampliar mi nube privada y hacerla híbrida?

Es un tema sencillo: rentabilidad económica. El coste de una máquina virtual en una nube pública es aproximadamente un 20% del coste que supone esa misma máquina virtual en una nube privada. Probablemente extender nuestra nube no sea una necesidad de TI, es mas bien una necesidad del negocio. Es fácil de entender que tarde o temprano

extenderemos nuestra nube. La gráfica siguiente ilustra el escenario que describimos:
Esto abre un escenario interesante. Si la rentabilidad la quiero llevar al límite ¿puedo migrar todo mi VDC a la nube pública? La respuesta es SI. No es un proyecto simple porque hay tecnologías complejas por el medio pero si que es posible.

¿Puedo ir a la nube pública sin pasar por una nube privada? Hay empresas que integran aplicaciones SaaS con su arquitectura tradicional pero esto no es estar “in the cloud”.

Pasar directamente a la nube pública, sin pasar por la nube privada, es factible pero hay mas aspectos a gestionar. Hemos de cambiar mentalidad, cultura, organización y tecnología de golpe, cuanto menor es el tamaño de la empresa y mayor la influencia de los responsables de TI en el negocio mas fácil resulta.

Además parece que todas las tendencias confluyen generando sinergias. Las estrategias de Cloud Computing, Arquitectura Empresarial, Empresa 2.0 y Sostenibilidad Empresarial son algunos de los retos a los que se enfrentan las empresas del siglo XXI o… ¿a alguien se le escapa que el mundo de los negocios está cambiando?

Pero de esto hablaremos la semana próxima.

El otro día mantenía una sana controversia con un amigo respecto a la posibilidad de imprimir desde dispositivos de movilidad (SmartPhones o Tablets) y la verdad es que a raíz de esto me picó la curiosidad y me puse a investigar acerca de esta posibilidad y me topé con un par de proyectos interesantes al respecto.

Antes que nada, me gustaría comentaros lo que se entiende por Printing-as-a-Service (Impresión como servicio). La impresión como servicio viene a solucionar la problemática que comentaba al principio del post, la posibilidad de imprimir desde dispositivos de movilidad.

Uno de los primeros escollos que nos encontramos al intentar resolver el problema es que los sistemas operativos pensados para este tipo de dispositivos no cuentan con un servicio de impresión propio, ya que es un servicio considerado no prioritario y que consume suficientes recursos como para ser descartado.

El siguiente escollo es que la cola de impresión necesita del espacio suficiente para renderizar el documento al lenguaje apropiado para la impresora a la que queramos enviar el documento. Por último, y quizá el obstáculo más importante, es que tenemos que contar con los controladores apropiados que nos permitan comunicarnos con la impresora en cuestión. Y todo esto en dispositivos que, si bien cada día son más potentes y cuentan con más recursos, tienen una capacidad limitada.

Ante esta problemática surge la impresión en la nube como respuesta. Dentro de los proveedores que he podido encontrar dentro de mi prospección en el mercado me he topado con dos iniciativas interesantes.

La primera nos llega de la mano del archiconocido Google, con su Google Cloud Print. Este servicio nos permite conectar una impresora a nuestra cuenta de Gmail y enviar nuestros trabajos de impresión desde nuestro dispositivo móvil. El principal problema que plantea esta solución es que se trata de una beta en una fase muy temprana de su desarrollo, ya que sólo permite imprimir desde Chrome OS, aunque Google promete ampliar esta funcionalidad al resto de sus productos cloud. Otras pegas importantes de este servicio son las limitaciones como:

• La dependencia de una máquina Microsoft Windows que actúe de proxy de impresión
• La imposibilidad de compartir la impresora a través de este servicio

La segunda de las iniciativas esta propuesta por Cortado, una empresa dedicada al desarrollo de aplicaciones móviles y de virtualización del escritorio. En este caso Cortado nos ofrece la posibilidad de imprimir en cualquier impresora cercana que cuente con conectividad WiFi o Bluetooth (actualmente cortado Cuenta con 5000 modelos de impresoras diferentes soportadas). El procedimiento resulta bastante simple, ya que lo único que es necesario hacer es instalar su aplicación en el dispositivo de movilidad, creando una cuenta de gratuita y comenzar a usar el servicio.

Si bien quizá la impresión como servicio no se encuentre en un estado de maduración suficiente como para dar el salto definitivo a la nube, si resulta más que interesante la existencia de estas iniciativas y otras iniciativas, como la Printing Cloud Alliance (en la que se encuentra también Cortado), que no hacen más que remarcar que el futuro inmediato (si no el presente) se encuentra en la nube y en los dispositivos de movilidad.

Hola de nuevo, soy Miguel Ángel Alonso y aquí estoy con vosotros como cada martes para hablar sobre un nuevo tema acerca del mundo de la virtualización.

En anteriores posts, hablamos sobre sistemas de copia de seguridad para Citrix (PHD Virtual),y mi gran amigo y compañero José María González sobre sistemas de copia de seguridad de VMware (El famoso Veeam Backup).

Dada la gran relevancia de Microsoft en el mercado y la constante mejora y mayor implantación de su sistema de virtualización (Hyper-V) en las empresas, me hizo buscar algún sistema de copia de seguridad para mi entorno de laboratorio y futuribles implantaciones, así que después de buscar y buscar, di con este software que cumple de manera más que interesante con todo lo necesario para poner a salvo los datos de nuestras empresas bajo entornos de virtualización de Microsoft.

Este no es otro que ALTARO Hyper-V (versión beta)

Las características más importantes de este software son mostradas en los siguientes puntos:

• Backups en caliente (copias de seguridad de las VMs sin parada de estas).
• Total integración con Hyper-V, eliminando complejos sistemas de configuración de los backups , reduciéndolos a 5 o menos clicks de ratón.
• Menor presencia de los agentes de backup, al ser sólo instalado en los Hosts y no en nuestras VMs, con el consiguiente ahorro de consumo de recursos y en particular para la seguridad de los departamentos de TI, donde no siempre son bien recibidos estos agentes por políticas de la empresa.
• Backup o Restauración de las VMs de manera individual sin tener que restaurar por obligación volúmenes enteros.
• Restauración desde múltiples puntos en el tiempo sin tener que ir siempre al backup más reciente.
• Tecnología de Backup Incremental (ReverseDelta) para una mayor eficiencia en los recursos consumidos y en los tiempos de copia de seguridad.
• Disponibilidad de tener diferentes programaciones de tiempo (Temporización) para nuestros backups .
• Se pueden restaurar VMs dentro del mismo Host con la particularidad de usar nombres diferentes (No sobrescribiría las ya existentes y se podría utilizar como un claro ejemplo de clonación)
• Backup consistente para sistemas Linux sin necesidad de parada de la VM.

La versión se hará realidad para todo aquel que esté interesado en probarla a partir del 31 de Marzo, con la particularidad de que Altaro regalará 250 Licencias gratuitas para la versión definitiva a los 250 primeros testadores que descarguen la versión beta.

Yo ya lo he hecho!!! ¿A qué esperas?.

Bueno aquí me despido de vosotros por hoy esperando haber contado algo de vuestro interés y os emplazo hasta la sema na que viene.

Un saludo para nuestros maravillosos lectores del Blog.