No te acostarás sin saber una cosa más, si Señor.

Estaba yo tan contento, preparando mi post de este jueves (éste, si, éste) y pensaba que versaría sobre una herramienta que me ha dado muchos alegrías. Hablo de Mremote, una herramienta que hace de cónsola / Shell para RDP, VNC, SSH, HHTP y alguno más.

En un proyecto me han pedido especial hincapié en tener una herramienta de este tipo, y buscando por esas webs de Dios, me encuentro con esta maravilla, Remote Desktop Manager by Devolutions, que encima es Freeware.

Integra los siguientes clientes: RDP and TS, MS Remote Assistance, Real VNC, TightVNC, UltraVNC, Citrix,LogMeIn, Team Viewer, Dameware, VMware Player, Workstation, vSphere, Hyper-V, Virtual PC, Virtual Server…. Add-ons para HP graphics, y SQL studio …. me dejo alguno que te interese? pues seguro que me lo he olvidado y seguramente está disponible. Increíble

Se puede hacer download aquí , bajas el .msi y lo instalas como un “my wife”, Al arrancar no te asustes, no te pide licencia, tan sólo te pide si lo quieres arrancar en modo Standard (Freeware) o Enterprise (de pago, básicamente con gestion de usuarios y soporte para SQL Server, Amazon S3, Multiusuario, etc). Obtendréis una vista como ésta.

Pero no terminan aquí las sorpresas. “File, Import, Import from another application, mremote” . Pues sí, te vas a tu Mremote que tienes funcionando, exportas un XML de la configuración de las conexiones y te lo importas a tu nuevo entorno (algún cambio tendrás que hacer, no todo es tan “directo”.

Aquí podéis ver el impresionante “pop up” de configuración con las herramientas que podemos integrar

Pero fijaros la lista que tiene especificamente para virtualización

Recordad que hay que instalar los clientes en la máquina donde vais a ejecutar la cónsola, y si no sabéis donde encontrarlos, en la pagina de download de la aplicación están los links necesarios, mas fácil imposible.

Le ha llegado la hora a mi fiel Mremote veo. Hasta la semana que viene.

La web del Blog de Virtualización en Español ha superado los 2.000 fans via RSS (Really Simple Syndication).

A día de hoy son en concreto 2.008 usuarios los que siguen las actualizaciones que el equipo de expertos en virtualización en Español colaboran en el site y envían puntualmente cada día a la red.

La cifra de 2.000 usuarios se consiguió durante la segunda semana de este mes de Marzo y supone un récord absoluto de seguidores en webs de ámbito de virtualización de sistemas en nuestro país.

Asimismo he podido comprovar gratamente que la tendencia de crecimiento es clara ya que se están suscribiendo, de media, del orden de entre 10 y 15 usuarios al día.

La manera de hacerse fan de josemariagonzalez.es via RSS es a través de este enlace y seleccionado la opcion “Get El blog de Virtualizacion en Español dlivered by email“.

Además josemariagonzalez.es está presente también en Twitter, una de las redes sociales del momento, y cuenta con más de 1120 seguidores.

Desde el equipo del Blog de Virtualizacion en Español os decimos GRACIAS por vuestra confianza.

Hola amigos, como veis continuamos con la monitorización de sistemas. Al igual que lo hice con Hyperic esta vez voy a mostraros como instalar el agente de Zabbix en Xenserver 5.5. Otro día lo haremos con Nagios que es el que nos falta.

1.- Descargamos de la web de Citrix el “SDK Virtual Machine” y lo importamos en nuestro XenServer. Esto nos servirá para poder compilar el agente de Zabbix para nuestra versión de XenServer.

http://www.citrix.com/lang/English/lp/lp_1688621.asp

2.- Una vez tenemos la máquina virtual creada, nos traemos el paquete que contiene el agente zabbix y lo descomprimimos.

3.- Compilamos:

./configure –enable-agent –enable-static

make install

4.- Localizaremos los ficheros del agente de zabbix en la siguiente ruta:

/usr/local/sbin/zabbix_agent

/usr/local/sbin/zabbix_agentd

5.- Copiamos el directorio tal cual sobre nuestro XenServer 5.5. Yo suelo hacerlo con scp por medio de comandos pero hay clientes como WinSCP que también son muy cómodos.

6.- Creamos el usuario zabbix en XenServer

useradd zabbix

7.- Le damos permisos de este usuario sobre los directorios antes creados

chmod 755 zabbix_agent*

chown zabbix zabbix_agent*

8.- Creamos el directorio donde estarán los ficheros de configuración:

mkdir /etc/zabbix

9.- Le damos permisos al usuario zabbix sobre el directorio

chown zabbix /etc/zabbix

10.- LLevamos el fichero zabbix_agentd.conf al directorio anterior creado y le damos permisos para el mismo usuario

chown zabbix /etc/zabbix/zabbix_agentd.conf

11.- Creamos el directorio para logs

mkdir /var/log/zabbix

12.- Le damos permios para el usuario zabbix

chown zabbix /var/log/zabbix

13.- Copiamos el script de inicio en /etc/init.d y lo añadiremos a los niveles de ejecución

chkconfig –level 2345 zabbix-agend on

14.- Modificamos la linea donde aparece:

ZABBIX_AGENTD_BIN=/usr/sbin/zabbix-agentd

por

ZABBIX_AGENTD_BIN=/usr/local/sbin/zabbix-agentd

15.- Editamos la configuración del IPTables, añadiendo la siguiente linea

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 10050 -j ACCEPT

16.- Reiniciamos IPTables

service iptables restart

17.- Arrancamos el agente y comprobamos su funcionamiento

/etc/init.d/zabbix_agentd start

/tail -f /var/log/zabbix/zabbix_agentd.log

Con esto tendremos el agente funcionando en nuestro XenServer. Espero que os sea de utilidad.

Saludos y hasta la semana que viene.

Hola soy Miguel Angel Alonso y como cada Martes vuelvo al Blog de la Virtualización en español de José María Gonzalez para volver a contaros algo nuevo y siempre desde mi humilde opinión.

En este caso continuaremos con el capítulo 3 de VMware View que no es otro que el de Security Server; servidor que nos ayudará a encapsular nuestro tráfico mediante SSL por nuestro más que conocido puerto 443 y así de esta manera proteger todas nuestras sesiones de nuestros clientes con nuestro Broker de View a través de nuestras conexiones de INTERNET.

Además debemos saber que luego de nuestro Server security a nuestro Connection Server este se comunicará utilizando los puertos tcp : 8009 (AJAP139) y 4001 (JMS).

Todas estas comunicaciones mediante SSL servirán exclusivamente para nuestras conexiones mediante RDP ya que en caso de utilizar PCoIP deberíamos mapear el puerto tcp 50002 en nuestro querido Router para cada uno de nuestros Desktops Virtualizados .
Y por último pero no más importante deberíamos colocar nuestro Server Security en la DMZ de nuestra organización y no pertenecer o ser miembro del Dominio de nuestra organización.

Bueno explicado todo esto comenzaremos con la instalación de nuestro Servidor de Seguridad:

Habremos de empezar con el asistente de instalación de VMware View Connection Server, “Next” para comenzar…

Aceptamos el acuerdo de licencia y continuamos con el botón de NEXT

Indicaremos cual es la ruta de instalación por defecto que nos indica en este Snapshot y por supuesto; NEXT

Ahora elegimos el servidor que queremos instalar, que no es otro que nuestro Security Server

Ahora seleccionaremos la dirección en este caso FQDN de nuestro servidor Broker, aunque podríamos introducir perfectamente nuestra IP correspondiente; y NEXT

Comienza nuestra instalación …

Finalizaremos nuestra instalación y nos iremos a nuestro servidor Broker (Connection Server) para desde allí añadir y parametrizar nuestro nuevo Security Server

Seleccionamos la pestaña Configuration y en la sección Security Server en el enlace Add añadiremos nuestro Servidor de Seguridad

Introducimos el nombre de nuestro Servidor de Seguridad y le adjuntamos debajo la dirección HTTPS con su correspondiente puerto para nuestras conexiones externas. Después pulsamos OK.

Seguidamente seleccionaremos la opción Create Configuration File para generar un fichero de seguridad con el cual trabajará nuestro SS (Security Server)

Y seleccionamos guardar. Al fichero le llamamos config.propierties. Este fichero debe ser guardado en la carpeta “C:\Archivos de programa\VMware\VMware View\Server\sslgateway\conf\” del Security Server.

Lo siguiente que haremos será ir a nuestro Server Security de la DMZ y reiniciar el servicio VMware View Security Server y ya tendremos configurado nuestro Servidor de Seguridad.

Aquí os muestro un ejemplo de conexión mediante WEB por HTTPS a mi servidor Broker protegido por nuestro Security Server antes configurado

Bueno aquí me despido de vosotros por el momento hasta el próximo Martes en un nuevo capítulo que será el 4º y en el que veremos cómo instalar y configurar de Vmware View 4 Composer. Gracias como siempre a José María González y a todos nuestros lectores sin los cuales nada de esto sería posible.

El cliente vSphere es la principal interfaz para administrar todos los aspectos de tu entorno vSphere.

Es el interfaz para el servidor de vCenter Server y el servidor ESX/ESXi. También proporciona acceso a la consola de las máquinas virtuales.

Una vez que has instalado el servidor ESX o ESXi, una página de bienvenida es mostrada, a la cual es donde te debes conectar y desde donde te puedes descargar el cliente de vSphere

Para ver la lista de versiones de ESX y ESXi con el que el cliente de vSphere es compatible, consulte la guía de instalación en http://www.vmware.com/guides.html

En este episodio te mostrare como bajarte el cliente de vSphere para poder gestionar tu entorno una vez instalado el servidor ESX o ESXi:

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?

Os acordáis de Andrew Kutz y su plug-in SVMotion para VI 3.5?. Ese plug-in nos facilitó mucho el trabajo.

Os acordáis de Xtravirt? Muchos instalamos nuestros primeros ESX de prueba en entornos Workstation con su “How to”.

No es que esté sentimental ni añoro otros tiempos, si unimos los dos temas nos encontramos frente al nuevo plug-in que ha desarrollado Xtravirt para vCenter.

Cuantas veces nos hemos quejado de que la consola de la VM en el vCenter va lenta?

Os presento vSpher Client RDP Plug-in. A partir de ahora cuando queramos conectarnos a una VM desde vCenter lo podremos hacer directamente desde el vCenter, botón derecho, “Connect via RDP”.

Podéis obtener el plug-in aquí. Una vez efectuado el download, lo instalaremos con un sencillo setup “mi wife”… y podremos verlo mediante Plug-ins, Manage Plug-ins.

Cerramos vCenter y lo volvemos a arrancar (esa informática….) y a partir de ese momento, click sobre la VM, botón derecho, ahí tenemos al final la opción “Connect via RDP”

Más aún, queréis definir passwords y resolución?. Vamos a Home de nuestro vCenter. Bajo “Solutions and Applications” vemos un icono “Xtravirt RDP Plugin”

Ahí podremos configurar nuestros valores por defecto.

Espero que os ayude en vuestro trabajo diario.

Hasta la semana que viene.

Hola amigos,

En el post de hoy explicaré como poder convertir una máquina física en una máquina virtual. Para ello haremos uso de la utilidad XenConvert 2.1, recién salida del horno, que mediante el proceso P2V “Physical to Virtual Conversion” convertiremos nuestro servidor físico en una máquina virtual.

Sin duda alguna la mejor de las nuevas características de esta nueva versión es la posibilidad de convertir y redimensionar múltiples volúmenes. Podéis ver las características en esta url:

http://www.citrix.com/English/ss/downloads/details.asp?downloadId=1862307&productId=683148#top

Dependiendo del sistema operativo de nuestra máquina física habrán dos posibilidades:

1. Si nuestro servidor físico es Windows:
   • Descargamos XenConvert 2.1 de la web que os he puesto anteriormente.
   • Instalamos.
   • Una vez finalizada la instalación podremos ejecutarla.
   • El asistente muestra varias opciones de tipos de conversión. Por defecto crea un fichero VHD pero también podemos crear un fichero XVA, que después importaremos como template o appliance.
   • Una característica muy importante de todo esto es que si os dais cuenta no hemos reiniciado en ningún momento nuestro servidor físico.
2. Si nuestro servidor físico es Linux:
   • Reiniciaremos nuestro servidor físico y arrancaremos desde el CD de instalación de XenServer.
   • Cuando salga el menú de bienvenido a XenServer nos moveremos entre las opciones con el tabulador y seleccionaremos con la barra espaciadora.
   • Seleccionaremos la opción P2V y daremos a aceptar.
   • El proceso de conversión se hará a través de la red entre el equipo físico y XenServer. Es importante tener en cuenta que este proceso será bastante largo y que si tenemos VM en producción su rendimiento se verá afectado.
   • Cuando el proceso acabe habremos creado nuestra máquina virtual dentro de XenServer.

Esto es todo amigos, vuestro jefe ya no tendrá excusa alguna para que podáis pasar vuestro servidor físico a máquina virtual.

Saludos y hasta la semana que viene.

¡Hola a todos de nuevo! soy Miguel angel Alonso y como cada martes estoy aquí para contaros algo nuevo que en este caso seguiré con el orden de los dos POSTS anteriores.

Hoy veremos la instalación, que es muy sencilla de un servidor Réplica para nuestro Connection Server, ya que de esta manera nos aseguraremos el mantenimiento del servicio en caso de caída y el balanceo de carga de nuestro Connection Server en función de nuestro número de conexiones a nuestros escritorios virtualizados.

Se debe instalar por lo menos un segundo servidor VMware View Connection Server para disponer de alta disponibilidad o balanceo de carga, a esto se le llama disponer de un servidor de réplica.

Al instalar en modo réplica Connection Server, se crea una instancia ADAM (Active Directory Application Mode) y se inciará el View LDAP data que permitirá mantener todos los servidores Connection Server con la misma información, ya que usará la misma tecnología de replicación del Directorio Activo para replicar los datos entre los Connection Server.

Lógicamente antes de realizar esta instalación, tendremos que tener un servidor Connection Server instalado.

La instalación de este componente no tiene nada, basta con ejecutar el asistente de instalación de Connection Server de nuevo en otro servidor, “Next”

Aceptamos el acuerdo de licencia “I accept the terms in the license agreement” & “Next”,

Seleccionamos la ruta de instalación, por defecto “%ProgramFiles%\VMware\VMware View\Server”, “Next”,

Debemos seleccionar la opción “Replica” para unirnos a otro servidor de nuestra instalación, “Next”,

Aceptamos la licencia de ADAM (Microsoft Active Directory Application Mode), “I accept the terms in the license agreement” & “Next”,

Debemos introducir un servidor VMware View Connection Server cualquiera de nuestra organización para poder replicarnos con él la configuración y los datos de nuestra instancia, “Next”,

Pulsamos “Install” para comenzar inmediatamente con la instalación del servidor de réplica,

Una vez terminada la instalación, si abrimos un navegador, contra cualquiera de nuestros Connection Server (https://ConnectionServer/admin), y vamos a la parte de “Configuración”, a “Servers”, podremos observar cómo ya tenemos un segundo servidor VMware View!

Bueno aquí me despido de vosotros por el momento hasta el próximo martes en un nuevo capítulo que será el 3º y en el que veremos cómo instalar y configurar de VMWare View 4 VMware View 4 Security Server.

Gracias como siempre a Jose María Gonzalez, mis compañeros del BLOG, a Xavisan y Cristiansan de CTXDOM y a todos nuestros lectores sin los cuales nada de esto sería posible.

También querría hacer una mención especial a nuestro nuevo compañero del Blog y que cada Viernes estará con nosotros para enseñarnos cosas nuevas y al que yo al menos espero con los ojos bien abiertos. Un fuerte abrazo y cálida bienvenida para Florián Murillo especialista del mundo de la Virtualización de Servidores, seguridad y Cloud Computing.

Hasta el próximo martes.

El role “Administrator” es el role con mas privilegios en vCenter Server. Este role permiete al usuario ejecutar cualquier accion disponible en vCenter Server y por consiguiente deberías otorgar este role al menor número posible de usuarios.

Por defecto, el grupo local “Administrators” de Windows, es añadido al role “Administrator” del servidor de vCenter.

Para limitar el alcance de acceso, es una buena practica evitar el uso de la cuenta de usuario Administrator de Windows para ejecutar vCenter Server. En su lugar, asigna el role Administrator a una cuenta o grupo normal sin privilegios administrativos.

En este episodio te enseñare como crear en el servicor vCenter un usuario mas restringido – en cuanto a privilegios – para sustituir así el grupo “administrators” del role Administrator:

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?

Hola, que tal, como estáis?

Aquí estamos como cada semana hablando sobre temas del ecosistema de la virtualización, específicamente en entorno VMware.

Hoy vamos a ver una pequeña herramienta que nos puede facilitar mucho el trabajo. En un entorno donde hay proliferación de VMs y tenemos definidos “Resource Pools” si deseamos que éstos estén bien configurados y al día deberemos ir revisándolos de forma periódica calculando las reservas de los recursos.

Eric Sloof ha desarrollado un script llamado DRPC (Dynamic Resource Pool Calculator) que nos permite hacer esta tarea administrativa de forma fácil.

Podemos obtener el script aquí, deberemos instalar en la maquina que vamos a usar VMware vSphere PowerCLI y los que no nos gusta trabajar con powershell, nos instalamos PowerGUI y todos contentos, que con la que cae, no es poco.

Cargamos el script en el PowerGUI y tenemos una pantalla como esta

Ejecutamos con F5 o bien con el “Play”. La siguiente ventana nos preguntará por nombre o ip de nuestro vCenter o ESX

Browse, incluimos la ip y le decimos “OK”

Nos pedirá credenciales para acceder al vCenter o al ESX, logico…

Y aquí nos enseña los Resource Pool que tenemos establecidos en nuestro entorno….

Si efectuamos click sobre el Resource Pool que queremos revisar, tras funcionar la barra de trabajo nos indicará los valores que tenemos establecidos en estos momentos para reservas de memoria y cpu para este elemento (Old) y los valores que nos plantea que modifiquemos. En este caso, dado que he movido máquinas la diferencia es importante

No hay más secreto, si hacemos click, nos actualizará directamente el Resource Pool sin que tengamos que tocar para nada el vCenter. Si no deseamos actualizar, pues pulsamos Exit y listos.

Espero que os sea de provecho.

Hasta la semana que viene.

Es para mí un placer anunciar, que el Blog de Virtualización en Español, cuenta desde hoy con un nuevo colaborador y especialista del mundo de la Virtualización de Servidores, seguridad y Cloud Computing.

Florián Murillo es CTO y socio fundador de cloud-consulting.es, consultora especializada en cloud computing y DataCenter, con mas de 25 años asesorando empresas de todos los tamaños y con amplia experiencia en Seguridad, Virtualización VMware (VCP4 y VCI) y Networking de Cisco (CCNP, CCDP y CCSP). Actualmente Florián Murillo se dedica a ayudar a desarrollar negocios y proyectos en la nube a integradores, consultoras y proveedores de servicio.

Cada Viernes, Florián Murillo compartirá contigo, mi querido y apreciado lector, la noticia mas importante acaecida en el mundo de la virtualización, lo último en seguridad o las últimas novedades del Cloud Computing ,

Muchas gracias Florián por tu mas que desinteresada colaboración con el blog y espero y deseo que tengas mucha suerte con nuestros cientos de miles de queridos y apreciados lectores.

Queridos lectores del blog de virtualización en español. Para los que también quieran saber como configurar Jumbo frames en XenServer voy a explicar como hacerlo.

1.- Entramos por ssh a nuestro servidor XenServer.

2.- Buscamos la interfaz física a la que queremos aplicar el cambio:

xe pif-list

3.- Una vez encontrada, comprobamos su configuración:

xe pif-param-list uuid=”uuid de la interfaz de red física”

La informacion obtenida es mas o menos esta:

device ( RO): eth1
MAC ( RO): 00:23:7d:ee:f2:c0
physical ( RO): true
currently-attached ( RO): false
MTU ( RO): 1500
VLAN ( RO): -1
bond-master-of ( RO):
bond-slave-of ( RO): ba4a8cd5-3708-081b-c496-0967ab2bfce7
management ( RO): false
network-uuid ( RO): e4bbd54b-8236-fb25-98f5-60fd5c56b3f6
network-name-label ( RO): Pool-wide network associated with eth1
host-uuid ( RO): 9e7b7330-8776-4ec1-9f9e-0f1d55898e83
host-name-label ( RO):
IP-configuration-mode ( RO): None
IP ( RO):
netmask ( RO):
gateway ( RO):
DNS ( RO):
io_read_kbs ( RO): 0.000
io_write_kbs ( RO): 0.000
carrier ( RO): true
vendor-id ( RO): 14e4
vendor-name ( RO): Broadcom Corporation
device-id ( RO): 164c
device-name ( RO): NetXtreme II BCM5708 Gigabit Ethernet
speed ( RO): 1000 Mbit/s
duplex ( RO): full
disallow-unplug ( RW): false
pci-bus-path ( RO): 0000:05:00.0
other-config (MRW):

4.- Configuramos MTU 9000 sobre la interfaz física:

xe pif-para-set uuid=”uuid de la interfaz física” other-config:mtu=9000

5.- Volvemos a comprobar y vemos que se han aplicado los cambios:

xe pif-param-list uuid=”uuid de la interfaz de red física”

Y la información obtenida es más o menos esta:

device ( RO): eth1
MAC ( RO): 00:23:7d:ee:f2:c0
physical ( RO): true
currently-attached ( RO): false
MTU ( RO): 9000
VLAN ( RO): -1
bond-master-of ( RO):
bond-slave-of ( RO): ba4a8cd5-3708-081b-c496-0967ab2bfce7
management ( RO): false
network-uuid ( RO): e4bbd54b-8236-fb25-98f5-60fd5c56b3f6
network-name-label ( RO): Pool-wide network associated with eth1
host-uuid ( RO): 9e7b7330-8776-4ec1-9f9e-0f1d55898e83
host-name-label ( RO):
IP-configuration-mode ( RO): None
IP ( RO):
netmask ( RO):
gateway ( RO):
DNS ( RO):
io_read_kbs ( RO): 0.000
io_write_kbs ( RO): 0.000
carrier ( RO): true
vendor-id ( RO): 14e4
vendor-name ( RO): Broadcom Corporation
device-id ( RO): 164c
device-name ( RO): NetXtreme II BCM5708 Gigabit Ethernet
speed ( RO): 1000 Mbit/s
duplex ( RO): full
disallow-unplug ( RW): false
pci-bus-path ( RO): 0000:05:00.0
other-config (MRW): mtu: 9000;

Una vez configuradas Jumbo Frames sobre las interfaces físicas podremos hacerlo sobre las interfaces virtuales, la manera de hacerlo es muy parecida. Sería sustituir el comando pif por vif. Quedando de la siguiente manera:

1.- Buscamos la interfaz virtual:

xe vif-list

2.- Vemos sus características y parámetros:

xe vif-param-list uuid=”uuid de la interfaz de red virtual”

3.- Configuramos mtu 9000:

xe vif-para-set uuid=”uuid de la interfaz virtual” other-config:mtu=9000

4.- Comprobamos cambios:

xe vif-param-list uuid=”uuid de la interfaz de red virtual”

Esto es todo, a partir de ahora ya sabemos como poder hacerlo en VMWare y XenServer. Espero que os sea de utilidad.

Un saludo,

Adolfo.

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.