Un sorprendete estudio publicado por IDC revela que el 23% de los nuevos servidores x86 destinados a virtualización utilizan la tecnología de Microsoft frente al 44% de VMware. En este 23% están incluidas licencias de Hyper-V y Virtual Server, aunque es de suponer que las instalaciones de Virtual Server irán desapareciendo y migrando a Hyper-V.
Estos datos son muy engañosos ya que se refieren solamente a licencias OEM adquiridas durante el segundo cuarto del año 2Q08, a nivel global VMware se encuentra muy por encima con una cuota de mercado entorno al 80-85%. Visto que la versión final de Hyper-V fue lanzada a finales del 2Q08 y que todavía no tenemos disponible la versión final de SCVMM yo creo que habrá que esperar hasta el 1Q09 para ver datos mas significativos.
Tampoco sabemos que porcentaje de estas licencias de Microsoft van destinadas a entornos de producción y cuantas a entornos de pruebas y desarrollo, ya que había muchos clientes esperando probar la tecnología de virtualización de Microsoft. Lo que está claro es que el mercado está viendo en Microsoft un gran competidor en el área de la virtualización.
En diversos medios se especula sobre la posibilidad de que VMware siga los pasos de Netscape y acabe sucumbiendo ante el gigante del software. Esta idea y otros FUDs han hecho, que en el último año, las acciones de VMware hayan caído desde los 120$ a los 20$.
sábado, 18 de octubre de 2008
VirtualCenter Administrator Portal
Este nuevo producto nos proporciona una consola web centralizada desde la que podemos monitorizar y gestionar varios VirtualCenters. Entre sus funcionalidades podemos destacar:
Actualmente se encuentra en versión beta y se distribuye como un vApp/Virtual Appliance basado en Linux. Será este el vCenter basado en Linux del que se habló en el VMworld?
Desde luego no llega a ser ni un vCenter Server para Linux ni un cliente completo para Linux ya que la gestión que puedes hacer sobre el entorno es muy limitada, reduciéndose a encender, apagar, suspender y ver la consola remota de las maquinas virtuales.
Os dejo un breve video que he realizado del producto:
http://communities.vmware.com/community/beta/vcadminportal
- Autenticación contra varios VirtualCenters mediante single sign-on
- Monitorizar eventos y alarmas de varios VirtualCenters
- Búsquedas entre VirtualCenters
- Operaciones básicas sobre las maquinas virtuales.
Actualmente se encuentra en versión beta y se distribuye como un vApp/Virtual Appliance basado en Linux. Será este el vCenter basado en Linux del que se habló en el VMworld?
Desde luego no llega a ser ni un vCenter Server para Linux ni un cliente completo para Linux ya que la gestión que puedes hacer sobre el entorno es muy limitada, reduciéndose a encender, apagar, suspender y ver la consola remota de las maquinas virtuales.
Os dejo un breve video que he realizado del producto:
http://communities.vmware.com/community/beta/vcadminportal
sábado, 11 de octubre de 2008
Microsoft, el eterno malo de la película
En los últimos días se ha abierto una pequeña discusión en el blog del amigo J.L. Medina acerca de Hyper-V y ESX. Uno de los temas que se critican en la arquitectura de Hyper-V es la dependencia de los drivers I/O de terceros en la Root Partition.
Virtualización I/O
Como comente, los drivers I/O que utiliza VMware no están escritos desde cero por VMware, están basados en los drivers que los fabricantes programan para Linux. Estos drivers al ser open-source, son adaptados y modificados por VMware para ejecutarse como módulos dentro del vmkernel, de ahí que la HCL sea mas reducida. Estos drivers los podéis descargar y veréis que no tienen mucha diferencia con el driver original del fabricante.
La diferencia de arquitectura es que VMware incluye los drivers I/O dentro de su hypervisor y Hyper-V, al igual que Xen, depende de los drivers cargados en un sistema operativo en la Root Partition o Dom0. En mi humilde opinión, la estabilidad y eficiencia de un driver puede ser la misma en una capa que en la otra, y ambas capas tienen acceso privilegiado al dispositivo. Porque se critica esta arquitectura?
Porque todos los hypervisors modernos, véase Xen, Hyper-V o KVM, están utilizando esta arquitectura? Están todos equivocados? Creo que la función de un hypervisor, entre otras, es de gestionar el scheduling de I/O entre las maquinas virtuales, no la de ser un sistema operativo completo. Veis normal que el hypervisor incluya también el driver de LVM o de TCP/IP como hace el vmkernel? Siguiendo ese razonamiento el hypervisor debería acabar convirtiéndose en un sistema operativo, con la complejidad que eso conlleva. Pienso que teniendo sistemas operativos robustos no veo la necesidad de crear uno nuevo.
Me inclino más a pensar que la diferencia de arquitecturas radica en que VMware nunca ha querido depender del kernel de Linux porque no lo controla. Seguramente si VMware tuviera un sistema operativo propio o si hubieran podido modificar el kernel a su antojo, sin tener que publicar los cambios, la arquitectura podría haber sido totalmente distinta. En este sentido, Microsoft controla el sistema operativo y el hypervisor, y ahí pueden hacer lo que quieran sin tener que dar explicaciones a nadie. A VMware le interesa ir metiendo todo lo que pueda dentro del hypervisor y quitarse la dependencia de GNU/Linux, y poco a poco parece que lo irá haciendo.
Por favor señores, cuando critiquemos algo hagámoslo con argumentos sólidos. Me sorprende que la ultima comparativa oficial de VMware para defender VMware ESX respecto a Hyper-V se base en los clicks de ratón que hacen falta para instalarlo y configurar iSCSI. Porque si algo hemos aprendido en los últimos años es que en facilidad de manejo y experiencia de usuario final a Microsoft no le supera nadie.
Hyper-V en producción
Aunque no son equiparables al número de instalaciones de VMware, si que hay instalaciones de Hyper-V en producción . Pero centrémonos en la que todos conocemos: MSDN y TechNet.
Que la solución mas completa a día de hoy es la de VMware es evidente, pero que Microsoft lo esta haciendo bien también lo es.
Alguien tiene datos que yo no conozca sobre el mal rendimiento I/O de Xen o Hyper-V por utilizar esta arquitectura respecto a VMware?
Mejoras en la virtualización I/O
Desde luego el I/O no ha sido el punto fuerte de VMware ni de ningún hypervisor en estos años. Actualmente han conseguido reducir la penalización en CPU prácticamente a cero, pero no ocurre lo mismo con la virtualizacion I/O. VMware lleva desde el año 2006 hablando de “Passthrough I/O”, ahora rebautizado bajo el nombre de VMDirectPath.
En breve, gracias a VMDirectPath y a la virtualización asistada por hardware tendremos la posibilidad de que las maquinas virtuales se salten el VMM y accedan directamente a los dispositivos físicos consiguiendo mejoras sustanciales en el campo de la virtualizacion I/O. Pero a que coste?
Sentido común
Si nos guiamos por el sentido común en temas de arquitectuara, a mí ahora se me viene a la cabeza el tema de los 32-bit del vmkernel de VMware. Recordemos que el hypervisor de VMware esta formado por dos capas diferenciables: el vmkernel y VMM. El vmkernel, a día de hoy, es de 32-bit y es el encargado de gestionar I/O, memoria y CPU así como de cargar los drivers para interactuar con el Hardware que comentabamos anteriormente. Por otro lado, el monitor VMM que se instancia a cada VM puede ser de 32-bit o de 64-bit. Gracias a esta separación entre vmkernel de 32-bit y VMM de 64-bit, y con la ayuda de VT-x ,VMware ESX puede ejecutar GuestOS de 64-bit.
Es la mejor solución desde el punto de vista técnico? Creo que no, pero brillante desde luego que si lo es. De este modo, VMware se ha evitado la presión de tener que migrar a 64-bit el vmkernel y la SC durante mucho tiempo para poder ejecutar maquinas virtuales de 64-bit. Ahora con ESX4, ya han hecho el esfuerzo de migrar todo a 64-bit.
Yo nunca he criticado esta solución aunque el mercado, sobre todo Citrix, si lo ha hecho sin ninguna razón.
Microsoft, el eterno malo de la película
Con lo que no estoy de acuerdo es en criticar todo lo que hace un fabricante. Microsoft tiene productos muy buenos y otros no tan buenos. Microsoft tiene gente brillante, al igual que la tiene VMware.
Estamos acostumbrados a ver como Microsoft siempre llega tarde con sus productos, pero cuando llega sabe posicionarlos muy bien. Solo hay que ver como ha posicionado Windows Server, SQL Server, Exchange o Internet Explorer en un mercado ya liderado con soluciones fantásticas. Que lo ha hecho con una política y un marketing agresivo? Correcto, eso nadie lo duda. Pero y que empresario no haría lo mismo por su empresa?
Microsoft, con su solución de virtualización, ha llegado el ultimo y se le pueden echar en falta cosas como LiveMigration, Cluster Filesystem, soporte para mas GuestOS, etc.. cosas que nadie duda tendrá con el tiempo y que VMware tampoco tuvo en su primera versión.
Recordemos que el VMFS v1 de ESX 1.5 no era un cluster-filesystem y no podía ser compartido entre varios hosts, no había VMotion, no había vCenter, la arquitectura I/O de dispositivos compartidos entre SC y VMKernel, etc…
Esta claro, y eso no lo discute nadie, que a día de hoy VMware tiene una posición inmejorable. Pero no olvidemos que otros fabricantes han estado en la misma posición. No olvidemos empresas como Sun Microsystems, Novell, IBM, Netscape, Citrix y otras muchas que se quedaron en el camino. Todas ellas tenían una posición inmejorable en el mercado con sus productos respecto a los equivalentes de Microsoft.
Virtualización I/O
Como comente, los drivers I/O que utiliza VMware no están escritos desde cero por VMware, están basados en los drivers que los fabricantes programan para Linux. Estos drivers al ser open-source, son adaptados y modificados por VMware para ejecutarse como módulos dentro del vmkernel, de ahí que la HCL sea mas reducida. Estos drivers los podéis descargar y veréis que no tienen mucha diferencia con el driver original del fabricante.
La diferencia de arquitectura es que VMware incluye los drivers I/O dentro de su hypervisor y Hyper-V, al igual que Xen, depende de los drivers cargados en un sistema operativo en la Root Partition o Dom0. En mi humilde opinión, la estabilidad y eficiencia de un driver puede ser la misma en una capa que en la otra, y ambas capas tienen acceso privilegiado al dispositivo. Porque se critica esta arquitectura?
Porque todos los hypervisors modernos, véase Xen, Hyper-V o KVM, están utilizando esta arquitectura? Están todos equivocados? Creo que la función de un hypervisor, entre otras, es de gestionar el scheduling de I/O entre las maquinas virtuales, no la de ser un sistema operativo completo. Veis normal que el hypervisor incluya también el driver de LVM o de TCP/IP como hace el vmkernel? Siguiendo ese razonamiento el hypervisor debería acabar convirtiéndose en un sistema operativo, con la complejidad que eso conlleva. Pienso que teniendo sistemas operativos robustos no veo la necesidad de crear uno nuevo.
Me inclino más a pensar que la diferencia de arquitecturas radica en que VMware nunca ha querido depender del kernel de Linux porque no lo controla. Seguramente si VMware tuviera un sistema operativo propio o si hubieran podido modificar el kernel a su antojo, sin tener que publicar los cambios, la arquitectura podría haber sido totalmente distinta. En este sentido, Microsoft controla el sistema operativo y el hypervisor, y ahí pueden hacer lo que quieran sin tener que dar explicaciones a nadie. A VMware le interesa ir metiendo todo lo que pueda dentro del hypervisor y quitarse la dependencia de GNU/Linux, y poco a poco parece que lo irá haciendo.
Por favor señores, cuando critiquemos algo hagámoslo con argumentos sólidos. Me sorprende que la ultima comparativa oficial de VMware para defender VMware ESX respecto a Hyper-V se base en los clicks de ratón que hacen falta para instalarlo y configurar iSCSI. Porque si algo hemos aprendido en los últimos años es que en facilidad de manejo y experiencia de usuario final a Microsoft no le supera nadie.
Hyper-V en producción
Aunque no son equiparables al número de instalaciones de VMware, si que hay instalaciones de Hyper-V en producción . Pero centrémonos en la que todos conocemos: MSDN y TechNet.
- MSDN sirve más de 3 millones de páginas por día.
- TechNet sirve más de un millón de páginas por día.
Que la solución mas completa a día de hoy es la de VMware es evidente, pero que Microsoft lo esta haciendo bien también lo es.
Alguien tiene datos que yo no conozca sobre el mal rendimiento I/O de Xen o Hyper-V por utilizar esta arquitectura respecto a VMware?
Mejoras en la virtualización I/O
Desde luego el I/O no ha sido el punto fuerte de VMware ni de ningún hypervisor en estos años. Actualmente han conseguido reducir la penalización en CPU prácticamente a cero, pero no ocurre lo mismo con la virtualizacion I/O. VMware lleva desde el año 2006 hablando de “Passthrough I/O”, ahora rebautizado bajo el nombre de VMDirectPath.
En breve, gracias a VMDirectPath y a la virtualización asistada por hardware tendremos la posibilidad de que las maquinas virtuales se salten el VMM y accedan directamente a los dispositivos físicos consiguiendo mejoras sustanciales en el campo de la virtualizacion I/O. Pero a que coste?
- Comprar servidores nuevos con procesadores Intel VT-d o AMD IOMMU.
- Dispositivos I/O que soporten SR-IOV y NICs que soporten múltiples colas VMDq.
- Imposibilidad de hacer VMotion.
- Imposibilidad de Suspender/Resumir las maquinas virtuales.
- Imposibilidad de compartir el mismo dispositivo físico con varias maquinas virtuales.
- Instalación en el GuestOS de drivers especiales para reconocer el dispositivo físico.
Sentido común
Si nos guiamos por el sentido común en temas de arquitectuara, a mí ahora se me viene a la cabeza el tema de los 32-bit del vmkernel de VMware. Recordemos que el hypervisor de VMware esta formado por dos capas diferenciables: el vmkernel y VMM. El vmkernel, a día de hoy, es de 32-bit y es el encargado de gestionar I/O, memoria y CPU así como de cargar los drivers para interactuar con el Hardware que comentabamos anteriormente. Por otro lado, el monitor VMM que se instancia a cada VM puede ser de 32-bit o de 64-bit. Gracias a esta separación entre vmkernel de 32-bit y VMM de 64-bit, y con la ayuda de VT-x ,VMware ESX puede ejecutar GuestOS de 64-bit.
Es la mejor solución desde el punto de vista técnico? Creo que no, pero brillante desde luego que si lo es. De este modo, VMware se ha evitado la presión de tener que migrar a 64-bit el vmkernel y la SC durante mucho tiempo para poder ejecutar maquinas virtuales de 64-bit. Ahora con ESX4, ya han hecho el esfuerzo de migrar todo a 64-bit.
Yo nunca he criticado esta solución aunque el mercado, sobre todo Citrix, si lo ha hecho sin ninguna razón.
Microsoft, el eterno malo de la película
Con lo que no estoy de acuerdo es en criticar todo lo que hace un fabricante. Microsoft tiene productos muy buenos y otros no tan buenos. Microsoft tiene gente brillante, al igual que la tiene VMware.
Estamos acostumbrados a ver como Microsoft siempre llega tarde con sus productos, pero cuando llega sabe posicionarlos muy bien. Solo hay que ver como ha posicionado Windows Server, SQL Server, Exchange o Internet Explorer en un mercado ya liderado con soluciones fantásticas. Que lo ha hecho con una política y un marketing agresivo? Correcto, eso nadie lo duda. Pero y que empresario no haría lo mismo por su empresa?
Microsoft, con su solución de virtualización, ha llegado el ultimo y se le pueden echar en falta cosas como LiveMigration, Cluster Filesystem, soporte para mas GuestOS, etc.. cosas que nadie duda tendrá con el tiempo y que VMware tampoco tuvo en su primera versión.
Recordemos que el VMFS v1 de ESX 1.5 no era un cluster-filesystem y no podía ser compartido entre varios hosts, no había VMotion, no había vCenter, la arquitectura I/O de dispositivos compartidos entre SC y VMKernel, etc…
Esta claro, y eso no lo discute nadie, que a día de hoy VMware tiene una posición inmejorable. Pero no olvidemos que otros fabricantes han estado en la misma posición. No olvidemos empresas como Sun Microsystems, Novell, IBM, Netscape, Citrix y otras muchas que se quedaron en el camino. Todas ellas tenían una posición inmejorable en el mercado con sus productos respecto a los equivalentes de Microsoft.
Instalación Hyper-V Server 2008 Español
Aunque ya ha sido ampliamente comentado en otros blogs, os dejo un video que he realizado del proceso de instalación de Hyper-V Server 2008 en Español. En el video se han cortado los tiempos de espera y la duración real de la instalación fue media hora aproximadamente.
jueves, 2 de octubre de 2008
Microsoft Hyper-V Server 2008 disponible
Ya tenemos disponible para descargar gratuitamente Microsoft Hyper-V Server 2008.
A diferencia de la versión de Hyper-V que Microsoft publicó en Junio y que requiere disponer de una licencia de Windows 2008, esta nueva versión stand-alone es totalmente gratuita y está basada en Windows 2008 Core con el role de Hyper-V.
Microsoft, que hace meses anunció que esta versión costaría 28$, ha cambiado su estrategia ofreciendo un hypervisor sin ningún coste a raíz del movimiento realizado por VMware en Julio con ESXi.
En la siguiente tabla podéis ver las funcionalidades de cada una de las versiones disponibles. Como vemos esta versión no dispone de funcionalidades avanzadas como HA, QuickMigration o soporte para mas de 32GB de RAM.
Nota de prensa de Microsoft:
http://www.microsoft.com/presspass/press/2008/oct08/10-01HyperVRTM08PR.mspx
Descarga Hyper-V Server 2008:
http://www.microsoft.com/servers/hyper-v-server/how-to-get.mspx
A diferencia de la versión de Hyper-V que Microsoft publicó en Junio y que requiere disponer de una licencia de Windows 2008, esta nueva versión stand-alone es totalmente gratuita y está basada en Windows 2008 Core con el role de Hyper-V.
Microsoft, que hace meses anunció que esta versión costaría 28$, ha cambiado su estrategia ofreciendo un hypervisor sin ningún coste a raíz del movimiento realizado por VMware en Julio con ESXi.
En la siguiente tabla podéis ver las funcionalidades de cada una de las versiones disponibles. Como vemos esta versión no dispone de funcionalidades avanzadas como HA, QuickMigration o soporte para mas de 32GB de RAM.
Nota de prensa de Microsoft:
http://www.microsoft.com/presspass/press/2008/oct08/10-01HyperVRTM08PR.mspx
Descarga Hyper-V Server 2008:
http://www.microsoft.com/servers/hyper-v-server/how-to-get.mspx
lunes, 29 de septiembre de 2008
Enhanced VMotion Compatibility
A lo largo de los ultimos años os habréis visto en la necesidad de ampliar vuestra infraestructura virtual con nuevos servidores y ver que al incluir una nueva generación de procesadores no podemos hacer VMotion con los antiguos. El problema de la compatibilidad con VMotion viene dado por la incorporación de nuevos juegos de instrucciones en cada generación de procesadores que hacen que una maquina virtual no deba ser migrada de un procesador a otro de una generación anterior para garantizar su estabilidad.
Por ejemplo, si una aplicación esta ejecutándose en un servidor con procesadores basados en arquitectura Penryn que soportan el juego de instrucciones SSE4.1 y permitimos migrarla a un servidor donde la arquitectura del procesador es Merom-SSSE3, la aplicación no se da cuenta de esta migración y al intentar hacer uso de alguna instrucción SSE4.1 para optimizar su ejecución generara una excepción y provocara que el sistema deje de funcionar.
Las mascaras para hacer compatibles procesadores de distinta generación Intel Prescott-SSE3, Merom-SSSE3, Penryn-SSE4.1 o Nehalem-SSE4.2 nunca han estado soportadas por VMware como indican en los KB1991(Intel) y KB1992(AMD)
Para remediar este problema los nuevos procesadores vienen con una funcionalidad que permite al VMM ocultar características del procesador, modificando las respuestas de la instrucción CPUID, para hacerlos compatibles con otros procesadores mas antiguos. Esta tecnología se conoce con el nombre de FlexMigration en Intel o Extended Migration en AMD.
La funcionalidad que utiliza esta tecnología en VI3 se encuentra disponible a partir de ESX3.5U2 y VC2.5U2 bajo el nombre de EVC o Enhanced VMotion Compatibility. Cuando habilitamos EVC en cluster de ESX lo que estamos haciendo es decir al VMM que muestre a las maquinas virtuales el conjunto de instrucciones mas bajo que soportan todos los procesadores del cluster, por defecto este juego de instrucciones es el de la arquitectura Merom-SSE3 en el caso de Intel, de esta forma todos los procesadores presentan las mismas características de este procesador base.
Los servidores con procesadores que no tengan las características del procesador base o no soporten FlexMigration no podrán ser agregados a un cluster de EVC.
Si al agregar un host a un cluster de EVC os da un aviso de que el servidor no puede ser agregado porque no está soportado por EVC debéis revisar lo siguiente:
Esta tecnología no permite hacer compatibles procesadores de distintos fabricantes AMD/Intel. La compatibilidad de VMotion a nivel de fabricante queda de la siguiente manera:
Guía de referencia de VMotion:
http://www.vmware.com/files/pdf/vmotion_info_guide.pdf
Lista de procesadores compatibles:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212
Por ejemplo, si una aplicación esta ejecutándose en un servidor con procesadores basados en arquitectura Penryn que soportan el juego de instrucciones SSE4.1 y permitimos migrarla a un servidor donde la arquitectura del procesador es Merom-SSSE3, la aplicación no se da cuenta de esta migración y al intentar hacer uso de alguna instrucción SSE4.1 para optimizar su ejecución generara una excepción y provocara que el sistema deje de funcionar.
Las mascaras para hacer compatibles procesadores de distinta generación Intel Prescott-SSE3, Merom-SSSE3, Penryn-SSE4.1 o Nehalem-SSE4.2 nunca han estado soportadas por VMware como indican en los KB1991(Intel) y KB1992(AMD)
Para remediar este problema los nuevos procesadores vienen con una funcionalidad que permite al VMM ocultar características del procesador, modificando las respuestas de la instrucción CPUID, para hacerlos compatibles con otros procesadores mas antiguos. Esta tecnología se conoce con el nombre de FlexMigration en Intel o Extended Migration en AMD.
La funcionalidad que utiliza esta tecnología en VI3 se encuentra disponible a partir de ESX3.5U2 y VC2.5U2 bajo el nombre de EVC o Enhanced VMotion Compatibility. Cuando habilitamos EVC en cluster de ESX lo que estamos haciendo es decir al VMM que muestre a las maquinas virtuales el conjunto de instrucciones mas bajo que soportan todos los procesadores del cluster, por defecto este juego de instrucciones es el de la arquitectura Merom-SSE3 en el caso de Intel, de esta forma todos los procesadores presentan las mismas características de este procesador base.
Los servidores con procesadores que no tengan las características del procesador base o no soporten FlexMigration no podrán ser agregados a un cluster de EVC.
Si al agregar un host a un cluster de EVC os da un aviso de que el servidor no puede ser agregado porque no está soportado por EVC debéis revisar lo siguiente:
- Los procesadores del servidor soportan Intel FlexMigration o AMD-V Extended Migration o son del tipo base definido.
- En la BIOS tenéis habilitadas las funcionalidades Intel VT Virtualization Technology y XD Execute Disable Bit o equivalentes en AMD-V.
- Las maquinas virtuales del servidor que queréis añadir están apagadas.
- Todos los servidores del cluster se encuentran en la versión ESX3.5 U2 o superior y están manejados por VC2.5 U2.
Esta tecnología no permite hacer compatibles procesadores de distintos fabricantes AMD/Intel. La compatibilidad de VMotion a nivel de fabricante queda de la siguiente manera:
- Intel Merom Xeon® 3200, Intel Xeon® 5300, Intel Xeon® 7300 o posteriores.
- AMD Second Generation Opteron (Rev-E/F), AMD Third Generation Opteron (Barcelona) o posteriores.
Guía de referencia de VMotion:
http://www.vmware.com/files/pdf/vmotion_info_guide.pdf
Lista de procesadores compatibles:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003212
domingo, 28 de septiembre de 2008
Offline VDI
Desde hace tiempo se venia escuchando hablar de Offline VDI o lo que es lo mismo escritorios virtuales que se mueven con el usuario y con los que podemos trabajar aunque no tengamos conexión a la red. Mientras el usuario esta en la oficina o tiene conexión a la red puede conectarse a ellos tal como hacemos actualmente. Pero que ocurre si el usuario quiere trabajar con su escritorio virtual cuando esta de viaje o en un avión? Con esta tecnología el usuario antes de marcharse puede llevarse una copia local de su escritorio y cuando vuelva a la oficina o tener conectividad sincronizar los cambios y trabajar en remoto.
En el VMworl 2008, VMware demostró por primera vez el concepto de Offline VDI. De momento utilizan una versión reducida de VMWare Player para que el usuario pueda ejecutar su escritorio virtual en local. La primera vez que el usuario quiere llevarse el escritorio, VDM lo marca como no accesible y lo descarga completamante al ordenador del usuario donde se ejecutara mediante VMware Player. Utilizando la tecnología de snapshots y ficheros delta se reducen los tiempos de sincronización posteriores de manera que cada vez que el usuario quiera sincronizar su escritorio solo se transfieren estos ficheros delta.
En los próximos años supongo que empezaremos a ver ordenadores sin sistemas operativos instalados, únicamente con vClient integrado en BIOS o FlashCard y que nos permitirán conectarnos a escritorios virtuales remotos o ejecutar una copia local.
En el VMworl 2008, VMware demostró por primera vez el concepto de Offline VDI. De momento utilizan una versión reducida de VMWare Player para que el usuario pueda ejecutar su escritorio virtual en local. La primera vez que el usuario quiere llevarse el escritorio, VDM lo marca como no accesible y lo descarga completamante al ordenador del usuario donde se ejecutara mediante VMware Player. Utilizando la tecnología de snapshots y ficheros delta se reducen los tiempos de sincronización posteriores de manera que cada vez que el usuario quiera sincronizar su escritorio solo se transfieren estos ficheros delta.
En los próximos años supongo que empezaremos a ver ordenadores sin sistemas operativos instalados, únicamente con vClient integrado en BIOS o FlashCard y que nos permitirán conectarnos a escritorios virtuales remotos o ejecutar una copia local.
Suscribirse a:
Entradas (Atom)
