Hola de nuevo. Soy Miguel ángel Alonso y aquí estoy de nuevo contigo para contarte algo nuevo sobre el apasionante mundo de la virtualización de sistemas.

En el tema de hoy voy a hablarte de una nueva funcionalidad a nivel de Red que no es otra que la tarjeta e1000e, la cual soporta adaptadores Pci-Express y será por defecto la tarjeta de los nuevos Windows 8. Esta tarjeta es una emulación de las Intel 82574L Gigabit Ethernet, y sólo está disponible en vsphere 5 con hardware 8.

El tema de hoy viene dado para explicarte como habilitarla, ya que de por si no viene activada y no puede hacerse a nivel de GUI.

Lo primero que deberemos es descargarnos el siguiente script desde esta página: http://communities.vmware.com/docs/DOC-12417

Cuando elegimos de manera normal una tarjeta de red para nuestra VM veremos algo como te muestro en la foto de la cabecera de este post.

Pero si ejecutamos el script que hemos descargado podremos ver algo como esto en nuestra consola del vMA:

Y finalmente podremos tener acceso a la nueva tarjeta de red una vez la hemos activado con el correspondiente script:

Por fin podremos disfrutar de esta nueva tarjeta que nos ofrece vSphere 5 en nuestros entornos y poder sacar todo el beneficio que esta nos pueda dar.Bueno, me despido de vosotros esperando haberos podido contar algo de vuestro interés. Hasta el próximo martes y un saludo.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Ferran Serafini y hoy vengo con un tema sencillo y a la vez muy potente. Seguramente habrás visto en XenCenter que los interfaces de red te permiten configurar QoS. Vamos a ver hoy, como implementarlo en nuestro entorno de virtualización con XenServer.

El QoS (Quality of Service) nos puede ser muy útil en entornos donde tenemos grandes tráficos de red y a su vez estos, sean limitados, hayamos detectado problemas, o bien necesitamos restringir el ancho de banda sin dejar de dar servicio a ciertas máquinas virtuales, etc.

Mediante QoS, XenServer permite establecer a nivel de red qué máquinas virtuales van a estar restringidas y cuáles no.

En algoritmo de XenServer para  QoS de red, se asocia a cada dispositivo VIF (Virtual Interface), por lo tanto se aplica a cada interface de red de cada máquina virtual. De este modo es posible tener una máquina con un interfaz limitado a 300 KB/s y otro a 1000KB/s. El valor que podemos establecer es la tasa máxima de transferencia.

Desde la CLI podemos configurarlo mediante:

xe vif-param-set uuid=<uuid_vif> qos_algorithm_type=ratelimit

xe vif-param-set uuid=<uuid_vif> qos_algorithm_params:kbps=300

Esto es todo por hoy, espero como siempre, haberte aportado algo nuevo e interesante. ¿Utilizas QoS en tu entorno, si es así que política establesces, criticidad de la máquina, segmento de red, etc?

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

Hola amigos, soy Florián Murillo. Estamos en un entorno muy cambiante, tanto que lo DICHO este mes puede quedar obsoleto el mes próximo… Por ese motivo, durante las próximas semanas, desarrollaré el estado ACTUAL de las tecnologías Cisco relacionadas con el Virtual Networking.

¿Qué es Virtual Networking?

Es la virtualización de la capa de acceso de switches; aquellos switches donde están conectados los servidores que también vamos a virtualizar.

O lo que es lo mismo: Los switches virtuales donde están conectados los servidores (ahora virtuales).

Se esquematiza en la figura siguiente:

Esto es lo que hace que los responsables de configurar los switches físicos a los que se conectarán los hosts ESX/ESXi deban pensar en estos hosts como switches, ya que en realidad están conectados a switches (virtuales).

Características únicas de los switches virtuales:

1. Los switches virtuales no se pueden apilar entre ellos, solo podemos conectar a un switch virtual interfaces físicos del host, las vNICs de las VMs y los puertos de servicio del kernel (vmk y vswif).
2. Los switches virtuales no tienen spannning-tree (STP), por tanto recordar deactivar STP en los puertos de los switches físicos donde se conectan los hosts ESX.
3. Los switches son de nivel 2 (L2), es decir, requieren “ayuda” externa para encaminar tráfico entre VLANs.

Cisco entra en el Virtual Networking con la llegada de vSphere 4 y concretamente utilizando la vNetwork Appliance API.

El switch virtual distribuido (dvSwitch) es un elemento básico para la implantación de grandes infraestructuras virtuales y, por extensión, para el despliegue de soluciones IaaS bajo el modelo de cloud computing. El elemento diferencial es su arquitectura. Las configuraciones se despliegan automáticamente a todos los hosts que participan en el dvSwitch, sin necesidad de repetir el cambio host por host, como ocurre con el vSwitch clásico de VMware.

El dvSwitch aporta funcionalidades nuevas respecto a los vSwitches, que podemos resumir en Seguridad, QoS, Gestión y Arquitectura abierta.

Cisco basa su arquitectura de Virtual Networking en Cisco Nexus 1000V, que incorpora características adicionales respecto dvSwitch.

Desde su aparición en el 2009, han aparecido productos que extienden las funcionalidades de Cisco Nexus 1000V, como son:

• Cisco Virtual WAAS
  • Solución de aceleración WAN y balanceo.
• Cisco Virtual Security Gateway
  • Solución de firewall por zonas, de forma que tengamos varios servicios de clientes diferentes en el mismo segmento de red y poder definir que se puede ver y por quien…
• Cisco ASA 1000V (que describimos la semana pasada)
  • Firewall perimetral y de filtrado entre VMs dentro de una zona.

Estos elementos se complementan con funcionalidades y soluciones clave:

• Cisco Nexus vPath
• Cisco Virtual Network Management System

En los próximos post, hablaremos de las novedades que nos aporta cada producto, empezando por la base: Cisco Nexus 1000V y Cisco Nexus vPath. ¿Qué opináis de la estrategia de Cisco en el tema Virtual Networking?

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

Hola amigos, soy Florián Murillo. En el VMworld 2011 de agosto en Las Vegas, Cisco ha anunciado grandes novedades para la infraestructura virtual de VMware.

Me centraré en una de ellas, en el Cisco ASA 1000V cloud firewall,  es un virtual firewall en formato virtual appliance que se integra con Cisco Nexus 1000V, estará disponible en la primera mitad del 2012.

Como es habitual en Cisco (y otros fabricantes) primero llega el marketing y detrás el producto, las características principales del nuevo producto son:

Proporciona cortafuegos perimetral “multi-tenant”, o lo que es lo mismo, se puede utilizar para securizar varios clientes en entornos aislados.

Proporciona VPN site-to-site, las conexiones VPN de clientes remotos, como Cisco AnyConnect no están soportadas en esta primera versión.

Requiere para su funcionamiento, como pre-requisito, de Cisco Nexus 1000V, el switch distribuido de Cisco.

Se gestiona desde el Cisco Virtual Network Managemeng Center (VNMC) compartiendo consola con el Cisco Virtual Security Gateway (otro día hablamos de este producto).

La versión inicial no soportará vCloud Director, pero como Cisco Nexus 1000V está soportado por vCloud Director, no dudo que se soportará en siguientes versiones.

Está soportado desde vSphere 4.1 y se basa en la versión de software Cisco ASA v.8.4

El licenciamiento será por sockets, siguiendo la línea de Cisco Nexus 1000V y Cisco Virtual Security Gateway.

Resumiendo: Es una versión inicial que alegrará a muchos consumidores de tecnología Cisco, aunque con ausencias esperadas, las VPNs de usuarios remotos y la no integración de vCloud Director hacen que denominemos esta versión como “la primera”.

Seguimos esperando el precio final pero, me surge una duda: ¿Puede el mantenimiento y soporte de la versión virtual de un producto ser mas cara que su homónimo del mundo físico?

Lo sabremos en unas semanas

¿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.

Hola amigos, soy Florián Murillo. La semana pasada, mi colega de blog, Santi Fernández, expuso en su post “Aterriza la nueva versión de vSphere 5” de forma clara, las líneas generales de las novedades de vSphere 5, que se lanzó el martes 12-julio. En este post, detallaré brevemente las novedades específicas de networking que trae la nueva versión.

La nueva versión de switches distribuidos, la v.5.0.0 (ya van tres versiones) tiene soporte de LLDP, NetFlow, Port Mirroring y funciones avanzadas en Network I/O Control (NIOC).

Link Layer Discovery Protocol (LLDP): Es un protocolo de descubrimiento de “vecinos” estándar, alternativo a Cisco Discovery Protocol (CDP), LLDP me proporciona información acerca del switch al que estamos conectado.

NetFlow: Realmente no es una novedad, en VI3 teníamos NetFlow en calidad de experimental, y desapareció en vSphere 4, quizás por la llegada de Cisco Nexus 1000V, que si soporta NetFlow. En vSphere 5 se pueden capturar y enviar a un “Netflow collector” los flujos de red entre VMs e incluso entre una VM y un servidor físico. Para ello le hemos de poner una IP al switch distribuido, otra novedad que se ha de tener en cuenta en los diseños. En vSphere 5 se soporta NetFlow v.5.

Port Mirroring: Copia el tráfico de que entra y/o sale de un puerto, en un puerto de mirror para tareas de análisis de tráfico o resolución de problemas. Es una gran herramienta.

Las funciones avanzadas que tiene el Network I/O Control son:

User-Defined Network Resources Pools: Network I/O Control llegó en vSphere 4.1 con unos Network Resources Pools (nRP) ya definidos y sin poder añadir mas. Ahora podemos definir nRP a nuestra conveniencia, asociando port-groups a los nRP creados para definir las prioridades de tráfico.

Cada nRP, además de los shares y limits, es marcado con un tagging 802.1p para aplicar Calidad de Servicio.

En definitiva, grandes mejoras que tendremos que ir desglosando una a una para que veáis como aplicarlas.

¿Creéis que estas mejoras ayudarán a optimizar el rendimiento de red en nuestros CPDs?

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

Hola, soy Miguel Ángel Alonso, y aquí vuelvo a estar con nuestros queridos lectores del blog, un martes más.

Siguiendo con la estela de los últimos Post relacionados con el mundo de la virtualización de Microsoft en Hyper-V, hoy vamos a ver una interesantísima herramienta de visualización-diagnóstico del entorno de nuestros servidores a nivel de CPU, disco, memoria y red con más de 100 parámetros que nos ayudarán en el deber diario de cada día.

La herramienta en cuestión se llama Vital Signs y es de la empresa SAVISION, experta productos de visualización y diagnóstico para soluciones de hypervisor tipo 1 como Microsoft Hyper-V y otras soluciones, como por ejemplo, SQL y Windows Server.

Este nuevo software de monitorización para Microsoft HyperV dispone de una integración total con System Center Operation Manager (SCOM), con lo que la lectura de datos de nuestra estructura de Hyper-V esta mucho mas elaborada.

Lo que más me gusta de esta herramienta con gran diferencia, por supuesto a parte de la gran cantidad de datos a visualizar, es la claridad de los departamentos en la que está estructurada y la visualización de unos gráficos muy claros y concisos.

Se asegura de forma proactiva de darnos errores producidos en las cargas de trabajo, y de forma automática – sin necesidad de intervención del personal – ,corregirá todos aquellos problemas basándose en anteriores lecturas de trabajo (normal) para volver a conseguir que nuestra infraestructura goce de una más que formidable salud.

Bajo mi punto de vista, es una herramienta que considero imprescindible para los entornos donde reina Hyper-V como plataforma de virtualización.

Aquí os dejo un ScreenShot para que podáis familiarizaros un poco más con este maravilloso producto:

Puedes encontrar la herramienta para su descarga en el siguiente enlace: http://savision.com/privatecloud

Bueno, hasta aquí por hoy. Espero haberos contado algo interesante, y te emplazo hasta la semana que viene para hablar sobre un nuevo tema, relacionado con este maravilloso mundo de la virtualización de sistemas.

¿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.

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

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

En el episodio de esta semana, te mostrare como hacer un curso de VMware ESXi gratuitamente y valorado en 1.500 euros, responderé a la pregunta de un usuario en relación a la configuración del teaming de red en VMware ESX/ESXi y te mostrare otra utilizad impresionante relacionada con el mundo de la virtualización de servidores, Compliance Checker for VMware vSphere.

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

PD. No te pierdas al final del show, nuestra nueva sección de tomas falsas.

¿Y tú, qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Qué piensas de las diferentes soluciones de Virtualización que existen en la actualidad en el mercado? ¿Cuál es tu solución favorita y por qué? Deja tu comentario en virtualizacion.tv o charlemos sobre ello en twitter.

¿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.

¿Que tal? Soy Jose Maria Gris y como cada Miércoles comparto estas páginas virtuales con vosotros.

Hace tiempo publiqué un post (por favor, Jose María) donde teníamos problemas de rendimiento con alguna vmnic. Allí hablábamos como trabajar con herramientas como iperf para ver exactamente que caudal estaba gestionando.

Con la aparición de VMWare vSphere 4.0 y 4.1 han cambiado muchas cosas en este mundillo de las nics y aún me llegan preguntas sobre ellas o bien, cuando estoy en alguna instalación veo que no se han usado los tipos de nic mas adecuados.

Y hoy he creído que sería bueno ver los diferentes modelos de vmnic que hemos movido y para que “sirven” o están planteadas.

Dejo de lado versiones que son “mandatory” para según que clusters y según que combinaciones.

Cito cronológicamente:

Vlance: Vlance es una “Legacy” que tenía su truco. Vlance era una emulación de la AMD 79C970 que su peculiaridad era “to hit de ground running” como los comandos. Esta vmnic empieza a funcionar en cuanto arrancaras la vm tuviera o no las vmwaretools instaladas, eso sí, a 10 Mb, pero conectaba. Al instalar las tools subía a 100 y a 1000 (?).

VMXNET: Este adaptador ya nació virtualizado, pensado para entornos virtuales. Precisaba de las tools. Fue el “abuelo” de las VMXNET actuales.

Flexible: Pues sencillamente eso, Flexible. En cuanto lo arrancabas tenia un comportamiento como una Vlance, al ponerle las tools, se comportaba como una VMXNET

E1000: Emulación de la Intel 82545EM. Personalmente he tenido experiencias no muy satisfactorias con este driver. Mediciones realizadas por mi mismo han dejado la transferencia de este driver muy lejos del Giga.

VMXNET 2 / VMXNET 3: Con vSphere nos llegaron estas vmnics que a mi modo de ver son las que funcionan mejor, incluyendo las ultimas tecnologías de switching. Eso sí, estos tipos tan sólo están soportados por los modernos OS Guest (XP hacia arriba), por lo que no podrán instalarse en entornos Windows 2000. En VMware vSphere 4.1 han sido mejoradas.

Pues con esto me despido hasta la semana que viene.

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

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

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

Esta semana tenemos una gran lección de Catalana Occidente, hablaremos de OpSource Cloud – un servicio IaaS, contestare a una gran pregunta de un usuario relacionada con los beneficios al instalar las VMtools de VMware vSphere y compartiré contigo un enlace muy interesante relacionado con el mundo de la virtualización de sistemas.

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

¿Y tú, qué opinas con relación a la pregunta lanzada en el episodio de hoy? ¿Prefieres tener corriendo tus máquinas virtuales en un servidor de hosting y en la nube? O por el contrario, ¿Crees que es mejor tener tus máquinas virtuales virtuales en tu nube privada dentro de tu empresa? Deja tu comentario abajo en este video en virtualizacion.tv o charlemos sobre ello en twitter.

Queridos lectores,

En el post de hoy explicaré como desactivar Task Offload. En ocasiones desactivandolo notaremos un incremento de rendimiento en la red.

Lo haremos tanto en las interfaces virtuales (VIF) como en las físicas (PIF).

1º .- Desactivamos Task Offload en una VM Windows 2003 :

- Vamos al registro HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
– Creamos la siguiente Key DisableTaskOffload

2.- Desactivamos CheckSum Offload en XenServer

- Sobre la interfaz virtual:

xe vif-param-set uuid=”uuid” other-config:ethtool-tx=”off”
xe vif-param-set uuid=”uuid” other-config:ethtool-rx=”off”

-Sobre la interfaz física:

xe pif-param-set uuid=”uuid” other-config:ethtool-tx=”off”
xe pif-param-set uuid=”uuid” other-config:ethtool-rx=”off”

Y con estos sencillos pasos lo tendremos desactivado. Recomiendo encarecidamente hacer pruebas para ver si realmente se mejora el rendimiento.

Y como siempre espero que sea de utilidad.

¿Cómo estamos? Soy José María Gris y como cada miércoles vengo a comentaros un nuevo tema que creo puede ser de vuestro interés.

Hoy veremos “el caso de las tarjetas de red virtuales que desaparecen en escritorios de View”. Este es un caso donde en una instalación se detectó que en los escritorios virtuales “desaparecían” tarjetas virtuales de Lan.

El administrador estuvo buscando y buscando hasta que encontró el problema y su solución.

El tema es bastante sencillo al fin y al cabo. En el terminal el usuario a veces introduce un USB, un Pendrive y ahí se origina el problema.

Cuando se invoca el icono de “sacar hardware con seguridad”, el sistema enseña tanto el USB como la tarjeta de lan. Si el usuario se equivoca o bien no sabe exactamente lo que tiene que hacer, entonces “desaparece” la tarjeta de lan dejando el escritorio inhábil hasta que el administrador vuelve a conectar el device.

Con la máquina virtual apagada, “Edit settings”, seleccionar la pestaña “Options”, y allí, en la sección “Advanced”, seleccionar “General”. En la parte derecha aparecerá el botón “Configuration Parameters”.

Entrando en estos parámetros, botón “Add Row”. Aparece nueva fila e introducimos en la primera columna devices.hotplug y en la segunda false.

La posibilidad de deshabilitar la tarjeta de red desaparece. Gracias David, Gaspar…

Hasta la semana que viene. Take care.

Hola de nuevo!!, soy Miguel Angel Alonso y aquí estoy con vosotros en el Blog de la Virtualización en español como cada martes. El post de hoy es más coto de lo acostumbrado pero no menos interesante por ello.

En el tema de hoy vamos a hablar sobre los simuladores de carga, y que tan bien van para nuestros entornos VDI (virtualización del puesto de trabajo). Gracias a estos simuladores de carga podremos saber con bastante exactitud los IOPs de red y disco que demandan nuestros escritorios en nuestras plataformas VDI.

Empezaré hablando por cercanía de uso de un producto de VMware y que podéis descargar todos los Partners desde Partner Central llamado RAWC, el cual consta de 3 instaladores y una Appliance:

1. DesktopRawcControllerSetup. Es el software que instalaremos en un server 2003 y que es donde se gestiona y envía las cargas a los escritorios (targets) a petición del Launcher.

2. DesktopSessionLauncherSetup. Este se instala en un escritorio que debe ser un Windows XP obligatoriamente el cual actúa como detonador del envío de carga a nuestros targets a través del servidor anteriormente mencionado.

3. DesktopRawcWorkloadSetup. Se instala en el escritorio que utilizaremos como imagen maestra para generar escritorios a través de VMware View (obligatoriamente). En esta imagen maestra deberemos instalar Macafee como antivirus, office 2007, Adobe Reader, winzip, Java y unos videos en alta definición para colocarlos en una serie de carpetas particulares que se indican en la guía de administración.

4. RAW Email Server. Esta se suministra en formato Appliance y hay que configurar e instalar las Tools para empezar a manejarlo. Este servidor nos ayudará junto con el Outlook 2007 que instalamos en nuestros desktops a generar cargas de trabajo que simulan nuestro día a día de la mensajería de la empresa.

Mediante la consola de gestión de nuestro launcher, podremos hacer que se abran, cierren, borren, escriban datos, escaneen virus, manden emails, compriman y descompriman archivos y un largo etcétera.

Cabe reseñar que existe también para Citrix otra solución del mismo estilo llamada Citrix EdSight for Load Testing. Buscando en profundidad por Internet he dado con otra solución mixta, llamada VSI Login Consultant, que sirve tanto para VMware como para Citrix y que es un calco de RAWC, aunque un poquito menos compleja.

Bueno hasta aquí por hoy, y espero haberos contado algo interesante una semana más. Gracias y hasta la semana que viene.

Hola amigos, soy Florián Murillo, y voy a narrar lo que es un día normal en nuestras vidas, imagino que os veréis identificados con esta u otra alegría.

Que tendrá el primer cafe de la mañana que siempre tiene que ser interrumpido, esta vez es un ESX que ha dejado de “ver” una tarjeta de 4 puertos ethernet, con los problemas que ya nos podemos imaginar.

Gracias a que este equipo está en un cluster HA (y que es la hora del café) no afecta al negocio, así que procedemos a recuperar el ESX sin el pánico colectivo de épocas anteriores, cuando no existían infraestructuras virtuales.

Tras varias pruebas se decide volver a reinstalar el ESX, por tanto, así procedemos, y tras la reinstalación (manteniendo el datastore local) celebramos que la tarjeta de 4 puertos ethernet vuelve a ser reconocida.

Pero como este trabajo siempre tiene un “pero”, el “pero” de hoy es que los puertos vmnic han cambiado de nombre, no todo podía ser tan fácil.

[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic2 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic3 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic4 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic5 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic6 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic7 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500

Cuando antes de la instalación, según la documentación existente (aquí os he impresionado), la situación anterior era la siguiente:

[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500

Hemos de dejar los interfaces igual que antes, si queremos evitar problemas de diseño e implantación, por tanto pasamos a editar el archivo /etc/vmware/esx.conf

[root@host01 ~]# nano /etc/vmware/esx.conf

… nos encontramos las siguientes líneas:

/device/000:008:00.0/vmkname = “vmnic2″
/device/000:008:00.1/vmkname = “vmnic3″
/device/000:009:00.0/vmkname = “vmnic4″
/device/000:009:00.1/vmkname = “vmnic5″
/device/000:010:00.0/vmkname = “vmnic6″
/device/000:010:00.1/vmkname = “vmnic7″

Editamos con nano estas líneas y las dejamos de la siguiente manera:

/device/000:008:00.0/vmkname = “vmnic0″
/device/000:008:00.1/vmkname = “vmnic1″
/device/000:009:00.0/vmkname = “vmnic2″
/device/000:009:00.1/vmkname = “vmnic3″
/device/000:010:00.0/vmkname = “vmnic4″
/device/000:010:00.1/vmkname = “vmnic5″

Reiniciamos el host y tras el reboot nos encontramos lo siguiente:

[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500

… lo incluimos de nuevo en el cluster HA y nos tomamos otro café, a ver si este acaba bien …

Hasta la semana próxima, amigos.

Queridos lectores,

En el post de hoy explicaremos, a través de unos sencillos pasos, como modificar la velocidad de negociación de la tarjeta de red. Nos será de mucha utilidad cuando nos topemos con algún switch que no se entienda con nuestro XenServer.

Como sabéis mediante los comandos de linux (ethtool), también es posible hacerlo. El problema es que los cambios no se mantendrán después de un reinicio.

1.- Encontramos la interfaz física que queremos modificar:

xe pif-list host-uuid=”uuid del host”

2.- Desplegamos todas las propiedades de la interfaz física:

xe pif-list uuid=”uuid de la interfaz” params=all

3.- Modificamos. Podemos modificar la velocidad, negociación y duplex.

xe pif-param-set uuid=”uuid de la interfaz” other-config:ethtool- autoneg=”off”

xe pif-param-set uuid=”uuid de la interfaz” other-config:ethtool- speed=”1000″

xe pif-param-set uuid=”uuid de la interfaz” other-config:ethtool- duplex=”full”

Fijaros bien en los pasos que he seguido puesto que es necesario deshabilitar la negociación para establecer la velocidad manual. Para terminar reiniciaremos para que se apliquen los cambios.

Espero que os sea de utilidad.

Hola a todos, soy Florián Murillo y hoy toca describir una de las funcionalidades que creo que acabaremos utilizando todos (los que tengamos licenciamiento Enterprise Plus).

Network I/O Control, es el nombre que se le ha dado a las nuevas capacidades para repartir el ancho de banda de red entre los diferentes tipos de flujos de información, algo sumamente importante cuando tenemos interfaces de 10Gb.

Esta funcionalidad solo se puede utilizar con switches distribuidos, por tanto, como decíamos al inicio, requiere la licencia Enterprise Plus.

La forma de implementarlo es sencilla ya que utilizan dos viejos conocidos: shares y limits.

Para activar NetIOC (es el acrónimo que se está difundiendo) nos vamos a la vista de networking y al hacer click sobre el switch destribuido nos aparece en la ventana de laizquierda la pestaña “Resource Allocation”, si hacemos click en el hiperlink “Properties” nos aparece el checkbox de activación, como en la imagen de la cabecera.

En la imagen anterior podemos ver en la columna “Network resource pool” los tipos de tráfico definidos por defecto, con el ancho de banda asignado y la prioridad a la hora de obtener ancho de banda (share).

Con el botón de la derecha sobre un flujo de tráfico, nos aparece la opción “Edit Settings”, pudiendo cambiar el limit y el share.

¿Puedo combinar NetIOC que se aplica a nivel de switch con Traffic Shaping que se aplica a nivel de port-group?

Por supuesto, yo puedo dar un ancho de banda y prioridad concreta al tráfico de las VM con NetIOC y luego tener varios port-groups con VMs, cada uno de ellos con su configuración de Traffic Shaping para aplicar diferentes calidades de servicio entre los port-groups.

Creo que es una gran ayuda para repartir el tráfico en interfaces de red de 10Gb, aunque con interfaces de 1Gb también nos puede ayudar a garantizar anchos de banda por servicio.

Tener en cuenta que para que un switch distribuido tenga la funcionalidad NetIOC se ha de crear en host con vSphere 4.1.

Esto es todo amigos, la semana próxima hablaremos de otra interesante novedad de VMware vSphere ESX/ESXi 4.1.