Hola a todos, soy Florián Murillo y como en mi anterior post, continuo hablando de seguridad y networking, con una breve introducción de VMware vShield Zones y su aportación a la seguridad.

El origen de este producto hay que buscarlo en Blue Lane, empresa adquirida por VMware hace año y medio, y el producto actual tiene sus orígenes en VirtualShield, un buen IPS para entornos virtuales que, en manos de VMware, tras integrarse con VMsafe (API de seguridad) y evolucionar, renace como vShield Zones.

vShield Zones nace como una pieza clave en la arquitectura cloud de VMware, conjuntamente con vCloud y otros productos que poco a poco se van orientando a gestionar clouds y no dataCenters.

Otros productos y funciones aportan seguridad a nivel de host y a nivel de red, vShield Zones añade, además, seguridad entre las máquinas virtuales y el hipervisor.

Las funciones de vShield Zones son tres :

1. Nos proporciona un firewall virtual con persistencia de sesiones y que maneja reglas L2, L3 y L4.
2. Registro y análisis de tráfico, para análisis forense o detección de tráficos anómalos.
3. Descubre y construye un inventario de sistemas operativos, aplicaciones y puertos abiertos.

El producto tiene 2 partes, el vShield Manager y el vShield Agent, ambos son Virtual Appliances que se instalan como archivos OVF.

El vShield Manager monitoriza, configura y actualiza los vShield Agent que desplegamos sobre la infraestructura virtual, y como ya habéis intuido, los agentes se encargan de aplicar las reglas de firewall, de “capturar” el tráfico entrante y saliente, así como detectar S.O. y aplicaciones para construir el inventario en el vShield Manager (ver imagen siguiente).

VMware vShield

La arquitectura de distribución de los agentes de vShield Zones nos recordará a la disposición de los firewalls físicos que protegen DMZs, y la finalidad es la misma, en la imagen siguiente podemos ver el antes y el después de la instalación de un agente para securizar un Port Group llamado Servers.

Desde el vShield Manager le aplicaremos las políticas al agente y quizás os preocupe el hecho de que el port group Servers está conectado a un switch interno, imposibilitando el funcionamiento de vMotion, pero esto lo arreglaremos añadiendo en parámetro VMOnVirtualIntranet con el valor “false” en el archivo vpxd.cfg, este archivo lo encontrareis en la instalación del vCenter.

Me reservo para otro post la integración de los agentes de vShield Zones con los Virtual Service Domain de Cisco Nexus 1000V, nos elevará la seguridad de vShield Zones al siguiente nivel (opss, parece un juego).

No es el único producto para llevar la seguridad hasta el port group, existen otros productos interesantes como VMC de Reflex Systems o Virtual Network Firewall de Altor Networks, ¿estamos entrando en la era de los Virtual UTM Appliances?

Por todo lo comentado llegamos a hacernos preguntas en la línea de mi último post, ¿puede un experto en seguridad aplicar este nivel de seguridad sin conocimientos de vSphere y de networking?

La licencia Enterprise Plus de vSphere incluye un nuevo tipo de switch, el Distributed Switch que aporta mejoras en calidad de servicio, seguridad, escalabilidad y explotación respecto al clásico Standard Switch de siempre.

Sin embargo esta licencia permite, también, utilizar (comprándolo adicionalmente) el primer switch virtual de Cisco, el Cisco Nexus 1000V, pero ¿Que ventajas aporta este switch respecto al Distributed Switch para que merezca la pena pagar un dinero extra?.

Como todo en la vida, para algunos será necesario y para otros no, pero hablemos brevemente de algunas de las características que lo diferencian del vDS :

En VI3 v3.5 se incorporaba NetFlow en modo experimental (y funcionaba muy bien), pero en vSphere ha desaparecido, si queremos registrar los flujos de información que pasan por nuestros switches virtuales, fundamental para análisis de comportamiento de las aplicaciones y para detectar flujos sospechosos, hemos de utilizar Cisco Nexus1000V.

Si necesitas enviar los logs de los switches virtuales para correlacionarlos con los del resto de los switches físicos, Cisco Nexus 1000V te lo proporciona.

Cisco Nexus 1000V soporta ACLs utilizando direcciones MAC o IP y se aplican a nivel de puerto, dicho de forma rápida tenemos un firewall en cada puerto y se mueve con la VM al cambiar de ESX, es una buena ayuda en lo que a seguridad se refiere.

Otras medidas de seguridad son DHCP snooping y IP Source Guard que mitigan ataques man-in-the-middle o Dynamic ARP Inspection que nos protege de ataques ARP spoofing.

Además puede trabajar en combinación con VMware vShield Zones, blindando nuestra infraestructura y facilitando la administración de la seguridad con herramientas gráficas.

Nos aporta diversos mecanismos de QoS : Mecanismos de clasificación de tráfico por diversos criterios, técnicas de marcado de tráfico y políticas de QoS. Todo ello utilizando los comandos Cisco IOS y llegando a garantizar un ancho de banda a un tráficos determinado !!!!

Y los entusiastas de Cisco están de suerte, se configura mediante Cisco CLI y con los comandos que ya conoce y muchos mas.

Como vemos la seguridad, las redes y los sistemas, ya no son especialidades diferentes, están naciendo los especialistas en DataCenter … ¿te apuntas?

La semana pasada te mostre como activar y configurar Jumbo Frames en un switch virtual.

En este otro episodio te mostrare a configurar Jumbo Frames en una máquina virtual Windows 2003 con el driver virtual vmxnet para una tarjeta a un Gigabit.

De esta forma tendrás Jumbo Frames configurado en todos los compoenens de tu entorno Virtual. No olvides de asegurarte que el switch físico en el que conectamos la tarjeta de red física de tu red iSCSI tiene también activado el soporte Jumbo Frames.

En caso de que tu switch físico no tenga soporte Jumbo Frames, es aconsejable no configurar Jumbo Frames en nuestro servidor VMware ni máquina virtual por razones obvias.

Muchos son los emails y llamadas que he recibido durante años sobre si Oracle está soportado en VMware. Pues bien, puesto clara y llanamente, si Oracle está soportado o no, dependerá del departamento en Oracle con el que hables. Me explico:

El equipo de preventa en Oracle es posible que te diga que Oracle no está ni certificado ni soportado en VMware pero si miras el articulo creado por el equipo de soporte en Oracle (metalink número 249212.1) dice lo contrario, o al menos, viene a decir que esta soportado aunque no certificado.

Oracle soporta sus productos en VMware. Esta política ha estado presente por más de dos años y no ha cambiado. Mientras que Oracle no está certificado en VMware, el articulo en el meta link claramente especifica las condiciones bajo las que Oracle ofrecerá soporte a clientes con VMware.

Si la capa de virtualización de VMware es el responsable del problema, entonces el departamento de soporte de VMware asistirá al cliente a solventar dicho problema.

Asimismo, Oracle VM es la única solución&plataforma de virtualización certificada y soportada para los productos de Oracle – Good for them.

Tip: La experiencia con el departamento de soporte de Oracle y con mis clientes corriendo Oracle bajo VMware es, ciertamente, muy positiva. Nunca he tenido ningún problema con Oracle cuando hemos necesitado (en muy contadas ocasiones) su soporte.

Y ciertamente, dependerá del departamento con el que hables: soporte, sales o marketing, – Oracle estará o no soportado sobre VMware. Triste pero cierto.

Ahora cuando te digan que no está soportado, primero, pregúntales para que departamento trabajan y, segundo, podrás enseñarle el metalink número 249212.1

Update1: Tabla comparativa de funcionalidades de vScout .vs vComander.

Hola, como estáis?.

Pues ya sabemos aquello que “virtualizar y rascar, todo es empezar”. Empezamos virtualizando una máquina de pruebas, después una no-crítica, vemos que aquello funciona bien, continuamos con los medio-críticos, nos damos cuenta que precisamente lo que tiene que estar virtualizado es lo crítico y terminamos virtualizando el escritorio del Director General. ¿Os suena?

En medio nos damos cuenta que nos falta RAM, que los procesadores… bueno. Vale, tenemos todo virtualizado, hasta los enchufes del Datacenter (verdad Iván ) y entonces vemos unas vm sospechosas. Hummm Que son estas VM? Ya, una copia de cuando estornudó el DC, vale, y esta? pues no recuerdo, estaba de baja….. y encima máquinas de prueba y otras historias.. sprawl…. (un amigo mío lo traduce por desparrame…)

Hay quien lo gestiona con un Excel, lo puedes hacer con vScout de Embotics. Herramienta gratuita que te inventaría las VM a la vez que te permite darle atributos especiales de gestión administrativa.

¿Como lo gestionamos?. Download desde su pagina web y lo instalamos sobre un 2003 con IIS. Conectamos vScout a nuestro vCenter y ya se nos presenta una pregunta que vaticina cosas “Marcar todas las VM como aprobadas”. Quitamos el check para que no las apruebe y conectamos.

Nos aparece este inventario (en este caso están aprobadas), donde una a una o bien por lotes podremos indicarle si la VM tiene fecha de expiración o no, y si la tiene, cuando expira. Le podremos indicar quien es el “owner”, si es que ya tiene el ciclo de vida caducado y bien si es “sospechosa” (quiere decir que no sabemos de donde viene la VM y la vamos a investigar).

También podemos tener atributos “customizables”, creando nuestros propios campos (hora cuando hacemos el backup de esta máquina, si hay alguna tipo de requerimiento especial, etc).

En mi caso, cuando he terminado de establecer los datos de una VM, genero un PDF de la cuenta de la VM y se la envío al Owner. Cuando llega el fin de ciclo de vida de la VM, sé a quién tengo que avisar, le envio otra vez el PDF y sencillamente la paro en 48 horas. La guardo en una carpeta administrativa “To be deleted” y después de un tiempo de caución se borra.

Espero que os sea interesante.

Hasta la semana que viene.

Es un placer para el Blog de la Virtualización en Español dar la bienvenida a VizionCore nuestro último sponsor y empresa con reconozidas soluciones innovadoras para la plataforma VMware desde el año 2005.

Vizioncore es una empresa líder de la virtualización y cuenta con más de 18.000 clientes (desde PYMES a grandes empresas). VizionCore fue fundada en 2002, y es un proveedor líder de soluciones de administración de virtualización de servidores.

Vizioncore es el único proveedor de la actualidad que comercializa un completo conjunto de soluciones para gestionar, controlar y proteger de forma completa los entornos virtuales durante todo su ciclo de vida.

Las soluciones de Vizioncore permiten a los usuarios analizar, convertir, proteger, supervisar, optimizar y automatizar la infraestructura virtual para obtener el máximo rendimiento y tiempo de funcionamiento de sus sistemas. Hoy por hoy, miles de clientes de todo el mundo (desde PYMES a organizaciones empresariales) utilizan las soluciones de Vizioncore porque son fiables, efectivas, fáciles de usar y asequibles.

Vizioncore es una empresa subsidiaria independiente de Quest Software, proveedor líder en la administración de sistemas empresariales. Actualmente, Vizioncore distribuye sus productos a través de una red de asociados extendida de 2.200 revendedores de valor agregado en todo el mundo.

Para obtener más información, visita www.vizioncore.com o www.vizioncorum.com, el sitio oficial del blog de Vizioncore Inc., o pónte en contacto a través de la dirección sales @ vizioncore.com.

La funcionalidad de memory overcommitment es y ha sido una ventaja evidente que VMware tiene sobre su competencia. Es una de las razones fundamentables por las que el ratio de consolidación con VMWare es mayor “teóricamente” que con otras soluciones de virtualización.

Ciertamente muchos de mis clientes y estudiantes se “enzarzan” en un debate abierto sobre el beneficio real de dicha tecnología. Recuerdo muy vivamente aun hoy, después de casi dos años, a Microsoft Iberia contándonos en el primer curso oficial de Microsoft Hyper-V (beta), que el memory overcommitment no tenia realmente ningún beneficio, supongo que cambiaron de opinión?

Al parecer, según una notica publicada en news.softpedia.com, Windows Server 2008 R2 Build 6.1.7700.0.100122-1900 traerá la funcionalidad de memory overcommitment en el próximo Service Pack en Microsfot Hyper-V.

Esta nueva funcionalidad permitirá a los clientes especificar una cierta cantidad de memoria RAM con que el sistema operativo virtual arrancara, y una cantidad de memoria máxima (limit) que el sistema podría utilizar, algo que VMware ya tenía desde hace muchos años, gracias a Dios, pero que desde el Blog de Virtualización en Español alagamos.

Puedes leer la noticia completa en este enlace:

http://news.softpedia.com/news/The-Windows-8-Start-Post-RTM-Windows-7-Build-6-1-7700-0-100122-1900-133746.shtml

Vamos a ver la instalación y configuración de Datacore SANmelody. Los requerimientos mínimos son servidor con Windows 2008 (x86 o x64) con una CPU de 2 cores (1 lo usa Windows y el otro Datacore) y memoria RAM (entendiendo que el ratio es de 20% de la memoria la usa Windows mientras que el 80% restante la usa Datacore como Caché). Microsofot .NET Framework 3.5. Lista total de requerimientos, aquí.

Vamos a usar para este laboratorio un viejo conocido, dos HP ML110 con 1 Xeon 2 nucleos y 8 Gb de RAM, uno como ESX y el otro comoDatacore. La topología a implementar es ésta. Simplificamos la red de storage con un simple cable cruzado para iSCSI entre los servidores.

Instalamos Windows 2008 en el servidor que tenemos preparado a tal efecto y le aplicamos todos los updates disponibles. A continuación le asignamos 2 ip fijas, una para administración y la otra para el Target de iSCSI. Como recomendación, deshabilitamos las actualizaciones (así evitamos reinicios no esperados). Se desaconseja que el servidor sea parte de nuestro Directorio Activo, así como se aconseja que se instale windows 2008  en su versión inglesa para un mejor soporte a la hora de compartir los posibles mensajes. Como es un “labo” y tan sólo tengo un 2008 español, “pues eso….”

En este caso tenemos 2 discos de 250 no usados, los inicializamos con GPT y los dejaremos Básicos y sin formatear.

Instalamos el software de SANmelody por defecto, incluyendo la licencia evaluación, trial o adquirida que tenemos cuando nos los indique, poco más que “siguiente, siguiente”. Reiniciamos.

Antes de nada, vamos a hablar de los términos en que “habla” Datacore. Un nodo Datacore como es éste SANmelody que estamos instalando es denominado Storage Server, mientras que nuestros ESX o Windows o máquinas que accedan a los recursos serán denominados Application Server y los recursos mostrados por el Storage Server son Virtual Volumes.

Otra característica de Datacore es que mientras otros sistemas presentan el target y el initiator los decubre y asigna, aquí, después de que el Initiator haya inicializado el canal, Datacore asigna un Virtual Volume a un Application Server mediante un Channel. Para mí es un método seguro para que no te levanten las LUN por error en una instalación, por ejemplo.

Continuamos, en la barra de estado vemos un icono de Datacore, botón derecho y seleccionamos Open computer Management, con elloaccedemos a la cónsola donde vemos un Snap-in de Datacore. Lo abrimos y accedemos sobre el Storage Server

Nos indica que el Storage Server está parado y que debemos ponerlo en marcha.

Aceptamos el mensaje y vamos a la barra de tareas y buscamos el botón de arrancar el servicio, lo arrancamos y podemos ver abajo una característica que debemos tener en cuenta. Cuando iniciemos el servicio nos dirá “Running – Not applied”. Casi todos los cambios que hagamos van a quedar “sin aplicar” hasta que no hagamos un “Apply configuration”

Con esto tenemos nuestro Storage Server preparado para crear recursos a compartir, o Virtual Volumes.

Accedemos en la misma cónsola al snap-in de administración de discos, seleccionando los discos que hemos dejado sin usar antes e inicializados. Botón derecho sobre el disco que deseamos convertir en Virtual Volume, Nuevo volumen simple, el tamaño que deseamos (todo el disco en este caso) y muy importante! “No asignar una letra o ruta de acceso de unidad” y “No formatear este volumen”. De esta forma nos queda un disco con una particion “Raw”, sin letra asignada ni formateado.

El siguiente paso es “Proteger” esta partición. De esta forma es Datacore quien gestiona la partición y prevenimos usos accidentales desde Windows. Para ello vamos al Snap-in Datacore y sobre Storage Server, botón derecho “Protect all volumes”, el sistema nos contestará OK.

Pero el Volume1 nos aparecerá en rojo como indica el grafico. Que ocurre? Volvamos atrás y recordemos que casi todos los cambio precisan de un “Apply” y el sistema nos está diciendo “Tengo el cambio en buffer, pero no lo he aplicado, los aplicaré todos cuando hagas el Apply”.  Lo hacemos.

Con un volumen creado, vamos a hacer un Virtual Volumen que vamos a  llamar VVproduction1. Nos posicionamos sobre Virtual Volumes, botón derecho, New Virtual Volume y nos aparece la siguiente ventana. En Name indicamos VVproduction1, seleccionamos el volumen disponible y con la flecha verde y OK obtenemos un Virtual Volume pendiente de hacer Apply. Aplicamos.

Nos trasladamos ahora a nuestro ESX.  Siempre será mejor si desde nuestro service console hacemos un vmkping a la ip del target de Datacore. Configuration, Storage Adaptors y nos posicionamos sobre nuestro adaptador de iSCSI por software (doy por sentado que hemos configurado el firewall y el initiator). En Properties, Tab Dynamic Discovery, Add, podremos incluir la dirección de la ip del target del STorage Server, 10.10.10.xx. Verificamos en Static Discovery y vemos el iqn de nuestro Datacore. Al salir, hacemos rescan.

Para comprobar que tenemos establecido el enlace, desde Datacore, en iSCSI Manager, sobre el NIC que enlaza con el ESX y podremos ver el iqn de nuestro ESX1. Tenemos el enlaze correcto. Tan sólo nos queda mapear el Virtual Volume con el ESX1 a través del Channel establecido. Nos posicionamos sobre Datacore Snap-in, sobre Application Servers, botón derecho, New Application Server. Damos nombre al Application Server, ESX1 e indicamos que el tipo es VMware ESX.

Sobre el Application Server ESX1, botón derecho, propiedades, Channels, señalamos el Channel del iqn del ESX y con la flecha verde lo pasamos a Assigned channels. Aceptamos y hacemos “Apply”.

Mapeamos el Virtual Volume con el Application Server mediante el channel establecido. Para ello nos posicionamos sobre Application Server, Map New Virtual Volume, obteniendo la siguiente imagen. Seleccionamos el Virtual Volume VVproduction1 con el Channel ESX1_! del Application Server ESX1. Ok y hacemos “Apply” y con eso hemos concluido.

Nos vamos a nuestro ESX, Storage, Add Storage, Disk/LUN, y ahí vemos el identificador de la LUN disponible de Datacore. Creamos la partición, lo formateamos y le damos nombre.

Tras un breve espacio de tiempo tendremos un Datastore disponible para nuestras VM.

Me acaban de llegar a las manos las hojas técnicas de los nuevos servidores de Cisco.

Mucho hemos oído hablar de que Cisco quería entrar en el tema de Servidores de la mano de su coalición con VMware. Y aquí están.

Os presento al UCS C200 M1 High Density Rack-mount server. Servidor de 1U con 2 sockets y con 12 slots de memoria, llegando a poder instalar 96 Gb con alta densidad o bien llegar a tasas altas con precios asequibles.

Incorpora 2 Nics de 10 Gb y un nuevo chipset que es capaz de gestionar la memoria para ofrecer más memoria de la que realmente tiene (me han dicho un número de veces que quiero antes validar.)

A ver si me cae uno en demo y os cuento cosas bonitas sobre ellos….. también hemos de ver los precios.

Podéis ver una demo interactiva en este link

¿Hola que tal de nuevo?. Pido mis disculpas a José María y todos nuestros lectores por el retraso en mis POSTS ya que he tenido un ligero contratiempo a lo largo de este mes que me ha hecho ir más lento con vosotros de lo que yo quisiera.

Una vez explicado esto, quería haceros llegar algo que ya he probado y que me ha sorprendido por su funcionamiento con un programa de almacenamiento SAN como es Openfiler (Código Abierto). Como realizar un Cluster entre SAN con Openfiler para la redundancia de nuestras VMs?.

Mirando en varios Blogs y otros donde ponían como realizarlo (HOW to) os transmito paso a paso como realizarlo. Aunque cabe reseñar antes de empezar, que todo se basa en el protocolo DRDB, el cual es básicamente una replicación continua vía TCP/IP mediante nuestra red Ethernet.

Lo primero es descargar e instalar openfiler en las dos máquinas. Hay una imagen para x86 o para x86_64 según las máquinas de que dispongáis. Durante la instalación, haced las particiones idénticas en los dos servidores, y cuando reiniciéis, os tendréis que asegurar que no se montan las particiones que se van a replicar entre los dos servidores. En mi caso, hice el siguiente particionado:

• /dev/hda1 — /boot – 150MB
• /dev/hda2 — / — 10GB
• /dev/hda3 – swap – 1024MB
• /dev/hda5 – 512MB – Será donde guardemos los ficheros de config para el cluster.
• /dev/hda6 – 12,9 GB – Haremos un share SMB
• /dev/hda7 – 12,9 GB – La usaremos como target iSCSI para VMWare

Para que nos quede un poco mas claro, las particiones que replicaremos serán las de datos y la de configuración del cluster. Las de sistema no será necesario replicarlas ya que el sistema está instalado en ambos nodos. Aseguraos también de que los dos nodos resuelven correctamente el nombre del otro y opcionalmente, montad la autentificación por claves de ssh, para no tener que escribir el password cada vez que hagáis un scp.

DRBD

Montar drbd es bastante sencillo. Lo primero que tenéis que hacer es aseguraros de que las particiones estén vacías, ya que es muy probable que durante la instalación hayáis creado un sistema de ficheros sobre ellas. Si fuese así:

dd if=/dev/zero of=/dev/hdaX bs=1M count=1

Con esto borráis las particiones y las dejáis impolutas para que podáis empezar a replicar. Lo siguiente, editamos el fichero /etc/drbd.conf en el nodo 1. Ahí tendremos que especificar un par de opciones generales y los arrays que váis a crear:

Ejemplo del fichero de configuración.

Luego lo copiamos al nodo 2. Una vez tenemos el fichero de configuración podemos crear los arrays (esto hay que hacerlo en ambos nodos):

• drbdadm create-md cluster_metadata
• drbdadm create-md vg0drbd
• drbdadm create-md vg1drbd

Y arrancamos el servicio drbd en los dos nodos. Si miráis el fichero /proc/drbd, veréis que el estado de los discos es inconsistente y que ambos nodos estan como secundarios. Así que en el nodo 1 hacéis:

• drbdsetup /dev/drbd0 primary -o
• drbdsetup /dev/drbd1 primary -o
• drbdsetup /dev/drbd2 primary –o

Con esto hemos puesto al nodo 1 como primario en todas las particiones que gestiona drbd. Ahora si miráis el /proc/drbd, veréis como está replicando los datos. Ahora hay que añadir drbd al inicio del sistema y ya de paso, creamos el sistema de ficheros en la partición que nos guardará los ficheros de configuración del cluster.

• chkconfig –level 2345 drbd on (en ambos nodos)
• mkfs.ext3 /dev/drbd0 (en el nodo 1)

En este punto, con los arrays creados, nos referiremos siempre al los dispositivos drbd para I/O para cualquier operación con discos.
Siguiente, editamos el fichero /etc/lvm/lvm.conf y cambiamos el filtro de esto:

• filter = [ "a/.*/" ]

a esto:

• filter = [ "r|/dev/hda*|" ]

y procedemos a crear el physical volume sobre drbd1 (el otro sera sobre drbd2, ya que el 0 no será gestionado por lvm).

• pvcreate /dev/drbd1

En la siguiente parte, te contare la parte del heartbeat y de como terminar la configuración de drdb.

Hasta la próxima semana.

Irene Kalmykova, Sales Director de 5nine.com, se ha puesto en contacto con el blog de virtualizacion en Español para dar a conocer sus últimos productos P2V & V2V para Hyper-V y VMware vSphere.

5nine P2V Planner, crea migraciones P2V automatizadas y personalizadas para Microsoft Hyper-V y VMware vSphere. Este software P2V no solo realiza la conversión de físico a virtual con un gran porcentaje de éxito sino que además te proporciona una comparación tipo TCO/ROI sobre cuál es la solución mas adecuada, VMware vSphere o Microsoft Hyper-V.

Estoy deseando probar esta nueva funcionalidad en mis conversiones de físico a virtual.

Otra de sus soluciones, 5nine Virtual firewall para Hyper-V, monitoriza y controla el tráfico entre máquinas virtuales de Microsoft Hyper-V y la red externa (y viceversa).

La buena noticia es que la versión actual es gratuita y está disponible para su descarga en su web.

La mala noticia es que la próxima versión, que será lanzada a fines de enero, será un producto de pago, con lo que yo que tú me daría prisa en bajarme la versión gratuita para poder jugar con ella.

Update 1: Si vas a asistir al evento de Magirus OpenHouse y eres asidulo lector de este blog, por favor, mandame un email a mi direccion personal y te entregare una camiseta especial del Blog de Virtualización en Español durante el evento. Por favor, incluyeme en el email tu talla para no equivocarme

Un año más, Magirus OpenHouse’10, es el punto de encuentro anual en el que se darán cita fabricantes, partners y clientes finales.

Magirus OpenHouse’10 girará en torno a un tema protagonista: Cloud Computing. Magirus, en esta nueva edición, se ha propuesto demostrar cómo todas las tecnologías giran alrededor de “La Nube”.

El evento es gratuito y se celebrará en Madrid, el jueves 4 de febrero de 2010 y es dirigido a resellers, integradores, ISPs, consultores y clientes finales.

Pedro Llamas, monologuista de la Paramount Comedy, hará de maestro de ceremonias dando un toque de humor a las sesiones. Así mismo, contaremos con la inestimable presencia de César Pérez de Tudela, uno de los exploradores más influyentes y mentalizadores de la aventura y el alpinismo. Con él, tendremos una visión diferente de “La Nube”.

El evento dispondrá de espectáculo en directo, regalos para todos los asistentes, sorteos en cada ponencia, y muchas cosas más. Asimismo, mi presencia tambien esta confirmada con lo que tendre el placer de conocer a tantos lectores del blog como pueda y quizas si la logistica me lo permite podre repartir algunas copias de mi ultimo exito: 101 Secretos de VMware vSphere.

Recuerda que para incribirse al evento has de hacer clic en este enlace y que la direccion es la siguiente: Hotel Puerta América. Avenida de América, 41. 28002 Madrid

Nos vemos en el Magirus OpenHouser’10

La semana pasada Microsoft y HP anunciaron un acuerdo de colaboración millonario – $250 millones de dólares – para ofrecer directamente en partnership, un nuevo modelo de infrastructure-to-application y soluciones avanzadas de cloud computing para reducir los costes y la complejidad de TI.

La virtualización es, por supuesto, el centro de atención del partnership entre Microsoft y HP. Las nuevas soluciones basadas en infraestructura HP y software de virtualización de Microsoft, Hyper-V, en teoría, permitirán a los clientes acelerar el tiempo de despliegue de las aplicaciones, reducir el tiempo de caída no planificada, y reducir los costes de infraestructura.

Este es, sin lugar a dudas, un gran compromiso por parte de ambas empresas. El acuerdo, establece tres componentes principales:

• Una hoja de ruta común de ingeniería para garantizar una integración sólida entre el hardware y software de las dos compañías, Microsoft y HP.
• Soluciones conjuntas para optimizar y simplificar el despliegue, gestión y “salud” del centro de datos.
• Una inversión inicial en el departamento de ventas, de servicios y para los programas del canal.

Puedes ver el comunicado de prensa en este enlace, y los videos ejecutivos y más información adicional en este otro enlace.

Habrá que ver, que clientes se decantan por utilizan HP + Microsoft Hyper-V en la nube y cuales se deciden por usar Hp + VMware vSphere …. y lo mas importante, cual es el factor de elección de una solución vs la otra por parte del cliente?. El tiempo nos dirá.

Channelpartner, editorial especializada en publicaciones periódicas de Tecnologías de la Información, me acaba de publicar un artículo sobre cómo ahorrar dinero con el Cloud computing en su sección de la voz del experto.

El ahorro que decenas de miles de empresas han generado con el despliegue de esta tecnología, está impulsando, de una forma más pronunciada y rápida, la adopción de de la tecnología de virtualización, desde el centro de datos hasta el escritorio.

En este artículo pretendo aclarar los beneficios potenciales cuando virtualizamos el hardware x86, los puntos fuertes y los ahorros tangibles que el uso del software de virtualización de servidores ofrece, con un ejemplo muy sencillo y muy práctico.

En este ejemplo sencillo y práctico, una empresa española pequeña/media que cuenta con 100 servidores físicos en sus instalaciones, y que contacta con JmG Virtual Consulting – mi empresa de servicios de consultoría de virtualización – para abordar un proyecto de virtualización del centro de datos, puede ahorrar mas de 65.000 dólares al año, solamente en ahorros de electricidad.

Puedes ver el artículo completo en este enlace:

http://www.channelpartner.es/Voz/201001080036/Ahorra-dinero-con-Cloud-Computing.aspx

Espero que te guste. Tus comentarios sobre el artículo son más que bienvenidos.

La alianza estratégica entre Citrix y Microsoft garantiza que Essentials for Hyper-V funcione de manera transparente con el nuevo Windows Server 2008 R2.

Con Citrix Essentials los que trabajan con Windows aprovecharán al máximo las soluciones de virtualización. Citrix Essentials for Hyper-V5.5 ofrecerá mayores opciones de control tales como la tecnología Citrix StorageLink.

Podéis obtener mas información en el siguiente enlace:

http://www.citrix.com/English/ps2/products/subfeature.asp?contentID=1686952

Saludos y hasta la próxima semana.