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 Florián Murillo y aquí estoy, como cada viernes.

Hace mas de dos años que me compré un MacBook, volví a mis orígenes ¿fruto de la edad? ¿fruto de una pasión oculta? ¿por qué es bonito? ¿fruto de la lógica? no lo se, me lo pedía el cuerpo, mi primer computador personal fue un Apple IIe, hace muuuuchos años.

El caso es que dos años después,  lo sigo utilizando felizmente. Me acompaña en mis cursos como Instructor Oficial de VMware (VCI) y en las consultorías y proyectos en los que participo. Aquí acaba mi pequeño tributo a Steve Jobs, he compartido en la distancia sus triunfos y sus fracasos, pero sobretodo compartimos la idea de que “la velocidad de rotación del mundo la decidimos nosotros con nuestros actos”.

Apple no ha aportado mucho al mundo de la virtualización, pero gracias a VMware dispongo de VMware Fusion, el equivalente a VMware Workstation para la plataforma Mac, me permite disfrutar de virtualización con mi ordenador favorito.

Llegó el día que necesité hacer unos scripts en Perl utilizando el vSphere SDK for Perl, rápidamente decidí que el camino era la vMA, una auténtica joya de VMware que debería ser mas utilizada.

La vMA es una virtual appliance que debemos descargar de la zona de descargas de VMware. Para transformar la virtual appliance en una VM para VMware Fusion utilicé ovftool, una utilidad en modo comando que convierte la virtual appliance en una VM ejecutable.

La utilidad ovftool también se descarga del download de VMware, está disponible para Windows, Linux y Mac.

Tras descompactar el archivo descargado, nos aparece un paquete instalable en Mac. Una vez instalada, desde una sesión de terminal, ejecutamos:

# ovftool /path/vMA-5.0.0.0-472630_OVF10.ovf /path/vma5.vmx

Como vemos ovftool tiene dos parámetros, el primero es la virtual appliance a convertir (formato .ovf) y el segundo es el destino y nombre de la VM (acompañado de .vmx).

A partir de este momento tenemos una VM ejecutable en VMware Fusion. ¿Qué os parece ovftool?

¿Crees que este videopost 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 Florián Murillo y voy a repasar los distintos mecanismos de conexión a ESXi 5.

Respecto al ESXi 4, hay cambios de nomenclatura en los servicios Tech Support Mode, el Remote Tech Support Mode pasa a denominarse simplemente SSH, y el Local Tech Support Mode paa a ser llamado a partir de esta versión ESXi Shell.

La imagen adjunta, resume las diferentes alternativas de conexión con un ESXI 5:

¿Qué misión tiene el Lockdown Mode?

Es un modo seguro de conexión al ESXi, al activar Lockdown Mode el ESXi se producen los siguientes cambios:

1. No acepta sesiones root desde vCenter Server, como por ejemplo para hacer un “Add host” al vCenter Server. vCenter Server se puede seguir conectando como vpxuser.

2. No acepta conexiones ssh como root.

3. No se pueden ejecutar scripts vCLI, vMA o PowerCLI que se ejecuten como root directamente contra un host, las hemos de pasar por vCenter Server.

4. No acepta comunicaciones CIM excepto desde el vCenter Server.

¿Desde donde podemos activar Lockdown Mode?

1. Desde la DCUI

2. Al añadir el host para ser gestionado por vCenter Server

3. Desde vCenter Server, Host (haciendo click sobre un host) > Configuration > Security Profile

Con todo lo dicho, la imagen inicial, tras activar Lockdown Mode quedaría de la siguiente forma:

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

¿Alguna vez has tenido que modificar los syslog de tu servidor ESX/ESXi?

¿Alguna vez no has tenido suficiente con el tamaño de los logs de los servidores ESX/ESXi que vienen por defecto?

Si tu respuesta es si para alguna de estas preguntas, te recomiendo que sigas leyendo. Si tu respuesta es no para alguna de estas preguntas, te recomiendo también que sigas leyendo, nunca se sabe cuando lo vas a necesitar cambiar

Tiempo atrás, nuestro colaborador y experto en seguridad y redes – entre otras cosas – escribió un magnifico articulo sobre como configurar el modulo de vilogger con vMA, el appliance de gestión de VMware vSphere. También hizo mención a la opción que tiene vilogger para cambiar el tamaño de los logs por defecto (5MB).

Te cuento esto porque esta semana durante la implementación de VMware vSphere ESXi 4.1 en las instalaciones de un cliente, hemos tenido que cambiar la configuración del tamaño de los logs del ESXi, que como he mencionado anteriormente es de 5MB.

Y estoy seguro que te preguntaras, ¿Por qué demonios tengo que hacer este cambio? Esa es la misma que le hice a mi cliente.

La razón fundamental es por temas y policías corporativas, esa fue su respuesta. Al parecer, este cliente tiene una política corporativa que estipula que los log de los servidores – en este caso los servidores ESX/ESXi – tienen que tener un tamaño máximo de 10MB.

Con lo que, aquí te dejo con el comando que cambia el tamaño del log llamado hostd de un servidor ESXi, de 5MB a 10.

vilogger updatepolicy –server esx1.demos.local –logname hostd –maxfilesize 10

Por supuesto, para que el comando anterior te funcione necesitas tener instalado el vMA y el modulo del vilogger. Puedes ver mas información sobre como configurar vMA, vilogger y syslog en el post de Florían.

¿Y tú qué opinas? ¿Conoces alguna mejor manera de personalizar los logs de tu servidor ESX/ESXi? ¿Cuáles son tus experiencias personales con vilogger? Deja tu comentario abajo o charlemos sobre ello en twitter

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.

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.

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 amigos, soy Florián Murillo y vamos a profundizar en el funcionamiento de vi-fastpass, una funcionalidad que proporciona vMA para facilitar la explotación de los host ESX.

Los administradores de ESX, cuando empiezan con ESXi, tienen que adaptar sus hábitos de determinación y resolución de problemas.

Uno de estos hábitos es que la ejecución remota de comandos requiere, lógicamente por ser remota, autenticación, es decir, que cuando en un ESX teclean:

$ esxcfg-nics -l

en ESXi han de teclear:

$ vicfg-nics -l –username root –password PWD –server esx1.domain.local

Observar el cambio de prefijo “esxcfg” por “vicfg”. Es una tónica habitual de vCLI.

Existen dos mecanismos para facilitarnos el trabajo: vi-fastpass y el parámetro sessionfile, hoy vamos a explicar cómo funciona vi-fastpass.

Consiste en guardar en un almacén de credenciales local de vMA los nombres, tipo de equipo y credenciales de autenticación del vCenter y los host ESX y ESXi. Cuando entramos en vMA consultamos el contenido actual del almacén de credenciales:

[vi-admin@vma ~]$ vifp listservers
Error: No targets have been defined for this vMA.

Como vemos, está vacío, vamos a añadir nuestro vCenter:

[vi-admin@vma ~]$ sudo vifp addserver vc.domain.local
Enter username for vc.domain.local: USER
USER@vc.domain.local’s password: PWD

Ahora entramos un par de hosts:

[vi-admin@vma ~]$ sudo vifp addserver host1.domain.local
root@host1.domain.local’s password: PWD
[vi-admin@vma ~]$ sudo vifp addserver host2.domain.local
root@host2.domain.local’s password: PWD

Vamos a verificar el contenido del almacén:

[vi-admin@vma ~]$ vifp listservers
vc.domain.local vCenter
host1.domain.local ESX
host2.domain.local ESXi

Observar que nos ha detectado que tipo de sistema es, si es un vCenter Server, un host ESX o un host ESXi. Esto es debido a que, para añadir el equipo al almacén de credenciales se conecta al sistema para verificar las credenciales que hemos entrado y, solo si la autenticación es correcta, los añade al almacén.

NOTA: Eso quiere decir que no podemos añadir equipos apagados al almacén de credenciales.

Ahora vamos a utilizar vi-fastpass. Utilizamos el comando vifpinit para autenticarnos de forma trasparente en un host:

[vi-admin@vma ~]$ vifpinit host1.domain.local
[vi-admin@vma ~][host1.domain.local]$ vicfg-nics -l

[vi-admin@vma ~]$ vifpinit host2.domain.local
[vi-admin@vma ~][host2.domain.local]$ vicfg-nics -l

Para eliminar un host del almacén de credenciales:

[vi-admin@vma ~]$ sudo vifp removeserver host2.domain.local
root@host2.domain.local’s password: PWD

Vamos a comprobar si lo ha eliminado del almacén:

[vi-admin@vma ~][host2.domain.local]$ vifp listservers
vc.domain.local vCenter
host1.domain.local ESX

vi-fastpass es una gran ayuda para simplificar los mecanismos de autenticación en comandos remotos. Pero, no podemos olvidar robustecer la seguridad de la vMA, para evitar que se transforme en un riesgo para la seguridad.

Hola amigos, soy Florián Murillo y empiezo con este POST una serie sobre la instalación, configuración y utilización de la vMA.

Como decía en un POST del mes de abril llamado “Adiós mi querido Sevice Console” el vMA es un virtual appliances con CentOS 5.2, vCLI, vSphere SDK for Perl, Java JRE, agente SNMP y vSphere SDK for Java.

VMware nos plantea vMA como una herramienta ayuda al análisis del rendimiento, a la explotación de nuestro DC y la resolución de problemas, sustituyendo las tareas que realizamos directamente en el Service Console y unificando los procedimientos de actuación de los ESX y los ESXi, lo cual me parece acertado.

La vMA la descargamos desde el download de VMware, la versión actual es la v.4.0.0 build 161993 que tras descomprimir el .zip nos queda un archivo .ovf y un archivo .vmdk, este formato es un standard desarrollado por un grupo de trabajo de la DMTF para proporcionar un formato común de template para desplegar sobre diversos hipervisores, está soportado por ESX, Hyper-V, XenServer, KVM y VirtualBox, de hecho todos estos fabricantes y otros mas forman parte del grupo de trabajo que ha estandarizado OVF.

El proceso de instalación y configuración es el siguiente:

Tras una ventana informativa, aceptar el EULA, elegir un nombre para la VM, escoger su ubicación en el inventario, seleccionar el datastore donde se guardará la VM en sucesivas ventanas, nos pregunta en que port group conectaremos el interfaz de red de la vMA (Management Network), en nuestro caso seleccionaremos “Virtual Machine Network” y empezará la instalación de la VM.

Este proceso no difiere de la instalación de cualquier otro archivo ovf.

Tras finalizar la instalación, tenemos la VM (que hemos llamado vMA-2) parada y preparada para ser arrancada y configurada.

Arrancamos la vMA y vemos desde la consola que arranca un Linux y nos pide los datos IP del interfaz de red:

Tras aceptar los datos IP, nos pide la contraseña del usuario vi-admin, que es el usuario predefinido por la vMA para administrar el sistema y finaliza el proceso de instalación creando los certificados RSA para ssh y levantando el servicio ssh.

Tras esto, el equipo está arrancado y funcionando, vamos a comprobarlo:

iMac:~ florian$ ssh vi-admin@10.1.0.202
vi-admin@10.1.0.202′s password:

[vi-admin@vma-2 ~]$

Vamos a verificar que funciona …

[vi-admin@vma-2 ~]$ vicfg-nics -l –vihost esx1.dominio.local –username USER –password PWD –server vCenter.dominio.local
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 04:04.0 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:df 1500 Broadcom BCM5715S
vmnic1 04:04.1 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:e0 1500 Broadcom BCM5715S
vmnic2 06:04.0 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:e1 1500 Broadcom BCM5715S
vmnic3 06:04.1 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:e2 1500 Broadcom BCM5715S
vmnic4 10:04.0 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:dd 1500 Broadcom BCM5715S
vmnic5 10:04.1 tg3 Up 1000Mbps Full 00:1b:24:3d:a3:de 1500 Broadcom BCM5715S
[vi-admin@vma-2 ~]$

Confirmado, hemos interrogado a vCenter para que nos informe de los interfaces de red que tiene el host esx1.

Espero que os parezca interesante, la próxima semana empezaremos a explorar las posibilidades de vMA, que no son pocas.