Despiste 10: Cambiar la IP de la Service Console

Hace poco me han pedido cambiar un host ESX 3.5 de nuestra VLAN de producción a otra VLAN. Este cambio implica un cambio de la direcciones IP de los portgroups de la Service Console y vmKernel. Inicialmente, esta taréa podría ser vista como una tarea simple, hacer login en el host ESX físicamente y cambiar la IP, pero este cambio tiene más implicaciones ocultas que podrían llevarnos a problemas serios como perder las capacidades de HA o vMotion en el host afectado.

Cambiar la IP de la Service Console es bastante simple y el procedimiento se parece a (basado en la información basada en este gran post):

1. Listar los port groups de Service Console actuales:
esxcfg-vswitch -l este comando devolverá la configuración actual de vSwitches, algo como:

Switch Name	Num Ports	Used Ports	Configured Ports	MTU	Uplinks
vSwitch0	64	13	64	1500	vmnic0,vmnic2
	PortGroup Name VLAN ID Used Ports Uplinks VM Network 0 8 vmnic0,vmnic2 Service Console 0 1 vmnic0,vmnic2

Switch Name	Num Ports	Used Ports	Configured Ports	MTU	Uplinks
vSwitch0	64	13	64	1500	vmnic1,vmnic3
	PortGroup Name VLAN ID Used Ports Uplinks VMkernel 0 1 vmnic1,vmnic3

de forma que puedas buscar el nombre del port group de tu Service Console, en nuestro ejemplo el que está en negrilla.
2. Buscamos la interfazvirtual asociada con ese port group, que tiene que tener un nombre parecido a vswif, donde n es el número de la interfaz virtual, y será devuelto por el comando esxcfg-vswif -l, además de toda la configuración IP asociada con cada interfaz virtual:

Name	Port Group	IP Address	Netmask	Broadcast	Enabled	DHCP
vswif0	Service Console	xxx.xxx.xxx.xxx	nnn.nnn.nnn.nnn	bbb.bbb.bbb.bbb	true	false

3. Una vez que hemos localizado la interfaz virtual asociada a nuestra Service Console, la única forma de cambiar la configuración IP es borrar esa interfaz virtual y crear una nueva interfaz virtual con los parámetros deseados. Los pasos para realizar ese procedimiento son:
   
   
   
   1. Borra la interfaz virtual con: esxcfg-vswif -d vswif0
   2. Crea una nueva interfaz virtual y asociala con nuestro port group de la service console llamado Service Console:
      esxcfg-vswif -a -p "Service Console" -i <new IP Address> -n <netmask> vswif0
4. También deberíamos modificar la puerta de enlace por defecto asociada con la interfaz virtual modificando /etc/sysconfig/network-scripts/ifcfg-vswif0 y añadiendo GATEWAY=ggg.ggg.ggg.ggg en el fichero.
5. Este paso es bastante importante si quieres ahorrarte un montón de dolores de cabeza. Modifica la entrada correspondiente en el fichero /etc/hosts
6. En este punto tienes dos opciones, reiniciar el host ESX o deshabilitar y habilitar l interfaz vswif. Si eliges deshabilitar y habilitar la interfaz vswif deberías realizar el siguiente procedimiento:
   
   
   
   • Para deshabilitar la interfaz vswif: esxcfg-vswif -s vswif0
   • Para habilitar la interfaz vswif: esxcfg-vswif -e vswif0
   
   
   Una vez que has realizado todos estos pasos, simplemente busca el ESX afectado en el VirtualCenter, Desconéctalo y vuelve a conectarlo. Este proceso desinstalará el agente vpxa isntalado en el host ESX y lo volverá a instalar durante el proceso de reconexión.
   
   
   Si después de todo esto aún sigues tienendo problemas de conexión/vMotion/HA comprueba la entrada del host ESX en la base de datos de VirtualCenter. Duncan Epping tiene un post genial en Yellow-Bricks que registro debe ser comprobado y modificado: http://www.yellow-bricks.com/2008/09/29/storage-vmotion-fails-after-service-console-ip-change/
   
   
   Es el momento de cambiar la dirección IP del VMkernel. Este cambio puede ser realizado via vClient, o puede ser hecho directamente desde la Service Console. Cambiar la dirección IP del VMkernel por medio del vClient es bastante fácil, así que me centraré en como hacer este cambio manualmente.
   
   
   Como vimos con el método para cambiar la IP de la Service Console, este procedimiento depende de borrar la vmknic afectada y crear una nueva.
   
   

1. De nuevo, el primer paso recomendado es listar todas las vmknics disponibles en tu host ESX. Esto se puede hacer utilizando el comando esxcfg-vmknic -l que producirá una salida parecida a esta:

Interface	Port Group	IP Address	Netmask	Broadcast	MAC Address	MTU	TSO MSS	Enabled
vmk0	VMkernel	xxx.xxx.xxx.xxx	nnn.nnn.nnn.nnn	bbb.bbb.bbb.bbb	00:50:56:aa:bb:cc	1500	40960	true

2. A continuación , vamos a borrar la vmknic afectada (la que está en negrilla en nuestro ejemplo). También necesitaremos el port group asociado:
esxcfg-vmknic -d -p VMkernel vmk0
3. Finalmente, creamos una nueva vmknic con la configuración deseada y la asociamos con el port group correcto. Recuerda que este procedimiento generará una nueva dirección MAC:
esxcfg-vmknic -a -p VMkernel -i yyy.yyy.yyy.yyy -n mmm.mmm.mmm.mmm vmk0

Ten en cuenta que estos procedimiento son válidos solo para Standard vSwitches, y que es necesaria una ligera modificación para adaptarlo a los Distributed vSwitches disponibles en ESX 4. Pero esa es otra historia.

He basado este post en mi experiencia personal y en la información recogida de:

• http://vmwaretips.com/wp/2008/09/12/changing-service-console-ip-address-in-esx-35/
• http://www.yellow-bricks.com/2008/09/29/storage-vmotion-fails-after-service-console-ip-change/
• http://www.yellow-bricks.com/2008/06/04/changing-the-ip-address-of-an-esx-host-and-ha/

Espero que este post pueda ayudar a alguien.

Misleading 10: Changing Service Console IP address

Recently I've been asked for changing an ESX 3.5 host from one of our production VLAN to another VLAN. This change involve a change of IP addresses for Service Console and vmKernel portgroup. Initially, this task could be viewed as a simple task, just login in ESX host physically and change the IP, but this change has more hidden implications that could move on serious problems like losing HA o vMotion capabilities for the affected host.

Changing Service Console IP is quite simple and the procedure looks something like (based on information found in this great post):

1. List current Service Console port groups:
esxcfg-vswitch -l this command will retrieve current vSwitches configuration, something like:

Switch Name	Num Ports	Used Ports	Configured Ports	MTU	Uplinks
vSwitch0	64	13	64	1500	vmnic0,vmnic2
	PortGroup Name VLAN ID Used Ports Uplinks VM Network 0 8 vmnic0,vmnic2 Service Console 0 1 vmnic0,vmnic2

Switch Name	Num Ports	Used Ports	Configured Ports	MTU	Uplinks
vSwitch0	64	13	64	1500	vmnic1,vmnic3
	PortGroup Name VLAN ID Used Ports Uplinks VMkernel 0 1 vmnic1,vmnic3

so you can look for your Service Console port group's name, in our example the bold one.
2. We are looking for the virtual interface associated with that PortGroup, witch will be named something like vswif<n>, where n is the instance number of virtual interface, and will be retrieved by the esxcfg-vswif -l, aside all IP configuration associated with each virtual interface:
   

Name	Port Group	IP Address	Netmask	Broadcast	Enabled	DHCP
vswif0	Service Console	xxx.xxx.xxx.xxx	nnn.nnn.nnn.nnn	bbb.bbb.bbb.bbb	true	false

3. Once we've located our Service Console's associated virtual interface the only way for changing IP configuration is delete that virtual interface and create a new virtual interface with the new desired parameters. Steps to perform that procedure are:
   
   
   
   1. Delete virtual interface with esxcfg-vswif -d vswif0
      
   2. Create new virtual interface and associate it with our service console port group called Service Console:
      esxcfg-vswif -a -p "Service Console" -i <new IP Address> -n <netmask> vswif0
      
4. We also should modify the default gateway associated with the virtual interface modifying /etc/sysconfig/network-scripts/ifcfg-vswif0 and adding GATEWAY=ggg.ggg.ggg.ggg in the file.
   
5. This step it's quite important if you want to save a lot of headaches. Modify the corresponding in the /etc/hosts file
   
6. At this point you have two options, reboot the ESX host or disable and enable the vswif interface. If your choice was disabling and enabling the vswif interface you should perform the following procedure:
   
   
   
   • To disable a vswif interface: esxcfg-vswif -s vswif0
     
   • To enable a vswif interface: esxcfg-vswif -e vswif0
     
   
   

Once you have done all these steps, just find your affected ESX in your VirtualCenter, Disconnect it and Reconnect. This process will uninstall the vpxa agent installed on the ESX host and will reinstall it during the reconecting process.

If after all you still have connections/vMotion/HA problems check ESX host's entry in the VirtualCenter database. Duncan has a great post at Yellow-Bricks that explains what registry should be checked and modified: http://www.yellow-bricks.com/2008/09/29/storage-vmotion-fails-after-service-console-ip-change/

Now it's time to change VMkernel IP address. This change can be done via vClient, or can be done directly from Service Console. Changing VMkernel IP address through vClient it's quite simple, so I'll focus on making this change manually.

As we saw with the method for change the Service Console IP, this procedure depends on deleting the affected vmknic and creating a new one.

1. Again, the first recommended step it's to list all vmknics available on your ESX host. That could be done using the esxcfg-vmknic -l command that will produce an output like this:
   

Interface	Port Group	IP Address	Netmask	Broadcast	MAC Address	MTU	TSO MSS	Enabled
vmk0	VMkernel	xxx.xxx.xxx.xxx	nnn.nnn.nnn.nnn	bbb.bbb.bbb.bbb	00:50:56:aa:bb:cc	1500	40960	true

2. Next, we are going to delete the affected vmknic (the bold one in our example). We'll also need the associated port group:
   
esxcfg-vmknic -d -p VMkernel vmk0
3. Finally, we create a new vmknic with the desired configuration and we associate it with the correct port group. Remember that this procedure will generate a new MAC Address:
   
esxcfg-vmknic -a -p VMkernel -i yyy.yyy.yyy.yyy -n mmm.mmm.mmm.mmm vmk0

Keep in mind that these procedures are valid only for Standard vSwitches, and it's necesary slight modification to adapt it to Distributed vSwitches availables in ESX 4. But that's another history.

I based this post in my personal experience and the information recollected from:

• http://vmwaretips.com/wp/2008/09/12/changing-service-console-ip-address-in-esx-35/
• http://www.yellow-bricks.com/2008/09/29/storage-vmotion-fails-after-service-console-ip-change/
• http://www.yellow-bricks.com/2008/06/04/changing-the-ip-address-of-an-esx-host-and-ha/

I hope this post could help somebody

Winds of change

It's been a while since the last time I updated the blog, and after much thought about the topic I've decided the moment for the change has arrived. Two obvious options arise to me: abandon the blog or keep writing.

If I'm writing this post is because I've decided to bet on the blog once again, but I think that it needs a change of approach. So I would like to start with a new line of work, making a real change of approach. First of those measures I'll take to achieve my purpose is write all my post in both languages, English and Spanish. I'll translate slowly all entries already posted. So I must apologize for my English, I'm quite sure that it will make someone cry.

Vientos de cambio

La verdad es que llevo bastante tiempo sin actualizar el blog, y después de pensar detenidamente sobre el tema he decidido que ha llegado el momento del cambio. Se presentan dos caminos obvios, abandonar el blog o continuar manteniéndolo.

Si estoy escribiendo esta entrada es porque he decidido volver a apostar por el blog, pero creo que necesita un ligero cambio de enfoque, por lo que la nueva linea de trabajo que quiero iniciar irá en este sentido, en hacer realidad ese cambio de enfoque. La primera de las medidas que voy a tomar para conseguir mi objetivo es escribir todas las entradas en Español e Inglés. Iré traduciendo poco a poco las entradas ya existentes. Así que debo pedir perdón por mi nivel de inglés, que seguro que a más de uno le hará saltarse las lágrimas.

One Liner 4: Detección de las interfaces de red desconectadas

Hoy me he levantado "perro", que le vamos a hacer. Tengo que revisar la conectividad de las interfaces de red de mi granja de VMware y no tengo ganas de levantarme a ver las interfaces que tienen problemas físicos, así que he hecho un pequeño One Liner que comparto con vosotros:

Get-VMHost | Sort-Object Name | % { Write-Host -ForegroundColor yellow $_.Name ; (get-view $_.Id).Config.Network.Pnic | Sort-Object Device | % { if ($_.LinkSpeed) {Write-Host -ForegroundColor green ("`t{0} Connected" -f $_.Device)} else {Write-Host -ForegroundColor red ("`t{0} Disconnected" -f $_.Device)}}

La salida del comando es un listado ordenado por nombre de host de las interfaces físicas (pnics) de cada uno de los servidores ESX, donde las interfaces con problemas de conectividad (de cualquier tipo) aparecen en rojo y las pnics operativas aparecen en verde.

Como veis, no es nada del otro mundo, pero te quita de un viajecito al CPD con la libretita de marras contando interfaces y cablecitos.

Lo dicho, que me he levantado "perro"

Despiste 9: Cambiar de usuario en los servicios de vCenter

Este quizá sea uno de los despistes más clásicos, típicos y que dan más coraje de sufrir, sobre todo cuando es la tercera o cuarta vez que le ocurre a uno. A ver, os pongo en situación: uno se pone a hacer el despliegue de una nueva plataforma de vSphere (migración o no) con toda la ilusión del mundo, instala su servidor de base de datos, prepara la base de datos, monta el que va a ser el servidor de vCenter, configura su DSN, instala el software correspondiente (vCenter, Update Manager, Guied Consolidation, etc...), se instala su vSphere client, añade sus hosts y hace las primeras configuraciones de prueba y... Voilá!! todo perfecto, una maravilla, una pasada... (aquí van todos los calificativos que se os ocurran).

En este punto uno reflexiona y dice: "vale, lo he instalado todo con un usuario que es administrador del dominio y esto al de seguridad (o sea YO) no le va a gustar nada, así que vamos a securizarlo un poco" . Activamos el cortafuegos, autorizamos los puertos correspondientes (80, 443, 389,636, 902,903, 8084, 9084 y 9087), revisamos las cuentas de servicios y nos encontramos con la desagradable "sorpresa" (no es tan sorpresa porque el programa de instalación ya nos lo advirtió) de que la cuenta de servicio asociada a los servicios VMware VirtualCenter Server y VMware VirtualCenter Management Webservices tiene asociada la cuenta de administrador con la que hice la instalación (mal royo). Como administradores preocupados por la seguridad vamos y cambiamos la cuenta de servicio por una cuenta sin privilegios que tenemos en el dominio para este tipo de cositas. Vamos a iniciar los servicios de nuevo y... yastá, yalaliaopardadiosmiodemivida!!!! el servicio de VMware VirtualCenter Server no arranca dando un simpático mensajito de error del tipo:

Failed to init tableDef: Column VER_ID does not exist in table VPX_VERSION. Database version may be incompatible.

El problema está en que la cuenta que está autorizada en el servidor SQL Server es la de la instalación original, con lo cual tendremos que toquetear la base de datos. El procedimiento no es original mío, lo he sacado de las communities de vmware, así que podeis ver el post original aquí (en Inglés).

Para los que no queráis traducir, básicamente los pasos a seguir son los siguientes:

1. Abrir el SQL Server Management Studio
2. Buscamos la base de datos de VMware. Si hemos seguido al dedillo el manual de instalación esta será VCDB
3. Navegamos por el árbol de la base de datos hasta VCDB->Seguridad->Esquemas->db_owner
4. Abrimos las propiedades del esquema y le cambiamos el valor del parámetro Propietario del esquema del valor original <vcuser>(el de la instalación inicial) a dbo
5. Eliminamos el usuario <vcuser> de la base de datos. Eso lo podemos encontrar en VCDB->Seguridad->Usuarios. Cuidado de no eliminar el login del servidor con el que se mapea ese usuario.
6. Abrimos una nueva ventana de consulta SQL
7. Lanzamos la siguiente consulta, cambiando <vclogin> por el nombre del nuevo usuario de la cuenta de servicio que le hemos asociado a los servicios de VMware:
1. EXEC sp_changedbowner @loginame = ‘<vclogin>’, @map = ‘true’ 
8. Iniciamos los servicios afectados en el servidor de vCenter
9. FIN

Espero que este POST os ahorre los dos días de dolores de cabeza que me ha llevado a mi solucionar el "problemita"

Despiste 8: Obtener el listado de certificados de una máquina remota

En esta ocasión os dejo un script para obtener el listado de los certificados digitales instalados en el almacén de equipo de una máquina remota. No hay una forma simple de hacer esto con powershell, así que rompiendome bastante la cabeza y navegando por un montón de foros he ido cazando piezas de otros scripts y trozos de código en otros lenguajes para crear este pequeño (aunque creo que útil) script.

El script toma como parámetros el nombre de máquina a la que conectarse (-computerName) y el almacén al que conectarse (-store). Las opciones válidas para el almacén son:

• "Root": para el almacén de certificados raíz de confianza
• "My": para el almacén del certificados personal
• "CA": para el almacén de certificados de entidades emisoras de certificados intermedias
• "TRUST": para el almacén de certificados de confianza empresarial

Es necesario lanzar el script con privilegios de administrador sobre la máquina remota.

Me gustaría también comentaros que el script está en fase alpha y es inestable, por lo que no os puedo asegurar al 100% que funcione en todas las ocasiones, aunque a mí me ha funcionado.

Aquí os dejo el link para que podáis descargar el script: Get-RemoteCerts.ps1

Ver también: social technet