El título del post de esta semana debería corresponder con la prometida tercera entrega de la serie “La powerCLI se renueva”, pero en esta ocasión las funcionalidades de las que os quiero hablar creo que son tan interesantes y potentes que se merecían una atención especial.

La idea básica de este grupo nuevo de cmdlets disponibles en la versión 5 de PowerCLI es la de customizar la imagen de instalación de ESXi de forma que podamos añadir o quitar software a nuestra ISO de instalación.

Para ello es necesario que primero veamos algunos conceptos básicos previos:

• VIB, es el acrónimo de vSphere Installation Boundle y puede ser entendido como el ladrillo que usaremos para construir una imagen de ESXi. Básicamente es un paquete con una estructura interna que contiene:
  • los ficheros que van a añadir la funcionalidad deseada a la imagen (Drivers, proveedores CIM, software para la imagen base, etc…)
  • un descriptor XML del paquete
  • un fichero de firma.
  • Almacén (Depot), es precisamente lo que parece, un conjunto de VIBs al que nos conectaremos para generar nuestra imagen. Los almacenes los podemos tener online (una URL de un servicio web) u offline (un fichero ZIP que descargamos directamente desde vmware o desde el fabricante sea). La parte importante de los almacenes que también pueden ser gestionados con Update Manager e Image Builder CLI (los VIBs no pueden ser gestionados nada más que por ESXCLI)
  • Perfil, que es la propia imagen que estamos construyendo y que al final del proceso acabaremos exportando.

Una vez visto los conceptos básicos podemos empezar a construir nuestra imagen personalizada de instalación de ESXi.

Primero añadiremos un almacén de VIBs que será el que usaremos para construir el perfil de nuestra imagen:

PowerCLI> Add-EsxSoftwareDepot -DepotUrl https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Depot Url

———

https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

En este caso estamos añadiendo el almacén estándar online de vmware. Del mismo modo podríamos haber añadido un almacén offline simplemente indicando la ruta completa mediante el parámetro DepotUrl. En este caso el fichero tiene que ser de tipo “zip”.

A continuación crearemos nuestro perfil. Sin embargo, en lugar de crear un perfil de nuevo y arriesgarnos a dejarnos algún componente importante atrás, clonaremos uno de los perfiles estándares disponibles en el almacén.

Por lo tanto, primero listamos los perfiles disponibles:

PowerCLI> Get-EsxImageProfile

Name                           Vendor          Last Modified   Acceptance Level

—-                               ——          ————-   —————-

ESXi-5.0.0-20110904001-notools VMware, Inc.    26/08/2011 1… PartnerSupported

ESXi-5.0.0-469512-no-tools     VMware, Inc.    19/08/2011 1… PartnerSupported

ESXi-5.0.0-20110904001-stan… VMware, Inc.    26/08/2011 1… PartnerSupported

ESXi-5.0.0-469512-standard     VMware, Inc.    19/08/2011 1… PartnerSupported

Y a continuación clonaremos uno de los perfiles disponibles, por ejemplo ESXi-5.0.0-469512-standard

PowerCLI> New-EsxImageProfile -CloneProfile ESXi-5.0.0-469512-standard -Name “QoSIT_ESXi”

Name                           Vendor          Last Modified   Acceptance Level

—-                           ——          ————-   —————-

QoSIT_ESXi                     VMware, Inc.    19/08/2011 1… PartnerSupported

Un punto interesante a tener en cuenta es que la cadena que le pasemos al parámetro Name aparecerá posteriormente tanto en el instalador de la imagen como en el atributo Image Profile en el Host Summary disponible desde el vSphere Client.

Una vez que tenemos nuestro perfil creado es hora de añadir o quitar el software, o los VIBs, que nos interesen. Para esto, listaremos el software disponible en los almacenes que tenemos conectados:

PowerCLI> Get-EsxSoftwarePackage

Name                       Version                                                     Vendor     Release Date

—-                                                ——-                                            ——     ————

net-ixgbe                                2.0.84.8.2-10vmw.500.0.0.46… VMware     19/08/2011 1:…

ata-pata-hpt3x2n             0.3.4-3vmw.500.0.0.469512      VMware     19/08/2011 1:…

esx-base                                 5.0.0-0.3.474610                                VMware     13/09/2011 0:…

ehci-ehci-hcd                       1.0-3vmw.500.0.0.469512          VMware     19/08/2011 1:…

ata-pata-atiixp                   0.4.6-3vmw.500.0.0.469512      VMware     19/08/2011 1:…

scsi-megaraid2                  2.00.4-9vmw.500.0.0.469512     VMware     19/08/2011 1:…

(…salida truncada…)

Y añadiremos o quitaremos el software que nos interese con los cmdlets Add-EsxSoftwarePackage y Remove-EsxSoftwarePackage. En este caso, como hemos elegido un almacen estandar no tiene mucho sentido añadir el mismo software dos veces a la imagen, así que para este ejemplo eliminaremos el paquete del descargador iSCSI de Broadcom (scsi-bnx2i):

PowerCLI> Remove-EsxSoftwarePackage -ImageProfile QoSIT_ESXi -SoftwarePackage scsi-bnx2i

¿Siguiente paso despues de haber personalizado nuestro perfil? Exportalo. En este punto tenemos dos opciones, hacerlo a formato ISO para quemarlo en un CD o a formato ZIP para usarlo con Upgrade Manager, como base para futuras personalizaciones o publicarlo en un servidor PXE y usar otra de las nuevas funcionalidades de la versión 5 de vSphere, el AutoDeploy. En lo que al cmdlet se refiere la diferencia reside en usar el modificador ExportToISO (formato ISO) o ExportToBoundle (formato ZIP):

PowerCLI> Export-EsxImageProfile -ImageProfile QoSIT_ESXi -FilePath C:\temp\ESXi_QOSIT.iso –ExportToIso

Después de unos breves minutos tendremos nuestra nueva y flamante imagen ESXi personalizada y lista para ser instalada.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

La semana pasada os hablaba un poco acerca de una de las novedades de vSphere 5, la nueva versión de su Shell de gestión PowerCLI. En el post anterior hacía un pequeño repaso de las recientes incorporaciones a esta versión y comentaba algunos de los nuevos cmdlets y snapins que tenemos ahora disponibles.

Ese mismo post me comprometí con vosotros a entrar un poco más en detalle en algunos de los cmdlets que mencionaba. Y como lo prometido es deuda, aquí vengo con algunos cmdlets después de “destriparlos” un poquito…

-        Get-VIProperty: nos permite obtener una propiedad personalizada de objetos vmware.

La opción de crear propiedades personalizadas para objetos de vmware, tipo VirtualMachine, Host o Datastore, no es nueva de la versión 5, ya teníamos esa posibilidad en la PowerCLI 4.1 con los cmdlets New-VIProperty y Remove-VIProperty, sin embargo no teníamos opción sencilla de obtener la definición de esas nuevas propiedades personalizadas. Get-VIProperty nos facilita esta tarea.

La definición de propiedades personalizadas es realmente potente e interesante, y lo suficientemente extensa como para tratarla en un post independiente, por lo que en esta ocasión, y para no extenderme demasiado, voy a dejaros un ejemplo sencillo de uso de las propiedades personalizadas:

Para este ejemplo tomemos las propiedades de un objeto datastore:

PowerCLI C:\>get-datastore Datastore1 | Format-List *

La salida del comando será algo parecido a esto:

FileSystemVersion              : 3.46

DatacenterId                   : Datacenter-ha-datacenter

Datacenter                     : ha-datacenter

ParentFolderId                 : Folder-ha-folder-datastore

ParentFolder                   : datastore

DatastoreBrowserPath           : vmstores:\192.168.1.30@443\ha-datacenter\ Datastore1

FreeSpaceMB                    : 2070576

CapacityMB                     : 2096896

Accessible                     : True

Type                           : VMFS

StorageIOControlEnabled        : False

CongestionThresholdMillisecond : 232

Name                           : Datastore1

ExtensionData                  : VMware.Vim.Datastore

CapacityGB                     : 2022,046875

FreeSpaceGB                    : 2047,75

Id                             : Datastore-4e4bb645-a7775cb1-71ec-d8d385a17632

Uid                            : /VIServer=root@192.168.1.30:443/Datastore=Datastore-4e4bb645-a7775cb1-71ec-d8d385a17632/

Supongamos ahora, a modo de ejemplo, que necesitamos saber el número de máquinas virtuales que aloja este datastore. Tenemos la opción de consultar la variable ExtensionData.VM.Length o definirnos nuestra propiedad personalizada para que nos devuelva directamente este dato:

PowerCLI C:\>New-VIProperty –Name NumeroVMs –ObjectType Datastore –Value { param($ds); $ds.ExtensionData.VM.Length }

Si ahora obtenemos de nuevo la lista de propiedades de nuestro datastore, o de cualquier otro, veremos la nueva propiedad recién creada:

NumeroVMs                      : 14

FileSystemVersion              : 3.46

DatacenterId                   : Datacenter-ha-datacenter

Datacenter                     : ha-datacenter

ParentFolderId                 : Folder-ha-folder-datastore

ParentFolder                   : datastore

DatastoreBrowserPath           : vmstores:\192.168.1.30@443\ha-datacenter\ Datastore1

FreeSpaceMB                    : 2070576

CapacityMB                     : 2096896

Accessible                     : True

Type                           : VMFS

StorageIOControlEnabled        : False

CongestionThresholdMillisecond : 232

Name                           : Datastore1

ExtensionData                  : VMware.Vim.Datastore

CapacityGB                     : 2022,046875

FreeSpaceGB                    : 2047,75

Id                             : Datastore-4e4bb645-a7775cb1-71ec-d8d385a17632

Uid                            : /VIServer=root@192.168.1.30:443/Datastore=Datastore-4e4bb645-a7775cb1-71ec-d8d385a17632/

Y después de todo esto… ¿para qué sirve Get-VIProperty? Bien, en su forma más sencilla, es decir, sin parámetros, nos devolverá el listado de todas las propiedades personalizadas, con su correspondiente definición. En nuestro caso, si no nos acordamos de cómo habíamos calculado el valor de una propiedad, ahora podemos saberlo:

PowerCLI C:\> Get-VIProperty –Name NumeroVMs –ObjectType Datastore | Format-List *

Name           : NumeroVMs

RetrievingType : Datastore

DeclaringType  : Datastore

Value          : param($ds)

$ds.ExtensionData.VM.Length

-        Copy-VMGuestFile: el nombre es auto-explicativo, copia un fichero o carpeta entre el host y una máquina virtual. Veamos un ejemplo sencillo.

En este ejemplo vamos a copiar la carpeta C:\temp\DEMO, que contiene cinco archivos y que se encuentra en nuestra máquina local a la carpeta C:\DEMO en la máquina virtual VM1.

El contenido de la carpeta DEMO es el siguiente:

Directorio: C:\temp\DEMO

Mode                LastWriteTime     Length Name

—-                ————-     —— —-

-a—        09/06/2011     13:07       3425 creds.xml

-a—        04/07/2011     11:11   66093364 cuentas.xml

-a—        19/08/2011     14:25       4066 Dpts.csv

-a—        15/11/2010     10:01      24099 groups.csv

-a—        11/11/2010     17:27       3351 OU.csv

Para realizar la copia ejecutaremos:

PowerCLI C:\>Copy-VMGuestFile –VM (Get-VM VM1) –LocalToGuest –Destination “C:\DEMO” –Source “C:\temp\DEMO” –GuestCredential (Get-Credential)

Donde:

-        VM es la máquina virtual con la que queremos interactuar

-        LocalToGuest nos indica el sentido de la copia, y por lo tanto la ubicación de los ficheros y directorios indicados por Destination y Source. En este ejemplo, Destination se encuentra en la máquina virtual y Source en el equipo desde el que se lanza el cmdlet.

-        GuestCredential indica las credenciales que usaremos para logarnos en la máquina virtual.

Como apunte final a este cmdlet comentaros que hay que lanzar este cmdlet desde la versión de 32bits de PowerCLI y que no funciona para la versión free de ESXi.

Por último recordaros que para que todos estos cmdlets funcionen correctamente tendremos que habernos conectado previamente a nuestro vCenter o host ESXi mediante el cmdlet Connect-VIServer.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

De vuelta de las vacaciones estivales, que espero que hayan sido tan entretenidas y reparadoras como han sido las mías, toca volver al trabajo y ponerse manos a la obra. Toca por lo tanto disfrutar ahora de placeres menos mundanos, cervecita, sol, playa, etc… y volcarnos en placeres algo más técnicos.

Y por supuesto, hablar de placeres técnicos y no hacer referencia al anuncio bomba de su nueva versión de vSphere 5, que hiciera VMware durante el mes de Julio, parece un poco incongruente.

Como ya habréis podido observar todos los miembros del blog estamos ávidos de destripar esta nueva versión del producto estrella de VMware y contaros nuestras experiencias, y por supuesto yo no voy a ser menos.

En mi caso, me gustaría “destripar” junto a vosotros una de las herramientas de gestión y automatización más potentes con las que me he podido encontrar, y de la que ya hemos hablado en el pasado, PowerCLI, que como resulta evidente se ha puesto de largo y se ha renovado para adecuarse a todas las novedades que vienen acompañado a su hermano mayor, vSphere.

Antes de entrar en faena, estaría cometiendo pecado mortal si no pusiera al menos el link de descarga de la nueva versión de PowerCLI.

En este primer post relacionado con esta herramienta de automatización me vais a permitir que no entre en demasiado detalle en todas las novedades, ya que como veréis son numerosas e interesantes, y creo sinceramente que debería ilustrarlos al menos con un mínimo ejemplo de uso.

De entre los nuevos cmdlets que podemos encontrar en esta nueva versión tenemos:

• Clonado de plantillas con New-Template
• Copiado de ficheros y carpetas desde y hacia un sistema operativo invitado con Copy-VMGuestFile.
• Unión a dominios con Get-VMHostAuthentication y Set-VMHostAuthentication.
• Unión de hosts ESX (versión 4.1 y posterior) a un Active Directory por medio de Get-VMHostAuthentication y Set-VMHostAuthentication.
• Obtención de usuarios y grupos del vCenter Server por medio de Get-VIAccount.
• Soporte de Servidores vCenter en el linked mode para el cmdlet Connect-VIServer.
• Obtener propiedades de objetos, Get-VIProperty.
• Movimiento de virtual appliances, Move-VApp.
• Importar fichero comprimidos y troceados con Import-VApp.
• Importar y Exportar virtual appliance en formato OVA.
• Soporte de la característica de SSPI passthrough de VIX
• Soporte de storageDRS: Crear máquinas virtuales y discos duros en los datastores del clúster y definir reglas de anti-afinidad (experimental).

Pero como no sólo de cmdlets vive el hombre, en esta versión se han añadido tres nuevos snap-ins (o librerías de cmdlets) para la gestión de algunos aspectos interesantes de nuestra infraestructura virtual:

• VMware.VimAutomation.License: Este snap-in contiene el conjunto de cmdlets que nos permiten gestionar los components de licencia de VMware.
• VMware.ImageBuilder: Este snap-in lo utilizaremos para manipular la imagen core de nuestro ESXi para añadir drivers, proveedores CIM y otros componentes y exportar la imagen resultante a una ISO que utilizaremos para el Auto Deploy.
• VMware.DeployAutomation: Contiene los cmdlets que nos permiten trabajar con VMware Auto Deploy.

Como podéis ver la nueva versión PowerCLI viene cargadita de nuevas características realmente interesantes que nos permitirán llegar a niveles de automatización realmente impresionantes.

¿Crees que este videopost puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por tu apoyo.

Hace poco más de una semana que se Apple liberó la nueva versión de su sistema operativo, MacOS X Lion, y entre la batería de nuevas funcionalidades, actualizaciones y demás parafernalias que suelen acompañar a la salida de una nueva versión de cualquier programa, hay un aspecto interesante que me llamó poderosamente la atención y que me gustaría compartir con vosotros: Apple permite Virtualizar Lion!!!!

¿Y qué quiere decir esto exactamente?

Pues precisamente lo que estáis pensando, que podemos coger nuestro medio de instalación (USB, cuando esté disponible, o ISO) e instalar nuestro flamante MacOS X Lion en una máquina virtual y echarlo a andar.

Para aquellos que estéis pensando que eso ya lo podía hacer con Leopard o Panther comentaros que si bien es cierto, el acuerdo de licencia con Apple no recogía estos casos si no lo prohibía directamente. La diferencia sustancial es que ahora si se contempla esta circunstancia en el acuerdo de licencia de nuestro MacOS X.

Pero como en todo acuerdo de licencia, hay limitaciones a los supuestos en los que podemos virtualizar a nuestro nuevo felino. En particular Apple nos permite correr dos instancias virtuales simultáneas, siempre que se haga sobre un Lion del que poseamos licencia y que este se ejecute sobre el hardware de la gente de Cupertino. Esta limitación nos obliga automáticamente a descartar cualquier opción de virtualizar usando hypervisores de tipo 1 y obligándonos a usar hypervisores de tipo 2 como VMware Fusion o Parallels Desktop.

Y si de algo es de lo que se caracteriza especialmente la compañía de la manzana es por la atención al detalle, y el acuerdo de licencia no iba a ser una excepción a esta máxima de diseño. Si alguno ha pensado “Bueno, todavía puedo montar un MacOS X Lion (Server o Desktop), le monto dos maquinitas virtuales, habilito el escritorio compartido y ya tengo una solución VDI casera con mis leoncitos…” siento deciros Apple ya se ha adelantado y sólo permite el acceso remoto interactivo a sólo una de las tres (una en el anfitrión y dos para las máquinas virtuales) instancias del sistema operativo que se estén ejecutando, aunque si permite dicho acceso concurrente en modo visualización.

¿Conclusión?

Apple ha hecho su entrada en la virtualización de una forma tímida, pero al menos lo ha hecho. Las restricciones impuestas por la compañía en los acuerdos de licencia no dejan mucho margen de maniobra. Para profesionales de IT no resulta espectacularmente útil, salvo para montar pequeños laboratorios o probar parches y configuraciones nuevas. Para los desarrolladores parece que si puede ser un escenario más propicio, ya que podrán “destrozar” el sistema a su antojo sin afectar al anfitrión.

Lo cierto es que este movimiento de Apple me recuerda bastante a las primeras andaduras con VMware Workstation, donde virtualizar un sistema operativo suponía poco más que una curiosidad para un profesional de IT. Y de aquellos tiempos mirad donde hemos acabado. Ojalá Apple vaya poco a poco siguiendo un camino parecido, ¿Quién sabe si dentro de poco podremos encontrar MacOS X como opción dentro de los pools de máquinas virtuales en las infraestructuras de VDI?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

Con la llegada del nuevo modelo de licenciamiento de la versión 5 de vSphere a muchos de nosotros se nos ha venido a la cabeza una de las preguntas lógicas, ¿Cuánto me va a costar actualizar mis licencias a vSphere 5?.

Como os comentaba la semana pasada, una de las características de este nuevo modelo, es que el licenciamiento se basa en el concepto de vRAM, por el que se licencia en base al total de la memoria provisionada a las máquinas virtuales.

Un detalle importante que recordar es que sólo se tienen en cuenta aquellas máquinas virtuales que estén ejecutándose.

Dándome una vuelta por Internet me he encontrado con un par de post bastante interesantes relacionados con este tema. En estos post se habla de cómo obtener la “huella” vRAM de vuestra infraestructura, dato bastante importante para hacernos una idea de lo que nos va a costar actualizarnos a vSphere 5.

El primero de los post, How to determine your vRAM footprint in vCenter, viene de la mano de VMguy y básicamente la opción que nos ofrece es exportar los datos de inventario de las máquinas virtuales en la vista “Hosts and Clusters” de nuestro vCenter a un fichero Excel y aplicar un par de fórmulas para obtener la huella vRAM. Rápido, sencillo y efectivo.

El segundo post, vSphere 5 License Entitlements, lo encontramos en Virtu-Al.net y consiste en ejecutar un script escrito en PowerShell. El script es bastante intuitivo y fácil de ejecutar. Simplemente tenemos que abrir una consola de PowerCLI y ejecutar el script LicenseValidator.ps1 que previamente nos hemos bajado de la misma web del post. A continuación nos aparecerá una ventana, tal y como podéis ver en la siguiente captura.

?

Ahora sólo basta suministrar los datos que nos solicita y hacer click en Connect para que el script recopile toda la información necesaria y nos la presente en un elegante informe HTML. La información completa la podéis ver en el mismo post, en un informe HTML de ejemplo.

Para terminar me gustaría que me permitierais la licencia de presentaros un pequeño OneLiner propio para PowerCLI para obtener la huella de nuestra infraestructura vSphere:

Get-VM | Where-Object {$_.PowerState -eq ‘PoweredOn’ } | Measure-Object MemoryMB –Sum

Que dará como resultado algo como esto:

Count : 12
Average :
Sum : 22016
Maximum :
Minimum :
Property : MemoryMB

Donde el campo Sum es el dato que nos interesa medido en MB.

Por explicar brevemente el oneliner comentaros que:

• Get-VM obtiene el listado de todas las máquinas virtuales de la infraestructura a la que estemos conectado.
• Where-Object {$_.PowerState -eq ‘PoweredOn’ }, es el filtro para quedarnos solo con las máquinas virtuales que estén encendidas, que son las que nos importan para obtener la huella vRAM.
• Measure-Object MemoryMB –Sum, realiza la suma de la propiedad MemoryMB (memoria provisionada a la máquina virtual) de todos los objetos que se le han pasado por la pipe.

Tened en cuenta que para poder ejecutar el oneliner anterior habéis tenido que conectaros previamente a vuestro vCenter con el cmdlet connect-viserver -credential (Get-Credential).

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

El pasado martes 12 de julio, VMware hizo la presentación de vSphere 5 cargado de nuevas funcionalidades y mejoras a las funcionalidades ya existentes.

Por hacer un breve repaso de las novedades que nos trae vSphere 5[SF1] , comentaros opciones nuevas bastante interesantes como:

• vSphere Auto-Deploy, que nos permitirá realizar despliegues automatizados de nuevos hosts ESXi de una forma más sencilla.
• vSphere Storage DRS, una funcionalidad que personalmente estaba esperando desde que cayó en mis manos el primer draft de SIOC (lo que por aquel entonces VMware decidió llamar PARDA), y que hace exactamente lo que parece que dice el nombre, es decir, reasignación dinámica del almacenamiento de máquinas virtuales.
• Profile-Driven Storage, una funcionalidad bastante interesante en la que mediante la configuración de perfiles de almacenamiento, vSphere nos informa de la compatibilidad de los datastores con nuestra máquina virtual. Básicamente consiste en definir un perfil de uso de almacenamiento basado en el nivel de servicio asociado a nuestra máquina virtual y en el momento de la creación, clonado o migración (storage vMotion) vSphere nos recomendará la mejor ubicación para la máquina virtual
• vSphere Web Client, con el que podremos administrar nuestra plataforma desde cualquier navegador web.
• vCenter Server Appliance, o lo que es lo mismo un vCenter basado en una virtual appliance de Linux (¡por fin!)

Por supuesto, la nueva versión de vSphere viene acompañada de mejoras de viejos conocidos:

• VMFSv5, soporta datastores de 64TB sin necesidad de usar extends
• Virtual Machine v8, con nuevas funcionalidades como el soporte de gráficos 3D para Windows Aero o dispositivos USB 3.0
• vSphere vMotion sobre redes de alta latencia
• máquinas virtuales más grandes de hasta 32 vCPU y 1 TB de memoria RAM.

En resumen un montón de nuevas funcionalidades que estoy deseoso de poder tocar y destripar de primera mano.

Sin embargo si hay algo realmente significativo que destacar de este nuevo lanzamiento de vSphere es su nuevo modelo de licenciamiento[SF2] , que ha sido, en el poco tiempo que lleva el producto en la calle, largamente comentado y rebatido.

Y el motivo de este intenso debate generado alrededor del nuevo modelo de licenciamiento es el cambio que hace VMware en la filosofía del modelo. La idea que subyace en este nuevo modelo, según VMware, es que ahora “pagas por uso” asemejándose más al mantra por todos conocidos del IaaS [SF3] .

VMware trata de conseguir su objetivo eliminando las limitaciones físicas asociadas al número de Cores por CPU que teníamos en la versión 4 e introduciendo un nuevo concepto, el pool vRAM.

Antes de entrar a ver en que consiste eso del pool vRAM, es importante mencionar que existe lo que VMware llama derechos de vRAM asociados a la licencia de vCPU y que evidentemente cambian según la versión de licencia [SF4] que estemos adquiriendo. De este modo para las ediciones:

• Standard, tenemos derecho a un máximo de vRAM de 24GB por CPU
• Enterprise, aumentamos la cantidad de vRAM hasta los 32GB por CPU
• Enterprise Plus, establecemos el valor de vRAM en los 48GB por CPU

Por cierto, si alguien ha notado la ausencia de la edición Advance, efectivamente VMware la ha eliminado del catálogo de la versión 5.

Volviendo al pool vRAM, ¿qué significa? Pues básicamente que en el nuevo modelo de licenciamiento tenemos derecho a ejecutar tantas máquinas virtuales como queramos siempre y cuando la suma de la memoria asignada a estas máquinas virtuales en ejecución no supere el tamaño del pool vRAM, que como habréis podido adivinar a estas alturas es la suma de las licencias de CPUs adquiridas.

De esta forma si tenemos dos host físicos con dos CPU (sin importar el número de cores) cada uno, dependiendo de la versión que adquiramos tendremos un pool vRAM de:

• Standard, 2 (hosts) * 2 (CPUs) * 24 = 96GB vRAM
• Enterprise, 2 (hosts) * 2 (CPUs) * 32 = 128GB vRAM
• Enterprise Plus, 2 (hosts) * 2 (CPUs) * 48 = 192GB vRAM

Es importante señalar que la vRAM no está asociada a un host sino al vSphere completo. Es decir, en el primer escenario, por ejemplo, si un host tiene asignado un total de 54GB de RAM a sus máquinas virtuales, y el segundo host tiene asignado un total de 38GB de RAM a sus máquinas virtuales, estaríamos cumpliendo con el acuerdo de licenciamiento, ya que 54 + 38 = 92 (RAM asignada) < 96GB (vRAM).

En este punto, creo interesante pasaros algunas referencias particularmente interesantes acerca del tema de licenciamiento, que como habréis podido suponer está bastante “calentito”:

• VMware’s Launch Event[SF5] , blog de Scott Lowe donde resume algunas de las novedades de la nueva versión de vSphere. Particularmente interesante la parte de comentarios donde se discute sobre el modelo de licenciamiento.
• vSphere 5 Licensing[SF6] , hilo de las communities de VMware donde se discute sobre el tema del licenciamiento.
• vSphere 5.0 Licensing Changes[SF7] , blog de Derek Seaman donde explica el modelo de licenciamiento. Particularmente interesante es el cálculo de costes de licencia que hace para una supuesta infraestructura de VDI.

Personalmente mi primera impresión acerca del nuevo modelo de licenciamiento ha sido bastante negativa, aunque con estas cosas me gusta darle un poco de tiempo al tiempo y ver si realmente existe un abaratamiento en los costes de licenciamiento tal y como asevera VMware, o a alguien se le ha “deslizado un cero” en los precios y el nuevo modelo es insostenible.

[SF2]http://www.VMware.com/files/pdf/vsphere_pricing.pdf

[SF3]http://es.wikipedia.org/wiki/Infraestructura_como_servicio#Infraestructura_como_servicio

[SF4]http://www.VMware.com/products/vsphere/buy/editions_comparison.html

[SF5]http://blog.scottlowe.org/2011/07/12/VMwares-launch-event/

[SF6]http://communities.VMware.com/thread/320877?start=0&tstart=0

[SF7]http://derek858.blogspot.com/2011/07/vsphere-50-licensing-changes.html

Uno de los aspectos más importantes de la configuración, o más bien de los ajustes de rendimiento, de un sistema operativo, ya sea Linux, Unix o Windows, es el correcto dimensionamiento del espacio de intercambio o del fichero de paginación de memoria.

Normalmente todos tenemos más o menos claro cuánto espacio tenemos que reservar para el área/fichero de intercambio: 2x(RAM física) para sistemas Linux/Unix y 1.5x(RAM física) para sistemas Windows.

Sin embargo estas reglas clásicas, y centrándonos ya sólo en la plataforma de Microsoft, puede que no acaben de tener mucho sentido, ¿o sí?

Permitidme un poco de bicefalia en el razonamiento sobre la decisión en cuestión:

• Por un lado el ahorro de espacio e IOPS a la hora de reducir el fichero de paginación
• Por el otro la disminución de carga administrativa al dejar que el sistema decida el tamaño del fichero de paginación.

Como con casi la mayoría de las cuestiones técnicas, la respuesta correcta siempre será “depende del caso” así que si os parece bien fijemos algunas variables para esta discusión:

• Tomaremos un servidor Hyper-V R2  (versión Core o Full)
• 96 GB de RAM
• Conectado a almacenamiento compartido (SAN o iSCSI con iniciadores hardware, lo que prefiráis en este punto)

Para el caso que discutimos otros aspectos como CPU o interfaces de red resultan poco relevantes.

Lo primero que observamos es que si aplicamos la regla tradicional del 1,5*(RAM física) el fichero de paginación se nos va a la nada desdeñable cantidad de 144GB (aquí caben un par de maquinitas virtuales sin muchos problemas). Si dejamos que el sistema gestione el archivo de paginación el tamaño es algo más pequeño (alrededor de los 100GB), pero aún un tamaño “interesante”.

Pero, ¿Cuál es la razón para querer tener un fichero de paginación tan grande? Siempre teniendo presente que estamos tratando con un servidor Hyper-V, el único motivo que se me ocurre para tener un pagefile.sys tan grande sería tener espacio suficiente para que en caso de que se produzca un error grave del sistema, este tenga espacio suficiente para hacer un volcado de memoria completo a disco.

No olvidemos un punto importante de la plataforma Hyper-V, y es que las máquinas virtuales consumen memoria física, nunca memoria virtual, por lo que en este aspecto, tener un fichero de paginación más grande no supone, bajo mi punto de vista, más que un desperdicio de espacio.

Por último, tener un fichero de paginación creciendo y decreciendo constantemente no hace más que derivar en una posible fragmentación del sistema de ficheros, por lo que si además si tenemos en cuenta que por defecto se ubica en el volumen de sistema, esta no es precisamente la mejor de las situaciones.

Así que teniendo en cuenta todo lo expuesto hasta ahora, además del hecho de que el dominio padre de un host Hyper-V “no hace más” que gestionar las peticiones de las máquinas virtuales alojadas en los dominios hijos y alojar los controladores para presentar el hardware a los dominios hijos, un fichero de paginación de entre 4 y 6 GB sería más que suficiente para un host Hyper-V.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Bicheando hoy un poco por la red, como suelo hacer todos los días a ver qué cosas de interés me encuentro, he descubierto este post en VMBlog.com de David Marshall en el que expone una breve entrevista a David Greschler (cofundador de Softricity App-V ) y Doug Brown (fundador de DABCC ) acerca de una nueva red social orientada a la Cloud, PaperShare.

A estas alturas de la película, cuando herramientas tan conocidas como Facebook, Twitter, LinkedIn y demás forman parte integrante de la cultura de Internet y casi de la vida diaria de más de uno de nosotros, venir hablando de “otra red social más” puede parecer un poco desfasado y hasta contraproducente.

Sin embargo si me atrevo a hablaros de PaperShare es precisamente porque no se trata de “otra red social más”. La idea que impulsa esta red social es la de compartir documentos, WhitePapers, Mejores Prácticas y en general cualquier documentación técnica de calidad relacionada con tecnologías que soportan y hacen posible la Cloud, desde virtualización de Datacenters, pasando por sistemas de DataRecovery o virtualización de escritorios, hasta la virtualización de aplicaciones.

En esta red social podremos encontrar tanto a usuarios normales de “a pie” (profesionales de IT), como podamos ser tu o yo mismo, como a Fabricantes de software o hardware, Integradores o Instructores.

Las condiciones y niveles de acceso dependerán del tipo de perfil de usuario con el que se acceda, donde el registro será gratuito para los profesionales de TI, a los que se permite la subida limitada de documentos y la creación ilimitada de grupos públicos, mientras que para el resto de perfiles, es decir, Fabricantes, Integradores o Instructores será necesaria una suscripción anual que dará derecho a la subida ilimitada de documentos y la creación de grupos privados.

Personalmente encuentro bastante interesante la vuelta que se le da al concepto de compartir documentación, ya que si bien es cierto que podemos encontrar estos documentos por la red, esta red social trata de centralizar, o al menos crear un punto de encuentro para la compartición de información y conocimiento. Si a esto añadimos la posibilidad que nos ofrece PaperShare de escribir reseñas sobre el documento que estamos leyendo, el punto de enriquecimiento del conocimiento incluido en el propio documento resulta bastante interesante.

Me llama particularmente la atención la definición que hace el propio David Greschler de PaperShare como red social:

“de alguna manera, lo que hemos creado es la inversa del modelo de red social. En lugar de que la gente venga al sitio porque fueron juntos a la escuela o porque trabajan juntos, vienen porque tienen el mismo interés. Pueden encontrar el contenido que quiere y conocer a gente y compañías que están interesados en el mismo tema”

Por último comentaros que en el día de ayer el número de documentos compartidos es de 5772, lo cual puede dar una orientación de la utilidad e interés de esta herramienta.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Seguro que no soy ni el primero ni el último consultor que ha escuchado o escucha a diario esta típica pregunta de parte de alguno de sus clientes.

Y es que la oferta de plataformas de virtualización es abrumadora, desde las tecnologías libres con las que poder montar plataformas serias de bajo coste, como puedan ser OpenVZ o KVM, pasando por las opciones gratuitas de los grandes fabricantes VMware ESXi , Microsoft Hyper-V o Citrix XenServer, hasta las soluciones comerciales, más potentes y llenas de funcionalidades espectaculares de los grandes fabricantes por todos conocidos.

Evidentemente la respuesta a la pregunta del título depende directamente de las necesidades y entorno particulares de la persona que nos hace la pregunta.

En esta ocasión me gustaría haceros partícipes directos de la respuesta a esta pregunta para un ámbito muy concreto, la integración de servicios en la nube. El motivo de trasladaros esta duda se debe a que recientemente en mi empresa hemos entrado a formar parte del Community Evaluation Program de Microsoft para evaluar la nueva Beta de System Center Virtual Machine Manager 2012.

Durante el proceso de evaluación del producto hemos podido ver nuevas funcionalidades, como la gestión de perfiles de hosts para la automatización del despliegue (el equivalente a los perfiles de host de VMWare), o las mejoras de Performance and Resource Optimization (lo que sería el equivalente al DRS de VMWare) e integración con Operations Manager, que realmente te hacen plantearte ciertas cosas que hasta el momento en el mundo de la virtualización las tenía como “indiscutibles”.

Quiero decir, clara y abiertamente, Microsoft, bajo mi punto de vista, está acercándose “peligrosamente” a VMware y además lo hace con un punto de calidad más que interesante.

Por supuesto, VMware sigue siendo el líder indiscutible y todavía hay una diferencia de maduración y calidad en su tecnología, y por supuesto también están preparando la salida de la nueva versión de su vSphere 5.

Pero llegados a este punto quizá haya otros factores, más allá de los puramente técnicos, que debamos plantearnos, o que al menos son los que a mí me hacen dudar seriamente entre ambas plataformas.

Uno de estos factores es la apuesta firme que hace Microsoft por las tecnologías Cloud, llevándose la mayoría de sus servicios a la nube, repartidos entre Azure, posibilitando el desarrollo de aplicaciones en la nube y Business Productivity Online Services, descargando del “lastre” de tener que andar desplegando servidores en la empresa para poder disfrutar de servicios como el correo electrónico, la mensajería unificada, portales (Sharepoint) u Office Communications.

Por supuesto, VMware también hace sus movimientos hacia la Cloud, de hecho lo lleva haciendo desde bastante antes que Microsoft. Sin embargo el nivel de integración o “integrabilidad” con los servicios que consumirá el usuario final no está tan trabajado, bien porque no sea el objetivo de VMware, por la masa de negocio en otros verticales de la que dispone Microsoft o por cualquier otro motivo.

Por último no debemos olvidar que la tecnología debe estar al servicio del negocio y no a la inversa, por lo que si bien creo que resulta bastante claro que VMware representa la excelencia técnica, no tengo tan claro que sea la mejor opción estratégica para según qué entornos, por ejemplo IaaS. Si tenemos en cuenta los costes finales a los que un posible proveedor de IaaS debe hacer frente si quisiera ofrecer este tipo de servicios, este puede ser un factor determinante a la hora de decantarse hacia una u otra plataforma.

Teniendo en cuenta todo esto… ¿Qué pensáis, VMware o Microsoft?

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Esta semana me gustaría permitirme la licencia de desviarme de los temas puramente técnicos y tecnológicos para desarrollar un poco más un concepto del que ya os adelantaba algo en el post de la semana pasada.

En este pasado post os hablaba acerca de la confianza asumida en los sistemas de seguridad de los bancos, y particularmente en el uso que hacemos de uno de sus sistemas más comunes, la tarjeta de crédito. En este punto me gustaría que pensemos en la tarjeta de crédito con cierta laxitud, es decir, pensemos en cualquier sistema de pago mediante tarjeta.

Hagamos un pequeño repaso de la historia de la tarjeta de crédito y de sus paralelismos con el Cloud Computing
.
La primera mención histórica que se hace al concepto de tarjeta de crédito viene de la mano de Edward Bellamy en 1887 en su novela utópica Looking Backward, donde Bellamy usará este término hasta en once ocasiones. En el caso del Cloud computing la primera mención al concepto es realizada por John McCarthy en 1960, donde decía que “la computación algún día estará organizada como una utilidad pública”.

Algunos años después de estas primeras visiones utópicas, el concepto de tarjeta de crédito empieza a materializarse en forma de tarjetas usadas para vender gasolina a los propietarios de automóviles a principios de 1920. Más tarde, en 1938, algunas compañías empezaron a aceptar las tarjetas de la competencia. En el paralelismo con el cloud computing, podríamos pensar en las apariciones, a principios de los 90, de conceptos como Grid Computing o Utility Computing, que si bien todavía no encajan completamente en el concepto de Cloud Computing, son claramente sus predecesores.

Volviendo de nuevo a la tarjeta de crédito, no será hasta 1950 donde Ralph Schneider y Frank McNamara, fundadores del Diners Club, implementasen la primera tarjeta de crédito que permitía realizar el cargo de una factura a dicha tarjeta, que sería abonado a finales del mes en curso.

En 1958, un competidor del U.S. Postal Service, American Express desarrollaría la primera red monetaria, en la que se permitiría las transacciones comerciales, usando su tarjeta de crédito, entre los clientes de American Express.

Poco después, a finales de los 60, aparecerían nuevas iniciativas como BankAmericard, lo que más tarde será Visa, o MasterChange, que pasaría a conocerse como MasterCard. La principal ventaja de estas tarjetas es que ya permitían realizar transacciones entre diferentes participantes, independientemente de que sean clientes directos de las entidades bancarias.

En este punto me parece interesante comentar las diferencias entre ambos sistemas:

• Sistemas de ciclo cerrado, en el que emisor de la tarjeta actúa como mero intermediario entre el cliente y el comerciante, como sería por ejemplo las tarjetas Diners Club o American Express.
• Asociaciones de tarjetas bancarias, en el que un grupo de bancos se asocian para crear una red de interoperación entre entidades. Esta asociación obligó a la creación de reglas de cooperación y transferencias de fondos entre bancos, que mejoraría de forma sustancial la seguridad y la operativa entre las entidades.

He querido pararme en estos puntos y en este momento porque se me vienen “sospechosos paralelismos” a lo que estamos viviendo hoy en día en el Cloud Computing. Si nos paramos a analizar por un momento el panorama de Cloud actual, vemos que nos encontramos en el punto en el que plataformas como Microsoft Azure, Amazon EC2, Google Apps o VMWare Cloud Foundry no dejan de ser “guetos” inconexos que recuerdan mucho a los modelos planteados por Diners Club o American Express.

Como ya comentaba, la seguridad en la nube o, mejor dicho, la confianza del usuario en la seguridad de la nube, es un requisito indispensable si queremos que dentro de poco oigamos cosas como: “voy a acercarme un momento al cajero que tengo que consultar la escritura de mi casa (o el informe que tengo que presentarme mañana a un cliente)”.

Afortunadamente, y haciendo el paralelismo con las tarjetas de crédito se ve de forma más o menos clara, se están dando los pasos oportunos y acertados, sólo es cuestión de seguir trabajando, desde todos los estratos, en la dirección en la que se ha seguido hasta ahora.

Puede que parezca de ciencia ficción, pero conceptos como El banco de datos no nos quedan tan lejanos…

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de
Twitter y Facebook de abajo o arriba. Gracias.