Hoy en el VMworld 2010 en San Francisco, tuvimos el Partner keynote, un aperitivo de los que nos espera mañana en el keynote del VMworld 2010 San Francisco con Paul Maritz, CEO en VMware.

Ciertamente fue una sesión muy productiva y llena de datos importantes. Sin ir mas lejos, Jeff Casual, Senior Vice President and General Manager Americas, nos dejo que un dato interesante: 3.000 partners son los que han asistido este año al VMworld, entre los que incluimos por supuesto a nuestra empresa, JmG Virtual Consulitng, S.L, expertos en virtualización.

Jeff también dio un dato que debería ser tomado muy en cuenta por todos los que nos dedicamos a los servicios de virtualización y es que mas del 85% del revenue de VMware proviene via Partners!!!.

Después, nuestro amigo Paul Maritz, CEO @ VMware tomo la palabra. Fue discreto pero contundente y conciso: agradeció a todos los partners su asistencia al VMworld, gracias Paull, y les advirtió estar en constaste alerta por las oportunidades que se presentaran en el futuro dentro del área de los servicios de virtualización.

Pero personalmente fue Rick Jackson, Chief Marteking Officer @ VMware, quien dio el dato más claro y rotundo:

We are past a virtual tipping point. For the first time more vms developed that physycal servers.

Rick no menciona la fuente del dato, pero sería estupendo si VMware nos pudiese decir la fuente del estudio pues ciertamente es un dato muy importante y a tener en cuenta, no crees?

Mañana, el keynote del VMworld 2010 de San Francisco. Sintoniza bien las ondas querido lector porque te adelanto en primicia – aun no puedo decir mucho por temas de NDA – que se van a anunciar 6 nuevos productos de VMware. No sé de dónde saca tiempo esta gente para innovar a este ritmo – a mi me tienen frito.

Podes ver un resumen en imágenes del VMworld 2010 San Francisco Partner Day Keynote en nuestra cuenta de twitter. Recuerda que puedes seguir online el evento VMworld 2010 en twitter.

… to be continued …

Una de las nuevas funcionalidades incluidas en VMware vSphere ESX/ESXi 4.1 es la posibilidad de poder hacer un re escaneado de todo nuestro datacenter con un solo clic de ratón.

Es importante mencionar que cada vez que se realizan cambios en la configuración SAN o en el servidor ESX/ESXi a nivel de almacenamiento, es necesario realizar un re escaneo de todos los adaptadores de almacenamiento y en todos nuestros servidores
VMware ESX/ESXi.

Asimismo es importante destacar la importancia de no hacer un rescan de tu fabric de SAN o iSCSI cuando uno de los caminos no está disponible. En VMware vSphere ESX/ESXi si uno de los caminos a una LUN falla, el protocolo de multipathing lo marca como “dead” y habilita el camino alternativo a esa LUN para poder restaurar el I/O a disco.

Sin embargo, si haces un rescan cuando uno de los caminos a tu LUN esta “muerto”, VMware vSphere ESX/ESXi eliminara este camino de la lista de rutas de acceso disponibles a dicha LUN. Esta ruta no estará disponible hasta que no se haga un nuevo rescan con la ruta activa.

En este episodio #38, te enseñare hacer un escaneado general desde el datacenter de toda tu fabric SAN para que los cambios en tu cabina sean actualizados en todos los servidores ESX/ESXi:

Vizioncore ha lanzado, en versión gratuita, un modulo de gestión para Microsoft System Center Operations Manager 2007 R2, el cual permite la monitorización de infraestructuras virtuales con VMware.

Antes de entrar en detalle con las características de lo que este Management Pack nos ofrece, cabe reseñar que Veeam ya ofrece este tipo de soluciones de monitorización del entorno virtual con VMware en System Center en modo trail – cuanta mayor competencia, mejor.

Pero, ¿cuáles son las características fundamentales del Management Pack gratuito de Vizioncore?

• Generación de alertas esenciales de la infraestructura virtual para reducir el tiempo medio de resolución ( de las siglas en ingles MTTR – mean time to resolution) de los problemas.
• La integración con System Center Operations Manager para centralizar y consolidar la monitorización del entorno virtual y físico.
• Arquitectura sin agentes ( agentless) para una implementación sencilla.
• Monitorización de eventos de disponibilidad y rendimiento del entorno virtual para una posible resolución rápida del problema

Puedes ver más información de VizionCore Management Pack para VMware en este enlace:

http://vizioncore.com/product/management-pack-for-vmware/features

Asimismo puedes descargar VizionCore Management Pack para VMware en este otro enlace:

http://vizioncore.com/product/Management-Pack-for-VMware

Lo bueno, y siempre desde mi perspectiva, es que cada vez más y más vemos un crecimiento paulatino del ecosistema de Microsoft, de esos mismos partners que en el pasado se centraron única y exclusivamente en las soluciones de virtualización de VMware.

Sin duda alguna la nueva versión de VMware vSphere ESXi 4.1 trae mejoras considerables.

En concreto, en esta versión se ha mejorado, y mucho, la forma y manera de activar el soporte SSH en VMware vSphere ESXi 4.1.

Esta nueva versión incluye una nueva opción en la configuración de VMware ESXi 4.1 para activar el soporte de SSH sin tener que editar, modificar, guardar y reinicializar ningún demonio de VMware ESXi, al menos, no lo tenemos que hacer nosotros manualmente.

Simplemente basta con activar la opción en el DCUI ( de las siglas en ingles Direct Console User Interface ).

En este episodio #37, te voy a mostrar como activar el soporte SSH para VMware vSphere ESXi 4.1, una mejora importante con respecto a las versiones anteriores de VMware ESXi 3.x y ESXi 4.0:

Con infinidad de compañías – pequeñas, grandes y medianas – adoptando cada vez más la tecnología de la virtualización de servidores, tiene aun mas sentido aprovechar los múltiples beneficios que aporta la utilización de la virtualización de sistemas.

Uno de estos beneficios es que las máquinas virtuales son independientes al hardware donde estas residen. Esto proporciona una portabilidad que va desde el site primario al site secundario donde el servidor físico y el hardware de almacenamiento pueden ser totalmente diferentes.

Cuando VMware lanzado al mercado en el año 2009 vSphere 4, lo hicieron con algunos cambios importantes en su vStorage APIs para Data Protection - API dicho de paso – que ya usan muchos productos de backup y replicación.

Uno de los cambios, a mi parecer, más notables fue el CBT (de las siglas en inglés Change Block Tracking). Con la funcionalidad de CBT, los servidores vSphere ESX/ESXi realizan un exhaustivo seguimiento de los bloques modificados en un disco virtual .vmdk

En este episodio #36, te voy a mostrar uno de los software de backup para entornos virtualizados que usan la funcionalidad de block change tracking, el archiconocido Veeam Backup:

VMware cambiara el modelo de licenciamiento de alguno de sus productos a partir del 1 de septiembre del 2010.

Ciertamente y, a medida que el tema del clould computing se convierte en un estándar mas en los entornos de TI, cada vez más es necesario la gestión global a nivel de máquina virtual (MV), en lugar de la gestión individual del hardware físico donde estas MVs residen.

Siendo ahora las máquinas virtuales, la nueva unidad de gestión – o al menos eso el lo que se pretende -, las empresas de TI necesitan un nuevo modelo – flexible, con opciones, que se ajuste a las exigencias del nuevo modelo – con el que puedan desplegar y configurar estas licencias.

Particularmente algunos productos de VMware vCenter pasaran de licenciarse por procesador o socket a licencias por máquina virtual. Asimismo, otros productos VMware vCenter continuarán siendo vendidos bajo el modelo de licenciamiento existente, es decir, por procesador o socket.

A continuación te muestro los productos que cambiaran el modelo de licenciamiento:

• vCenter AppSpeed
• vCenter CapacityIQ
• vCenter Chargeback
• vCenter Site Recovery Manager

Asimismo los productos siguientes no sufrirán ningún cambio en el modelo de licenciamiento:

• VMware vSphere
• vCenter Server
• vCenter Server Hearbeat – a quien le importa!?
• vCenter Lab Manager
• vCenter Lifecycle Manager

Ya hora aquí va la pregunta: Que pasa si previamente has adquirido licencias por procesador para AppSpeed vCenter, vCenter CapacityIQ, vCenter Chargeback o vCenter vCenter Site Recovery Manager?

Pues bien, VMware te ofrecerá un plan de transición que te permitirá cambiar tus licencias actuales – por procesador – al nuevo modelo de licencias basado en máquina virtual por licencia.

Por consiguiente, si poses licencias por procesador de los productos mencionados, a partir del 01 de septiembre del 2010 podrás hacer la conversión a licencias por máquina virtual.

Te conviene? Espero tu feedback.

Como te decía en mi post de la semana pasada, podemos usar Veeam Monitor como utilidad para medir y monitorizar el rendimiento de tu entorno VMware vSphere, pero también es posible utilizar Veeam Monitor para darnos una idea general de cómo están ejecutándose nuestras aplicaciones en nuestro entorno de VMware vSphere.

Ahora y gracias a la incorporación en el mismo producto de un plug-in gratuito llamado “Veeam Business View” , es posible monitorizar y gestionar la infraestructura virtual de tu entorno, no sólo desde un punto de vista técnico, sino también y mas importante, desde el punto de vista de servicios de la empresa.

En este episodio #35, te voy a guiar a través de la instalación del plug-in “Veeam Business View” para enseñarte el valor añadido que dicho plug-in puede tener en tu entorno:

Hola amigos, soy Florián Murillo y en el post prevacacional de hoy vamos a responder a pequeñas dudas que nos surgen en nuestro día a día con la vMA, en concreto:

¿Que versión de vMA tenemos instalada?

[vi-admin@vma01 ~]$ cat /etc/vima-release | head -1
vMA 4.0.0 BUILD-161992

donde head nos enseña las primeras líneas del archivo (el parámetro es el número de líneas)

¿Como aumento el espacio del disco de la vMA?

Primero verificamos el estado del disco antes de hacer los cambios

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Recordemos que /dev/sda es el disco duro y el número que le sigue es la partición.

Ahora paramos la vMA para hacer un grow del disco con:

[vi-admin@vma01 ~]$ sudo shutdown -h now

Ampliamos el disco de 5GB a 10GB desde vCenter (recuerda de borrar los snapshots para poder ampliar el disco) y levantamos la vMA

[vi-admin@vma01 ~]$ sudo fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Observa que el tamaño del disco /dev/sda ha cambiado a 10.7GB

Ahora cramos una partición con el nuevo espacio:

[vi-admin@vma01 ~]$ sudo fdisk /dev/sda

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n <--- Nueva partición
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3 <--- crearemos /dev/sda3
First cylinder (653-1305, default 653):
Using default value 653
Last cylinder or +size or +sizeM or +sizeK (653-1305, default 1305):
Using default value 1305

Command (m for help): t <--- Cambiamos el tipo de partición a 8e para Linux Volume Manager
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): w <--- Grabamos los cambios realizados (importante)
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
/dev/sda3 653 1305 5245222+ 8e Linux LVM
[vi-admin@vma01 ~]$

Ahora reiniciamos:

[vi-admin@vma01 ~]$ sudo reboot

Tras reiniciar, preparamos la nueva partición, para ampliar /var:

Como estamos en un entorno Linux Volume Manager, nos hemos de adaptar a sus reglas:

Primero creamos el Volumen Lógico

[vi-admin@vma01 ~]$ sudo pvcreate /dev/sda3
Physical volume “/dev/sda3″ successfully created

Ahora añadimos extendemos en Volume Group VolGroup00 (que vimos en el df -h) con el Volumen Físico creado

[vi-admin@vma01 ~]$ sudo vgextend VolGroup00 /dev/sda3
/dev/hda: open failed: No medium found
Volume group “VolGroup00″ successfully extended

Verificamos que tenemos espacio libre no asignado, y que coincide, como esperabamos con el Volumen Físico añadido:

[vi-admin@vma01 ~]$ sudo vgdisplay | grep -i free
Free PE / Size 160 / 5.00 GB

Ampliamos Volumen Lógico /var que hay dentro del Volume Group VolGroup00 con el espacio que nos aporta /dev/sda3

[vi-admin@vma01 ~]$ sudo lvextend -L+5G /dev/VolGroup00/var
Extending logical volume var to 5.50 GB
Logical volume var successfully resized

Verificamos que hemos ampliado /var

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

Está igual !!!! esto es debido a que hemos ampliado el Volumen Lógico /var pero no se ha formateado para el S.O., esto lo realizamos a continuación:

[vi-admin@vma01 ~]$ sudo resize2fs -p /dev/VolGroup00/var
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/var is mounted on /var/log; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/var to 5767168 (1k) blocks.
The filesystem on /dev/VolGroup00/var is now 5767168 blocks long.

Ahora si, ya podemos seguir recolectando logs sin llenar el disco.

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
5.4G 21M 5.1G 1% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm
[vi-admin@vma01 ~]$

¿Como cambiar la dirección IP de la vMA?

Es simple:

Paso 1: Modificamos el archivo /etc/sysconfig/network-scripts/ifcfg-eth0
Paso 2: sudo /etc/init.d/network restart

ya tenemos nueva IP, verifica que en /etc/hosts aparece la nueva IP.

Bueno amigos, con este repaso de Linux me despido temporalmente, deseando que paséis unos días tranquilos (o no) y nos volvemos a encontrar en septiembre con las novedades de la versión 4.1 que tenemos disponible desde el día 13 de julio. Ser felices.

A parte de usar Veeam Monitor 4.5 como utilidad para medir y monitorizar el rendimiento de tu entorno VMware vSphere, también es posible utilizar Veeam Monitor 4.5 para el seguimiento y resolución de problemas en tu solución de VMware vSphere.

Esta versión 4.5 incluye un notable número de características y mejoras, entre las que destaco:

• El soporte para VMware vSphere 4 y anteriores versiones de VMware ESX/ESXi
• Funciones de monitorización del almacenamiento y espacio en disco, problemas con los disco y datastores.
• Funciones de monitorización del hardware a través de CIM/SMASH
• La posibilidad de profundizar en cada sistema operativo Windows o Linux de las máquinas virtuales para controlar el rendimiento real de sus procesos desde el interior de una máquina virtual, sin tener que abrir la consola de la máquina virtual.

Pero en particular, Veeam Monitor 4.5, incluye ahora un plug-in que posibilita la integración con “Veeam Business View“, un complemento gratuito de la herramienta que permite la supervisión y la gestión de la infraestructura virtual, no sólo desde un punto de vista técnico, sino también y mas importante, desde el punto de vista de servicios de la empresa.

En este episodio #34, te voy a guiar a través del Veeam Monitor 4.5:

Hola amigos, soy Florián Murillo y en el post de hoy vamos a revisar la configuración de la vMA como recolector de logs de ESX y ESXi.

Para ello configuraremos un ESX y un ESXi para enviar logs a la vMA y después configuraremos el servicio vilogger para recolectar los logs.

Para configurar un ESX, nos conectamos por ssh y editamos el archivo /etc/syslog.cfg añadimos la línea:

*.* @10.1.1.1

Siendo 10.1.1.1 la IP de la vMA. A continuación hemos de permitir que el tráfico de syslog salga del ESX por lo que hemos de añadir la regla en el firewall del Service Console:

esxcfg-firewall -o 514, out, udp, trafico_syslog

y reiniciamos el servicio syslog:

service syslog restart

Para configurar un ESXi, utilizamos la propia vMA para lanzar una ejecución remota del comando vCLI que redirige el tráfico syslog hacia la vMA.

vicfg-syslog -s 10.1.1.1

Ahora solo nos falta configurar la vMA como syslog server con el servicio vilogger:

Lo primero que hacemos es cambiar la configuración del servicio syslog server en el servidor vMA para que acepte logs remotos:

sudo service syslog stop

cambiamos el archivo /etc/sysconfig/syslog, la línea SYSLOGD_OPTIONS ha de quedar como sigue:

SYSLOGD_OPTIONS=”-r -m 0”

y volvemos a levantar el servicio syslog con la nueva configuración:

sudo service syslog start

para permitir el tráfico de syslog, hemos de configurar el firewall de la vMA:

sudo iptables -I INPUT -i eth0 -p udp –dport 514 -j ACCEPT

y como queremos que este cambio sobreviva a los reinicios de vMA, también añadimos la regla de firewall (sin el comando sudo) al final del archivo /etc/rc.local

Ahora ya podemos empezar a utiliza vilogger, la utilidad que estructura los logs recogidos de los ESX/ESXi:

Primero iniciamos vi-fastpass ejecutando el comando vifpinit y a continuación facultamos a vilogger para recoger los logs de un host con:

vilogger –server esxi.dominio.local enable

No nos autenticamos en el host porque lo hace vi-fastpass por nosotros.

Cada host que activemos crea un directorio con el nombre del host en /var/log/vmware, en este directorio se almacenan los logs recogidos. SI quieres modificar el directorio por defecto de alojamiento de los logs, modifica el archivo /etc/vmware/viconfig/vilogdefault.xml

Verás algo parecido a la siguiente secuencia de comandos:

[vi-admin@localhost ~]$ vilogger list

Target Server: esxi.dominio.local
Log Status CollectionPeriod NumRotation MaxFileSize Location
(Seconds) (MegaBytes)
hostd Disabled – – – -
messages Disabled – – – -
vpxa Disabled – – – -

$ vilogger –server esxi.dominio.local enable

Target Server: esx1.dominio.local
hostd … Enabled
messages … Enabled
vpxa … Enabled

$ vilogger list

Target Server: esxi.dominio.local
Log Status Collec NumRot MaxFilSize Location
(Seconds) (MB)
hostd Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/hostd.log
messages Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/messages.log
vpxa Enabled 10 5 5 /var/log/vmware/esxi.dominio.local/vpxa.log

Con vilogger list verás el estado de todos los equipos registrados en vi-fastpass, es decir, vilogger utiliza vi-fastpass.

Con vilogger updatepolicy podemos modificar el intervalo entre recogidas de logs, el número de archivos a guardar o el tamaño de estos archivos, incluso podemos tener políticas diferentes por archivo de log.

Con vilogger –logname NOMBRE podemos desactivar la recolección de un log en concreto.

Como curiosidad, si entras en /var/log/vmware/esxi.dominio.local verás que los archivo de log anteriores al actual no los comprime como hace cuando se almacenan en el ESX/ESXi.

La semana próxima (la última antes de las vacaciones) seguiremos mejorando la configuración del vMA.

Ser felices.

Paul Martin, Director of Systems Engineering EMEA, y Larry Loucks, expertos y especialistas en soluciones de virtualización para VizionCore, me han pasado una presentación sobre los 10 errores de la virtualización según VizionCore.

Esta presentación es altamente recomendada para aquellos u aquellas que estas pensando en virtualizar vuestro centro de datos, o ya lo han hecho – por aquello que: “El hombre es el único animal del mundo que tropieza con la misma piedra mas de dos, tres, y hasta cuatro veces…

Muchas gracias a Paul Martin, Larry Loucks y VizionCore en general por pasarnos tan valiosa información.

No me cabe la menor duda que nuestros queridos y expertos lectores harán un buen uso, de tan importante información recogida aquí en esta presentación de powerpoint.

Muchas gracias de parte de todo el equipo del Blog de Virtualización en español.

Hola a todos,

Como sabéis durante el proceso de instalación de XenServer, este te dice si deseas instalar el cd adicional con los templates para linux.

En caso de no hacerlo, podremos instalar dicho cd posteriormente.

En el siguiente post os explicaré como hacerlo:

1.- Insertamos el cd en XenServer

2.- Accedemos a Xenserver desde CLI

3.- Montamos la unidad de cd

# mount /dev/hda /mnt

4.- Accedemos al directorio

# cd /mnt

5.- Instalamos

# ./install.sh

6.- Salimos del directorio y desmontamos

# cd ..

# umount /mnt

7.- Expulsamos el cd.

Y esto es todo, con ello tendremos instalado los templates de linux.

Espero que os sea de utilidad.

VMkernel System Information es un software propietario de VMware que almacéna información y configuración del service console y del vmkernel.

VSI ( VMkernel System Information) pueden ser consultado usando el shell interactivo vsish, una herramienta excelente la cual puede ser muy útil para la resolución de problemas en nuestro entorno VMware vSphere ESXi.

Este shell interectaivo es acesible solo y unicamente desde la consola directa del servidor ESXi y en modo soporte (support mode), o desde un cliente SSH siempre y cuando hayamos activado el servicio de SSH en VMware ESXi.

En este episodio #33, te voy a guiar a través del VMkernel System Information shell en VMware vSphere ESXi:

Hola amigos, soy Florián Murillo y continuamos hablando de vMA, la semana pasada hablamos de vi-fastpass, hoy hablaremos del fichero de sesión, un mecanismo de autenticación trasparente en un host ESX/ESXi:

Primero nos autenticamos en la vMA con ssh:

login as: vi-admin
vi-admin@myhost’s password: PWD
Welcome to vMA

A continuación nos cambiamos al directorio donde está el script save_session.pl, es un script en perl que creará un archivo, que vamos a llamar /tmp/file.txt y que albergará las credenciales de root para autenticarnos transparentemente en el host HOST2

$ cd /usr/share/doc/vmware-vcli/samples/session
$ ./save_session.pl –savesessionfile /tmp/file.txt –server HOST2 –username root -password PWD
Session information saved.

Ahora vamos a utilizar este archivo para ejecutar el comando de vCLI “vicfg-nics -l” que nos proporciona información de las vmnics del host, para ello acompañaremos el comando con el parámetro –sessionfile seguido del nombre del archivo de credenciales que acabamos de crear:

$ vicfg-nics -l –sessionfile /tmp/file.txt
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 01:00.0 bnx2 Up 1000Mbps Full 00:22:19:65:e9:dc 1500 Broadcom
vmnic1 01:00.1 bnx2 Up 1000Mbps Full 00:22:19:65:e9:de Broadcom
vmnic2 02:00.0 bnx2 Up 1000Mbps Full 00:22:19:65:e9:e0 Broadcom
vmnic3 02:00.1 bnx2 Up 1000Mbps Full 00:22:19:65:e9:e2 Broadcom
$

Estas credenciales son temporales, pasados 30 minutos, dejarán de funcionar, por lo que no suponen un riesgo de seguridad a largo plazo.

Además esta funcionalidad es de vCLI no de vMA, por tanto si tenemos vCLI en un linux o windows podemos utilizarla también, no ocurre lo mismo con vi-fastpass.

Hasta la semana próxima.

Hola que tal? Como estáis?

Habéis experimentado problemas cuando un servidor 2003 SP2 intenta unirse a un dominio y da timeout? O bien con algún software que hace copias masivas “corta” el enlace con la red en un 2003 SP2.

Bienvenido al club. Os presento a Tcp/Ip Offload Engine o para los amigos, “TOE”.

El protocolo SCSI tiene ya unos cuantos años, y cuando empezó a aparecer iSCSI los procesadores tenían que procesar más información. Para descargar el procesador, se sacó un chipset (TOE) que cuando tienes un 2003 SP2 puede dar errores de comunicación con la red.

Tal como indica la KB de VMware 1004337, cuando experimentas estos síntomas (y yo desde ahora lo haré por defecto) hay que tocar el registro y desactivar el TOE en la VM en el 2003.

“By default, Windows 2003 Server Service Pack 2 has the TCP/IP Offload Engine (TOE) enabled. TOE may prevent the virtual machine from talking to the domain controller.

You must modify the registry on the host operating system.

To modify the registry:
1. On the host operating system registry, s et EnableTCPChimney, EnableRSS, and EnableTCPA to 0.
2. Run the following command to disable TCP chimney offload:

Netsh int ip set chimney DISABLED “

Bueno, hasta la semana que viene

Take care…