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"