Hola amigos, soy Florián Murillo, cuando hemos instalado y gestionamos nuestra infraestructura virtual, si alguien me pregunta que base de datos y DSN estamos utilizando, se lo contestaremos, casi sin respirar.
Pero cuando lo hemos de descubrirlo porque vamos a revisar una instalación, pensamos, no hay problema, abrimos el administrador de ODBC y lo averiguo rápido, y de repente Opssss!!!! me encuentro con lo siguiente:
y pienso ¿cual de ellos es el DSN de conexión a la base de datos?
La respuesta no es inmediata, pero es muy sencillo averiguarlo, la respuesta está en el “regedit” o sea en el registro del S.O.
la clave es “HKLM\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB” veamos la imagen siguiente:
¿Que significa cada clave de registro?
1 = Nombre del System DSN utilizado por vCenter Server
2 = Usuario utilizado para autenticarse en la DDBB, observar que no está cifrado!!!!
3 = Contraseña
4 = Driver utilizado
5 = Número de conexiones concurrentes a la DDBB, ver imagen adjunta
Ahora ya tengo claro que conexión estamos utilizando!!!!
Mi buen amigo, Jeff Miller, jefe de prensa en Veeam Software, ha anunciado que Veeam está ofreciendo licencias gratuitas de Veeam Backup y Veeam Replication versión 5 para todos aquellos con la acreditación oficial VCP (VMware Certified Professionals), VCI (VMware Certified Instructors) y VMware vExperts.
Estoy seguro que aquellos que ya tienen la certificación oficial, son instructores oficiales, o, han sido galardonados con la acreditación oficial de VMware vExpert, se alegraran de esta noticia extraordinaria por parte de Veeam.
¿ Alguna vez has tenido el problema de máquinas virtuales inaccesibles ?
Es uno de los errores/problemas mas frecuente que se dan en entornos de virtualización con VMware vSphere ESX/ESXi, y que están relacionados, principalmente, por motivos de perdida de acceso al datastore NFS.
En este episodio nos “bajaremos” de nivel – via ssh – para usar el comando vmkmod_load y poder ver así, los módulos del kernel VMware ESX/ESXi que tenemos ejecutando en nuestro servidor VMware vSphere ESX/ESXi.
En este episodio número #50, en concreto, veremos como podemos confirmar que el modulo nfsclient esta arrancado, así como el comando exacto para arrancarlo si este no estuviera cargado en memoria del VMkernel:
Hola amigos, soy Florián Murillo, y voy a narrar lo que es un día normal en nuestras vidas, imagino que os veréis identificados con esta u otra alegría.
Que tendrá el primer cafe de la mañana que siempre tiene que ser interrumpido, esta vez es un ESX que ha dejado de “ver” una tarjeta de 4 puertos ethernet, con los problemas que ya nos podemos imaginar.
Gracias a que este equipo está en un cluster HA (y que es la hora del café) no afecta al negocio, así que procedemos a recuperar el ESX sin el pánico colectivo de épocas anteriores, cuando no existían infraestructuras virtuales.
Tras varias pruebas se decide volver a reinstalar el ESX, por tanto, así procedemos, y tras la reinstalación (manteniendo el datastore local) celebramos que la tarjeta de 4 puertos ethernet vuelve a ser reconocida.
Pero como este trabajo siempre tiene un “pero”, el “pero” de hoy es que los puertos vmnic han cambiado de nombre, no todo podía ser tan fácil.
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic2 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic3 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic4 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic5 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic6 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic7 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
Cuando antes de la instalación, según la documentación existente (aquí os he impresionado), la situación anterior era la siguiente:
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
Hemos de dejar los interfaces igual que antes, si queremos evitar problemas de diseño e implantación, por tanto pasamos a editar el archivo /etc/vmware/esx.conf
Reiniciamos el host y tras el reboot nos encontramos lo siguiente:
[root@host01 ~]# esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU
vmnic0 0000:08:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1f 1500
vmnic1 0000:08:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1e 1500
vmnic2 0000:09:00.00 e1000e Up 1000Mbps Full 00:26:55:d9:63:1d 1500
vmnic3 0000:09:00.01 e1000e Up 1000Mbps Full 00:26:55:d9:63:1c 1500
vmnic4 0000:0a:00.00 igb Up 1000Mbps Full d8:d3:85:e4:c2:5a 1500
vmnic5 0000:0a:00.01 igb Up 1000Mbps Full d8:d3:85:e4:c2:5b 1500
… lo incluimos de nuevo en el cluster HA y nos tomamos otro café, a ver si este acaba bien …
Hola, soy Jose Maria Gris. He sufrido una intervención quirúrgica de urgencia que me ha dejado durante 3 semanas bastante “off line”. Pero no hay mal que cien años dure…..
De nuevo estoy aquí para hablaros esta vez de dos mundos. El ecosistema de VMware y……. el iPAD!. El Ecosistema se amplía hacia Cupertino .
Que sí! Antes de ir al VMworld de Europa ya me lo había comprado. En Kopenhagen fue increíble ver la concentración de iPAD que había. Y fue allí donde oí que estaban sacando el cliente de vCenter para el iPAD.
Pero no me he podido esperar. Os presento iDatacenter. Disponible en el Appstore a los precios módicos que hay en él. Evidentemente no es un vCenter pero podemos ver lo que está pasando en él y hacer interacciones.
En esta primera pantalla podremos ver la visión general de nuestro Datacenter. El uso de recursos, los disponibles y nuestras VM.
También podemos ver el desglose de nuestro Datacenter en cuanto a hosts se refiere y la vista de VM and templates con sus carpetas administrativas si las hemos creado.
Podemos ver la información que se refiere a un host en concreto. Sus recursos, VMs que corren en el, versión de ESXi que tenemos instalada, sus datastores, incluso, podriamos cambiar el estado del servidor. Podríamos activar el Maintenance mode o bien pararlo.
Por último, evidentemente, nos quedará la vista referente a nuestras VM. Podremos ver como esta el host que la aloja, características de nuestras vms y podremos cambiar el estado de las mismas asi como un storage vMotion de las mismas, aunque no un vMotion.
El autor anuncia nuevas features en breve, de momento a mí lo que hay me funciona muy bien (mejor me va el iPAD), pero bueno. Esperemos el vCenter para iPAD, aunque creo que será un cliente parecido. ¿ O no ?
Bueno, esta pequeña maravilla es lo que tenemos ahora en nuestras manos y es con lo que disfrutamos.
Sois muchos los que diariamente contactáis conmigo para preguntarme las nuevas funcionalidades y precios de VMware vSphere ESX/ESXi 4.1.
Es por lo que hoy, día festivo en España, os propongo que leáis con detenimiento este documento excepcional del web de VMWare donde especifica claramente las nuevas funcionalidades de VMware y las diferentes opciones que hay a la hora de adquirir las licencias.
Es un documento muy interesante que describe, entre otras cosas, las diferentes funcionalidades incluidas en las distintas alternativas de licencias en VMware, que dicho sea de paso, son muchas.
También incluye un apartado donde se describe el proceso de actualización de licencias de VMware versión .3x a las nuevas licencias y las diferentes opciones de actualización que nos proporciona VMware.
Este documento es de obligada lectura para aquellos que tienen pensado actualizar las licencias de versiones anteriores o entender las opciones existentes en cuanto a las funcionalides incluidas en las distintas versiones de licencias de VMware vSphere.
Happy reading y feliz fiesta de la Inmaculada. Felicidades a todas las “Inmaculadas”.
En un post publicado el 22 de noviembre de este mismo año, publique una entrada sobre las políticas de anti-afinidad de un clúster VMware DRS
Permiteme recordate la importancia de VMware Distributed Resource Scheduler (DRS).
Básicamente VMware DRS balancea dinámicamente las máquinas virtuales de un servidor VMware ESX/ESXi a otro servidor o servidores VMware ESX/ESXi para mejorar el tiempo de respuesta de las aplicaciones que las máquinas virtuales contienen.
Cuando un virtual máquina experimenta un aumento de la carga, VMware DRS automáticamente asigna recursos adicionales mediante la redistribución de otras máquinas virtuales entre los servidores físicos.
Sin embargo, VMware DRS no sabe qué servicios dichas máquinas virtuales se están ejecutando con lo que se hace necesario configurar policías de afinidad y anti-afinidad en un clúster VMware DRS.
¿ Te imaginas un clúster VMware DRS donde aplicaciones multi-tier se están ejecutando en diferentes servidores VMware ESX/ESXi y que este se caiga ?
En este episodio número #49 te enseñare a crear políticas de afinidad para tus aplicaciones multi-tier.
De esto modo, VMware DRS se asegurara automáticamente de ejecutar las máquinas virtuales del backend y frontend en un mismo servidor VMware ESX/ESXi y mejor así las latencias de red de estas máquinas virtuales, de modo que la comunicación de red entre dichas máquinas virtuales se “quedan” en un mismo servidor VMware ESX/ESXi.
Hola amigos, soy Florián Murillo y en los cursos de VMware que imparto como VCI detecto que los módulos de networking requieren mas esfuerzos que otros, por eso he pensado que podía ser de utilidad explicar con claridad y brevedad (a ver si lo consigo) como se ha de configurar un switch Cisco Catalyst para conectar sistemas ESX/ESXi.
¿Que nos recomienda VMware?
- Los puertos de los switches donde se conectan los ESX/ESXi se han de configurar con trunk VLAN 802.1q
switchport mode trunk
- Los puertos de los ESX/ESXi no participan de negociación en protocolos como DTP, PAgP o LACP, por tanto desactivar protocolos dinámicos de configuración en los puertos de los switches.
switchport nonegotiate
- Los puertos de los ESX/ESXi no participan en negociaciones de STP (spanning tree protocol) por tanto se ha de desactivar en lor puertos de los switches el envío de BPDUs de STP.
spanning-tree portfast trunk
- En Cisco, la native VLAN es la VLAN por la que circula el tráfico de protocolos de nivel 2, y los que no tiene un tagging de VLAN, por tanto, todos los port-groups han de tener VLAN ID para prevenir que algún tráfico se “cuele” en la native VLAN en vez de “circular” por la VLAN que le toca.
switchport trunk native vlan 99
- Otra cosa a cuidar es que ninguna VLAN tenga el mismo número de VLAN que la native VLAN.
- Todos los puertos de los switches donde se conecta un ESX/ESXi han de permitir, solamente, el paso de las VLANs que se han configurado en la infraestructura virtual.
switchport trunk allowed vlan 10-12, 20
Si vemos la configuración completa del puerto, queda de la siguiente manera:
Estoy de acuerdo que esta configuración no engloba todas las posibilidades y diseños, pero en los temas cubiertos se ajusta a las Best Practices de VMware.
¿ Has tenido recientemente algún problema con las licencias de VMware Site Recovery Manager ?
Nuestro buen lector y amigo Miguel Angel Amigo, valga la redundancia, hace tres semanas nos reportó un “posible” error con el software VMware Site Recovery Manager en los foros de virtualización del blog en español.
En palabras del propio Miguel Angel:
Buenos días y felicidades ante todo por el blog. Soy un seguidor tuyo desde los inicios y tengo los 2 libros tuyos que me han ido muy bien. Mi duda es que tengo un mensaje en los virtual center sobre el SRM que no se ha que se debe, ya que lleva en producción más de 8 meses y no sé porque lo da.
El error que comenta Miguel Angel es que aun teniendo una licencia válida para los dos vCenter Servers, necesarios para poder licenciar nuestra copia de VMware Site Recovery Manager, este reportaba que dichas licencias de ambos CPDs habían expirado.
The SRM License ” at Site1 license has expired ->
The SRM License ” at Site2 license has expired ->
Ciertamente he visto muchos entornos de VMware Site Recovery Manager pero este error me desconcertó, hasta tal punto que no tuve más remedio que aconsejar a nuestro querido amigo y lector, el abrir un ticket de soporte directamente con VMware. Y gracias que lo abrimos!.
Esto es lo que nos dijeron nuestros compañeros de soporte en VMware:
As per your email, I understand that the assigned licenses in vCenter Server for SRM 4.0 shows as 0.You have ESX hosts running in vCenter Server on disaster site as well as on production. You have applied licenses for SRM but it still shows the count in assigned columned as 0.The issue related to the query is known and we are working on this issue. Though the assigned licenses shows as 0 but ESX hosts will get licensed for SRM. You can check fail over test to know whether SRM is working. If there is any issue in fail over test, please let us know to check the cause of the issue.
Después del primer contacto con el soporte de VMware, Miguel comprobó que efectivamente los test de Recovery plan funcionaban a la perfección a lo que VMware admitió que corregirán via parche en una próxima versión.
As for as assigned licenses is concerned, we will release the patch to fix the issue. You will be informed about the new patches accordingly.
Muchas gracias querido lector por hacer público tu problema con VMware Site Recovery Manager, y muchas gracias a VMware por la extraordinaria rapidez en solucionar el problema a su cliente.
Hola. Soy Miguel Ángel Alonso, y aquí estoy como cada Martes para hablaros sobre 8un nuevo tema del mundo de la virtualización.
En este caso hoy vamos a hablar de Centrix WorkSpace Discovery, una herramienta gratuita que nos permitirá hacer estimaciones de ahorros, usabilidad e implantación dentro del marco VDI, y más en concreto, de las aplicaciones corporativas de nuestras empresas que pueden correr en las estaciones de trabajo virtualizadas.
Como dije anteriormente, Centrix WorkSpace Discovery es una herramienta gratuita que permite a las organizaciones ver, entre otras cosas, qué aplicaciones activas están instaladas en sus ordenadores de sobremesa o portátiles y cómo se utilizan.
Centrix WorkSpace Discovery, apoya el desarrollo de casos de negocio inicial para el cambio a las nuevas tecnologías de virtualización de aplicaciones y brinda a las organizaciones la capacidad de ver las áreas potenciales para el ahorro de costos y optimización de su entorno actual. Con el uso de este software, las organizaciones pueden comenzar a manejar sus entornos de TI como un marco de servicio y mejorar la eficiencia de costo y de los servicios aplicados.
Con Centrix WorkSpace Discovery, podremos tener una estimación de precios, usabilidad de las aplicaciones y muestreo en términos comparativos dentro del marco de la virtualización de aplicaciones para así poder ver el ahorro de costes e implantación de dichas aplicaciones corporativas.
Para poder instalar esta aplicación, son necesarios los siguientes requisitos:
1- NetFrameWork 3.5.
2- IIS (Role).
3- Minimo un SQL Express.
4- Instalación del agente de Centrix en las estaciones de trabajo en las que queramos controlar el WorkFlow de las aplicaciones.
Una vez hayas realizado la instalación del producto, veras en una de las secciones del programa, donde se pueden ver los valores recogidos y tablas comparativas de nuestras aplicaciones.
Para que los valores recogidos sean fiables, el proceso de assesment de las aplicaciones de tu entorno, debería estar recolectando datos por al menos una semana.
Bueno hasta aquí por hoy. Nos vemos la semana que viene con un nuevo tema del mundo de la virtualización.
Gracias por estar ahí como siempre y hasta la semana que viene.
