Dejad que Nutanix se acerque a mi. Y a tí.

Nutanix es una solución Hiperconvergente (HCI) que está dando mucho de qué hablar, y no por falta de méritos, el producto está madurando rápidamente y cada vez más frecuentemente, resulta la elección final de muchas empresas a la hora de afrontar nuevos proyectos orientados a la cloud privada y/o híbrida.

El producto dispone de una versión denominada Community Edicion (CE) que es gratuita y nos permite conocerlo más de cerca, aunque las exigencias de hardware para ponerlo en marcha por nuestra cuenta son un poco altas y nos tira un poco para atrás a la hora de montarlo por nuestra cuenta ya que, como mínimo necesitamos 16 GB de RAM para la CVM, 200 GB en SSD para caché y, bueno, tan solo unos 500 GB de HD para datos. En términos prácticos, no parecen requisitos muy exigentes, pero si se convierten en críticos si pretendemos dedicar un equipo entero solo para ésto.

Si vas sobrado de recursos, no pierdas tiempo y ve directamente al proceso de instalación después de haber creado un USB de arranque con la ISO. Si, por el contrario, eres un homínido terrestre, ajénamente financiado por el sudor de tu frente, tenemos la posibilidad de montarlo en virtual como un Hipervisor anidado o como dicen en la scene, nested, y de éste modo rebajar las exigencias de hardware. Eso si, vamos a tener que aportar, al menos 8 GB de RAM, 4 vCPU y unos 30 GB de nuestro SSD. Si, como lo oyes, un SSD va a ser necesario.

Update 08/02/17: Probado en un stick USB 3.0 de 128 GB sin problemas 🙂

A continuación voy a exponeros los pasos necesarios para lograr tener un nodo de Nutanix corriendo en virtual usando VMware Workstation para Windows, con 8 GB y 30 GB de espacio en disco SSD. Éstas son las fases:

REGISTRO EN NUTANIX

Lo primero que tenemos que hacer es registrarnos de forma gratuita.

1. Visitamos la web oficial de Nutanix. Podremos acceder a recursos e información que nos resultarán útiles para un primer acercamiento al producto.

2. Seguidamente hay que proceder a descargar el Community Edition del foro correspondiente.

3. Extraer el fichero .img que está dentro de la ISO.

4. Renombrar el dichero a ce-flat.vmdk

5. Crear el siguiente fichero de texto y renombrarlo como ce.vmdk

# Disk DescriptorFile
version=1
encoding=”UTF-8″
CID=a63adc2a
parentCID=ffffffff
isNativeSnapshot=”no”
createType=”vmfs”

# Extent description
RW 14540800 VMFS “ce-flat.vmdk”

# The Disk Data Base
#DDB

ddb.adapterType = “lsilogic”
ddb.geometry.cylinders = “905”
ddb.geometry.heads = “255”
ddb.geometry.sectors = “63”
ddb.longContentID = “2e046b033cecaa929776efb0a63adc2a”
ddb.uuid = “60 00 C2 9b 69 2f c9 76-74 c4 07 9e 10 87 3b f9”
ddb.virtualHWVersion = “12”

Nota: En mi caso, trabajando con Workstation 12, la última línea corresponde con mi versión del virtual hardware. Si utilizáis una versión anterior, cambiad ese número por la correspondiente.

Quedarán dos ficheros vmdk en la carpeta.

6. Confirmamos el correcto contenido del fichero ce.vmdk

CREAR LA MÁQUINA VIRTUAL

1. Definimos una nueva VM personalizada en VMware Workstation.

2. Compatibilidad con tu versión actual.

3. No instales el OS ahora.

4. Elige Linux, CentOS x64.

5. Cambia el nombre de la VM a NutanixCE.

Al elegir la ubicación de tus ficheros .vmdk te saldrá un warning, es normal, dale a Continuar.

6. Añade 2 Procesadores y 2 Cores para completar las 4 vCPU

7. Selecciona 8 Gb de RAM.

8. Selecciona SATA como tipo de disco.

9. Selecciona LSI Logic como controladora de disco.

10. En mi caso, voy a usar mi propia red, y le daré una IP real de mi subnet.

11. Al crear el disco, selecciona usar disco existe.

12. Localiza el fichero ce.vmdk y seleccionalo.

El resultado final de confirmación es este. Pulsamos Finish.

13. Marcar la Virtualización de procesador para poder crear VMs, aunque no tendremos muchos recursos la verdad, pero es necesario para la instalación.

14. Ahora solo nos queda añadir los discos de Caché y Datos. Empezamos por el primero, seleccionando SCSI.

15. Indicamos un tamaño de 201 GB, en un solo fichero y seleccionamos su ubicación.

16. Repetimos el mismo proceso para crear otro disco de 501 Gb. Esta sería nuestra Virtual Machine final.

ARRANCANDO QUE ES GERUNDIO

1. En ésta fase arrancamos nuestra máquina y si nuestros recursos disponibles son suficientes lo más seguro es que nos topemos con un intento de arranque PXE.

2. Ésto es normal ya que la controladora ISCSI tiene prioridad y nuestros discos no tienen nada, asi que nos toca pulsar F2 durante el arranque para entrar en la BIOS de la VM.

3. Movemos nuestro disco SATA de la última posición a la primera, salimos y guardamos.

4. En el siguiente arranque nos aparecerá una primera sonrisa en la cara al ver que las cosas funcionan como nosotros queremos y observamos el logo de Nutanix.

Y tras unos pequeños segundo de tensión nos encontraremos el prompt de linux.

4. Introducir el usuario root y contraseña nutanix/4u

Editamos el fichero de requisitos con el siguiente comando:

vi /home/install/phx_iso/phoenix/minimum_reqs.py

Identificamos los valores resaltados en amarillo, y modificamos el valor MIN_MEMORY_GB reemplazando el 15.0 por un 6 y guardamos los cambios, recordad que se sale activando el modo comandos con ESC + : , y luego guardamos y salimos con wq!

5. Ahora nos toca modificar el numero de IOS necesarios en nuestro SSD, para no quedanos cortos bajaremos el valor de 5000 a 500. Para ello editamos el siguiente fichero:

vi /home/install/phx_iso/phoenix/sysUtil.py

En apenas un avance de página aparecen las entradas buscadas, editamos y cambiamos ese valor de 5000 por el de 500 tanto para lectura como para escritura.

6. Sin salir del editor, ahora debemos buscar la linea Custom_Ram=12  que indica el valor mínimo de RAM para la VCM. Hay que localirlo y cambialo por un 6. Puede costar encontrarlo entre tanta linea, yo os aconsejo que vayáis al final del archivo y pulséis 5 retornos de página. Entonces lo tendréis en primera posición.

7. Ahora vamos a grabar los cambios y desde el prompt de root vamos a salir del shell escribiendo exit , y nos volvemos a logar esta vez con el usuario install. En este momento es cuando empezará la verdadera instalación y veremos si nuestros maquillajes han tenido el efecto deseado.

Lo primero que vamos a ver es la ventana de seleccion del idioma, elegimos el nuestro.

8. Después confirmamos la identificaciones de los dos discos.

Durante unos segundos iniciará los discos y comenzará a validar el rendimiento de los discos. Si no resultara satisfactorio, seguramente sea por el rendimiento de nuestro disco SSD, en ese caso volved a editar el fichero sysutil.py y bajad aun mas los valores de IOS de disco.

9. Nuestra próxima tarea es completar los datos de red de nuestro sistema.

Debemos añadir la dirección IP de nuestro Host, la dirección IP de su CVM, y completar el resto de los datos, marcar la creación de single cluster y leer toda la EULA, bueno avanzar página como si no hubiera mañana nos vale. Finalmente pulsar Start .

No os entréis en pánico si veis errores del tipo:

Dejad que termine. Es un proceso largo, pero indoloro. Los vmdk comenzarán a expandirse,aunque no más allá de los 30 GB.

10. Cuando finalice, os pedirá que pulséis ENTER y la VM se reiniciará. En pocos segundos veréis el prompt inicial, con mención a la CVM y su dirección IP. No os logéis.

El mágico momento que estábamos esperando para poder abrir nuestro navegador ver algo ha llegado. Escribid la url formada por la IP de nuestra CVM y el puerto 9440. En mi caso es la ip 192.168.0.81 así que la url es:

https://192.168.0.81:9440

Ahora logaos con admin/admin y os pedira cambiar la password, escoged una buena que no se os olvide como por ejemplo *******, y como último paso introducid vuestras credenciales de registro de la web de Nutanix.

Nota: Si durante el registro tenéis un error similar a este:

Posiblemente no tenga resolución para localizar los servidores del frabricante.Abrid un SSH a la IP de la CVM y logaos con usuario nutanix y password nutanix/4u

Intentad un ping a nutanix.com. Si no logra llegar, ejecutad este comando:

ncli cluster add-to-name-servers servers=8.8.8.8

Probad de nuevo el ping y reiniciar la VM.

Finalmente debería aparecer el portal inical de PRISM, donde podréis cacharrear, no sin ciertas limitaciones, claro. Recordad que esto es una ñapa para practicar o realizar alguna demo a colegas, partners, etc.

A partir de ahora se abre un nuevo mundo de posibilidades y dudas que nos harán crecer profesionalmente. Espero que os haya gustado y pueda seros útil.

COOL…NUTANIX EN CASA…..!!

vExpert 2017. Nota personal.

VMware ha hecho pública la lista de seleccionados a vExpert de este año. Podéis ver el listado de los ganadores aquí.

Aunque no es una acreditación oficial, VMware selecciona anualmente aquellos que, de alguna manera, han participado en extender el conocimiento e implantación de sus soluciones y dedican tiempo más allá de sus responsabilidades a éste propósito. No vendemos ser más listos que nadie, pero si poseemos una particular pasión por ésta tecnología que raramente tiene su reconocimiento en los entornos laborales dentro de éste, nuestro viejo e impredecible país.

Por eso, en cierto modo, y en nombre de los profesionales que compartimos éste interés, me enorgullece poder enarbolar en silencio y durante los próximos 12 meses el distintivo de VMware vExpert 2017 por tercer año consecutivo.

“Por un nuevo reto, por un nuevo año lleno de conocimientos que compartir.”

Cheers 🙂

I want a full vCSA 6.5 backup

Whenever you decide backing up the vCSA 6.5 Database, as part as the greatest features of vSphere 6.5, these are a few tips to consider:

• Backup can be performed anytime, no downtime is required.
• Use encryption option using AES 256 and do not lose the password.
• Prepare a remote for transferring. Possible options are: FTP, SFTP, HTTP, HTTPS
• Make sure the target folder is empty.
• Grant write permissions.
• Even then, some errors might happen like:

That issue happens when a specific vCSA service is not running. Here’s how to deal with the services in the vCenter Appliance:

service-control is the main command. Using status as parameter you’ll have a quick and clear view about which services are running and which are not.

service-control –status:

We found our lazy service is not running, so now it’s time to wake up. Easy as typing the following:

service-control –start vmonapi

Now the faulty service is up and running. After this no more issues happened with the Backup Procedure.

Let’s check the folder:

What we have on the remote site is not a single backup file. Remember:

• This backup procedure is a file-level backup.
• This backup is only for vCSA, we have to perform the same task on our PSC in an external deployment.

To know much more about vCSA services check here

A more detailed information about how to perform a vCSA Database backup is here.

Validate vRA Installation with SQL

I’ve been trying a fresh vRA installation on my lab but unfortunately I’ve faced a lot of limitations due to the current lab capacity. I ended up tuning the right amount of RAM for each virtual machine involved in the deployment and eventually systems where ready to fit in my particular limitations. I was ready to install vRealize Automation 7.

I deployed the vRA OVA file and instead of running the wizard, I tried setting up a new MS Windows SQL and IIS Server and installing the vRA Agent and then the vRA IaaS Installation Software but unfortunately after meeting the requisites I wasn’t able to pass the installation procedure. Logs just mentioned errors I could not understand.

Then I started out using the vRA Wizard that makes you feel confident about a successful install. It wasn’t as I expected and it sadly took me more time due to the validation we need to overcome prior to installation.

First there’s a Prerequisites list we need to meet, this takes time but it wasn’t a big deal because it mainly focuses the IaaS Server, SQL and IIS services.

On contrary, there is a final validation procedure before the installation that caused be some trouble when checking Database, Web and Manage Services. I had the following long error related to the SQL Database:

Named Pipes Provider, error: 40 – Could not open a connection to SQL Serve

This error is very common if you have installed MSSQL, normally it is fixed enabling Named Pipes on your SQL Server Network configuration protocols but in this case it did not fix it. Back to the documentation I found the 1433 TCP port must be used for MSSQL and no other. I always thought Port number 1433 was the default one but when running a netstat -a on my MS Windows machine there wasn’t any 1433 port. It was clear for me that my MSQQL wasn’t listening on 1433 and I had to refresh some SQL Stuff to fix it.

So here’s what I did:

Edit the TCP/IP Properties on the SQL Server Network Configuration, you can notice on IP1 that TCP Dynamic Ports has a 0 and TCP Port is empty. Well, first option tells MSSQL to use random ports for listening to connections so:

• Remove that 0 and leace TCP Dynamic Ports blank
• Add 1433 to the TCP Port on every IP entry

• Scroll down to IPAll and add the 1433 TCP Port number as well.
• Now restart the SQL Service.

A new netstat command launched showed me the right port this time:

So when I relaunched the Validation procedure I finally had a bright green light and a handful of good expectations 🙂

Merry Chistmas and happy new Lab !

Hint 1: This VMware KB is worth reading.

Hint2: When you log off from the vRA wizard it won’t be running again unless you open a SSH connection to vRA appliance and run the following command:

vcac-vami installation-wizard activate

 

 

Migrating vCenter Server 6 / vCSA 6 to vCSA 6.5

One of the most exciting changes in vSphere 6.5 refers to the vCenter Server Appliance. With this version, vCSA becomes The King in the North, he’s in charge,  the boss, the head man, the top dog, big cheese. I really want to try it and now it is time to upgrade my lab. In earlier versions we’d have to install a new vCSA but now, we just need the right ISO file 🙂

Windows vCenter Server -> vCSA 6.5

1. Enter the SSO Administrator credential and wait for the script to complete the deployment.It will take a little to identify your current information and will show a message “waiting for migration to start” when ready:
2. Go to another windows machine – must be different form the existing vCenter – prepare to mount the VMware VSCA 6.5 ISO and launch the following program: vcsa-ui-installer\win32\ installer Select the Migrate Option
3. Type the right information required for the vCenter Server. Click Next and Accept the Certificate window.
4. Now it’s time to determine where new VCSA appliance is going to be deployed. Type the Target ESX, and credentials. Accept the Certificate window as well.
5. Time for typing the name for our new brand vCSA virtual machine and password.
6. Now it’s time for choosing the final deployment size
7. And which datastore is going to be used.
8. Finally the temporary networking settings. Make sure you use a reachable subnet network.
9. Last window is a summary, check all information and click Finish when ok.
10. Now the process will take a bit longer. Your future vCSA 6.5 is being deplyoed.

Update: During this post creation I noticed there was another brilliant post regarding this procedure here, so I decided to give a short explanation of what is next and continue my post by starting covering also the upgrade for an existing vCenter Appliance.

So after a successful deployment, our new vCSA 6.5 is running partially operational. A second installation stage is beginning to configure the new appliance, export the main existing configuration, power off the source vCenter and import the data to the new vCSA. Last step is accessing our new vCenter Appliance using the management url and replace the IP address with the right one.

 vCSA 6.0 -> vCSA 6.5

A key point here is that you could achieve this upgrade on from vCSA 5.5 Update2 version or later. In my case, 6.0 is in place. As I had my lab with an external PSC, another important thing to remark is that I needed to do this procedure twice. One for upgrading PSC and another for vCSA. This part is focusing just on the vCSA as I already upgraded my PSC before.

1. We are starting from the same .ISO and the same installer, but this time we are going to perform an Upgrade, choosing the second option: MIGRATE.
2. Now we are going to type the data for both our current vCSA and the ESXi where the appliance is running. Click NEXT when ready.
3. Again we are prompted for the Target ESXi wher the new vCSA is going to be deployed. Type it and press NEXT.
4. Now type the name for the new vCSA and confirm root password. NEXT when ready.
5. As in the migration procedure, we have to select the infrastructure size we are dealing with. Choose it and press NEXT.
6. Target datastore is our next option to choose. Select the right one and click NEXT.
7. Now its time for networking parameters. Click NEXT when ready.
8. Confirm the summary window and press FINISH.
9. The installation progress window is displayed. Now it is time to have a coffee.
10. When the stage is done, we are ready to begin the last stage.Press CONTINUE.
11. Next stage is ready.Click NEXT.
12. A new input for the existing vCSA and ESXi is needed. Press NEXT when ready.
13. Now we need to decided what is going to be copied to the new appliance. Press NEXT when ready.
14. A new confirmation has to be done. Press FINISH when ready. We can’t proceed whitout checking the text regarding the backup.
15. We need to know the Source vCSA is going to be shutdown. Confirm pressing OK
16. Data will start to be transferred between to the new vCSA. Time for a short break.
17. When the transfer is done, we can close the window noting the urls shown below. Basically they are still the same.
18. When we access for instance, to the Appliance URL we can see a new option for HTML5 is available, not fully operational though. 😦

In any case, a new vCSA 6.5 is running on our system and it goes like that:

We can appreciate it is fastest, as the Fling Appliance already did, so a new fress web client to get used to 🙂 . Don’t forget to delete the older versions once you confirmed the proper working of this new 6.5.

 

Chaíto !

VMware Learning Zone

Most of you will surely know the VMware training portal and all the well-known resources VMware offers for a self-study but I want to point out this particular site where you will find:

• Fully 24/7 access.
• Videos including the latest NSX and VSAN technologies.
• Self-paced eLearning courses.
• Recorded webcasts.
• Additional and great stuff for Official Exams

Some are fundamental content, but nevertheless, it is worth watching. Go now for a 60-days free trail right here.

Caution: You might become addicted.

 

Todo es fabuloso . . . o no ?

Los switches distribuidos han sido uno de los más importantes cambios introducidos en vSphere desde la versión 4. Facilitan no solo el despliegue de nuevos hypervisores , tambiéns aportan un único punto de administración que facilita su gestión. Gracias a esta nueva funcionalidad podemos hacer uso del fabuloso NIOC (Network IO Control) que además nos garantiza una buena gestión del ancho de banda en un entorno donde usamos adaptadores convergentes de 10GbE o más, concrétamente en momentos de alta demanda como son las tareas de vMotion.

Networking is awesoooooome . . .

Os podéis imaginar cómo sería poder ver los paquetes de nuestras máquinas virtuales circulando por la red, entrando y saliendo de nuestros Uplinks como si fueran piezas de LEGO cantando aquello de “Todo es fabuloso”. Porque en realidad, lo es. Hasta que tu vCenter decide dejar de cantar en armonía y dar el salto a nuestra realidad con un tremendo casque.

Puede ser algo habitual, como una parada de servicio, una falta de espacio en disco, o simplemente lo ha reiniciado el HA por un error inesperado en el ESXi dónde estaba corriendo y la cosa tarde un poco más en arrancar de lo que esperábamos. O desafortunadamente nuestra BBDD se ha ido al garete. El caso es que sabemos que vamos a tardar más tiempo del esperado en traer nuestro vCenter de vuelta.

Normalmente no tenemos demasiada presión porque nuestras máquinas van a estar funcionando y dando servicio, manteniéndose totalmente ajenas al apagado de nuestro vCenter. El asunto se nos puede complicar cuando, por cumplir ciertos SLA,  nos demandan realizar una migración de una VM a otro ESX dentro del clúster en ese preciso momento. Suena raro, pero lamentablemente, en ocasiones existen pequeñas diferencias a nivel de networking que hacen que una VM de serios problemas en uno de los DC’s cuando se trata de un Cluster extendido. En  un reciente caso, la máquina en cuestión perdía toda conectividad resultando ser totalmente inaccesible. Os imagináis que esa VM sea la BBDD del vCenter ?. Al conocer las virtudes y defectos de nuestro entorno, sabemos que si la VM la pasamos a otro Host ubicado en el DC contrario recuperaríamos nuestro mundo fabuloso de nuevo, y eso es lo que me ha tocado hacer.

Recordáis el “No Martini, no party !”?. Pues en nuestro caso aplica a “No hay vCenter, no hay vMotion”. Y como quiern no quiere la cosa van pasando los minutos, los indicadores ya marcan un DEFCON 2 y algunos alrededor nuestro comienzan a sufrir ciertas contracciones por lo que viene siendo la bajante principal. Todo un indicio claro de que ésto empieza a ser serio, y nos va a tocar improvisar para traer de vuelta ese vCenter.

Tiempo atrás, el vCenter era una herramienta exclusiva que solamente utilizábamos los responsables de la plataforma de virtualización, en realidad, en España, hace 4 años nadie ajeno a virtualización conocía el vCenter Server mas allá de una máquina Windows que era crítica para nosotros y que usaba una Base de Datos. Si se nos caía el servicio, nadie se enteraba. Eso de instalar un programa que, tras escribir un nombre de máquina, usuario y password, te abría un entorno gráfico con Hosts y Virtual Machines, te permitía acceder a las consolas de cada una de ellas, montar ficheros ISO, añadir y quitar discos, adaptadores de red…. todo eso, era algo desconocido y misteriorp  que solamente conocíamos nosotros. No exagero si os digo que hablar de vCenter (“viCenter“) en algunos proyectos de hace años, para otros equipos de trabajo era como quien tenía un primo llamado Vicente. Hoy en día vCenter Server es una herramienta ampliamente conocida y utilizada por el resto de equipos de trabajo. Backup, Monitorización, Storage, etc. Por tanto,  la criticidad de “Éste, nuestro servicio” se ha incrementado con el paso de los años.

No vamos a realizar un vMotion, eso está claro, pero si podemos aprovechar la falta de servicio para apagar la máquina en cuestión – en éste caso la BBDD del vCenter- y que eso nos de opción a registrar la VM en otro ESX desde su Datastore. Es aquí donde quiero llegar con este post, hay que tener siempre en cuenta que trabajar con los vDS nos facilita la vida, pero toda la información relativa a su configuración y todos sus PortGroups residen en la BBDD del vCenter y están accesibles mientras lo esté el propio vCenter server. Por tanto antes de hacer esta operación hay que recordar que cuando vayamos a registrar la misma VM en otro ESX, mediante nuestro vSphere Client, todas las VLANS que actualmente residen en el vDS no estarán disponibles y nos quedaremos con el culete al aire.

Hemos perdido el vCenter !!!!

Ésta situación es algo confusa, pero real. Y es el comportamiento normal cuando se crean los Port Groups por defecto en un vDS, es como funciona la asignación por defecto y que todos usamos, es el Static Binding. Con ésta opción por defecto, cuando conectamos una VM a un PortGroup, se asigna y se reserva un nuevo puerto inmediatamente. Por supuesto garantiza la conectividad en todo momento, incluso si el vCenter está “apagado o fuera de cobertura”.  El puerto se desconecta solo al quitar la VM de ese PortGroup.

También existe un segundo modo, que prácticamente está en desuso, llamado Dynamic Binding. En este caso el puerto se asigna y reserva cuando la máquina se enciende – y además tiene conectada la NIC. Del mismo modo, el puerto se elimina cuando la VM se apaga o se desconecta su adaptador de red desde el vSphere client. Obviamente éstas VM solo pueden encenderse y apagarse desde el vCenter.

El modo más avanzado corresponde al Ephemeral Binding. En este modo el puerto también se asigna y crea al encender la VM teniendo el adaptador de red en estado “conectado” pero a diferencia del Dynamic, es el Host el que realiza esta asignación, pudiendo actuar de forma independiente del vCenter Server. Ésta sería nuestra opción adecuada para un caso como el que vengo planteando. Por supuesto, una vez apagada la VM, el puerto se borra.

 

Vmware recomienda usar este último modo de creación de puertos solo para propósitos de recuperación. Sinceramente no he apreciado en prácticamente ningún entorno por los que he estado la selección de éste tipo de binding. En el escenario que estoy planteando, con el Static Binding, tenemos que seguir improvisando.

De modo que nos encontramos ahora mismo con la VM que contiene nuestra BBDD registrada en el ESX que está en el DC correcto para garantizar su funcionamiento, está apagada, y no podemos seleccionar la VLAN correcta porque pertenece a un PortGroup creado por defecto en un Switch Distribuido y el vCenter está KO.

En esta situación necesitamos sacarnos un PortGroup para poder Taggear la VLAN correspondiente, y lamentablemente solo podemos hacerlo en un vSS (virtual Standard Switch) en nuestro ESX. Podemos crear el vSS, pero nuestros vmnics están todos ya asignados en nuestra , ya madura, infraestructura.

Una de las maravillosas funcionalidades de una infrastructura vSphere que, por supuesto siga las buenas prácticas, es la facilidad de crear tolerancia a fallos, en nuestro caso la que nos vendría de maravilla sería aprovecharnos de la redundancia de los adaptadores de red y disponer de, al menos, dos Uplinks totalmente funcionales en nuestro vDS.

Con esta simple y mínimamente exigida configuración, podríamos ‘romper’ esa redundacia sacándo un vmnic del vDS y añadírselo a nuestro recien creado vSS. Ahora, solamente necesitaríamos crear un PortGroup con la VLAN de nuestra BBDD y posteriormente seleccionar esta nueva VLAN para que la use nuestra ansiada VM editando sus propiedades.

Recapitulando. En este punto tendríamos nuestra máquina de BBDD del vCenter registrada en el ESX adecuado dónde tenemos garantizada su conectividad, además está conectada a un vSS que solo existe en ese host,  usando uno de los vmnics que formaban NLB en el vDS, y finalmente conectada a un PortGroup que tiene la VLAN correctamente taggeada. Tenemos todos los ingredientes para el éxito. Así pues, tras encendérla, nuestros servicios de vCenter serán capaces, y de hecho lo fueron, de poder conectar con la BBDD y arrancar de forma satisfactoria. Nuestro vCenter volvío a la vida.

Vicente Viveee…!!