Parece que continuamos queriendo hacer sombra a Iker de Cuarto Milenio con las cosas paranormales. Si un ESXi no tiene Service Console ¿Cómo es que mi vCenter lo muestra y además me dice la memoria que tiene?
Soy Jose Maria Gris y como cada miércoles estoy aquí para hablaros del ecosistema de VMware y de estas cositas que a veces parecen tontas pero nos dan quebraderos de cabeza.
Es la tercera vez que veo este caso, la primera fue una consulta de un cliente y me dejo “out” pues no entendía lo que pasaba.
Esta situación curiosa ocurre cuando sucede lo siguiente:
Vas a actualizar un ESX a ESXi para que cumpla con las siguientes versiones de vSphere
Tienes el host en producción y lo desconectas del vCenter
Instalas ESXi en el nuevo Host y claro, le das el mismo “hostname” y la misma IP
Cuando lo tienes levantado y configurado, lo “reconectas”
Miras vCenter y lo que era ESX ahora es ESXi, bien
Pero vas a mirar Configuracion – Memoria y ves extrañado que la memoria de la Service Console aún está ahí.
Sencillamente vCenter no limpia la información de la memoria de Service Console. De hecho, si la cambias te pide reboot. Estas viendo la información de tu ESXi pero la información de tu Service Console de tu “noexistente” ESX.
¿La razón? Pués que al reincorporar el host con el mismo nombre y IP, vCenter entiende que es el mismo host y por lo tanto no “refresca” todos los registros. En lugar de hacer un “desconnect”, teníamos que haber hecho un “remove”.
Solucion, haces “remove” del ESXi del vCenter y lo vuelves a incluir. Tu Service Console fantasma habrá desaparecido y todo estará en su lugar. Hasta la semana que viene.
¿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.
Cosas veredes, Nicomedes…. Y es que aún me asombro de que me asombren ciertas cosas. Soy Jose Maria Gris y como cada miércoles aquí estoy con vosotros.
El tema es importante, pues puede llevar a equívocos y no es cuestión de ello con nuestras replicaciones. Pues nada, estas haciendo un montaje de réplicas para asegurar tu entorno virtual y de pronto ves que el amigo vCenter te empieza a explicar que no ha podido crear el disco virtual y que “The requested operation is not implemented by the server”. ¿Y ahora que he hecho?
Pues nada, resulta que cuando haces una replicación entre LUNs con Veeam Backup y lo haces con ESXi y a través de vCenter, pues te casca este mensajito, aunque todo está bien.
Según los foros y nuestro amigo Anton Gostev, se trata de que el vCenter actualmente no implementa ciertos APIs de VMware. ¿??
Lo haces directamente al ESXi sin pasar por vCenter y no aparece el mensaje.
Resumen del caso, según los foros de Veeam no hay ningún problema. Yo lo he probado, he verificado y he hecho failover de mis réplicas y si, no han dado ningún problema.
Hola amigos, soy Florián Murillo. La propuesta de VMware para cloud computing se llama vCloud, pero ¿En que consiste vCloud?
vCloud en un conjunto de productos y tecnologías que proporcionan las herramientas necesarias para construir una nube privada/pública, pero… ¿es suficiente? Vamos a revisar la arquitectura tradicional de cloud computing y donde se ubica VMware vCloud:
Ya tenemos la primera definición: VMware vCloud proporciona la infraestructura y la capa de servicios, necesarios para construir una nube privada/publica.
¿Que incluye VMware vCloud?
Incluye los siguientes productos y tecnologías:
VMware vCloud Director: Proporciona una capa de gestión de la nube, aprovisionamiento de máquinas virtuales desde un catálogo y computación elástica.
VMware vShield Edge: Su misión es aislar (firewall) los diferentes silos de computación entre ellos y proporcionar conectividad VPN site-to-site. Incluye otras funcionalidades como NAT, DHCP y Web Load Balancer.
vCenter Chargeback: Realiza el control de uso, para la posterior facturación a clientes.
VMware vSphere: Proporciona el hipervisor y los servicios de valor añadido del hipervisor: Alta Disponibilidad y Computación Elástica.
vCloud API: Este API, basado en REST, nos proporciona interoperabilidad con otras nubes y aplicaciones.
Mi impresión es que tiene los elementos de base necesarios para transmitir confianza tecnológica a los clientes, probablemente el puzzle esté incompleto y necesite algunos elementos extras:
Un sistema de autenticación y autorización robusto y muy escalable.
Una solución IPAM con pretensiones globales (IP Address Management).
Un IDE (Integrated Development Environment) para extender la solución con plug-ins y módulos adicionales, el API necesario y una gran aportación, pero es insuficiente.
Un interfaz para usuarios finales.
Un cuadro de mandos gerencial de Gobierno del Cloud
Con el paso del tiempo veremos como la solución va creciendo añadiendo nuevos productos, tenemos ante nosotros una época divertida tecnológicamente.
Como cada miércoles estoy aquí con vosotros para ver temas nuevos del ecosistema de VMware. Soy Jose Mª Gris y esto no es el programa de Iker en Cuatro sobre temas paranormales, pero va camino .
Hoy veremos, que si no somos demasiado ordenados o poco metódicos nos encontramos en situaciones como la que hoy hablamos.
Tenemos nuestras plantillas y hacemos un update. (Por cierto, la semana que viene hablaremos de los updates y lo que tenemos que tener en cuenta a la hora de hacerlos)
A partir de este momento, el deploy de nuevas máquinas a partir de nuestras plantillas no tendrá las vmwaretools a fecha de hoy, el famoso “out of date”. Vale, nos vamos a actualizar nuestras templates. Nos ponemos el traje de fregar y a actualizar.
Convertimos nuestra template en vm, actualizamos las vmwaretools y tenemos todo al día, bien, pero….. Vamos a ver los componentes de nuestra máquina y al hacer “Edit Settings” Blum! Nos enseña el mensaje de marras. Por mucho que paremos la máquina y le hagamos de todo, no nos enseña sus intimidades, vergonzosa se nos ha vuelto.
Si editamos el .vmx veremos que tenemos referencias que han cambiado o bien no existen, el ISO del SO que generó la máquina que ya no está, o como este caso el datastore había sido cambiado de nombre.
Podemos editar nuestro .vmx y corregir todo o bien una solución mucho más simple, desinventariamos la vm y la volvemos a inventariar (JMM, nos estamos haciendo un montón de estos eh?).
Con ello podremos acceder a nuestra vm, actualizarla y volver a su sitio.
Ya esta disponible online el quinto episodio en nuestro Web TV show de virtualización en español, un nuevo programa de televisión web que es audaz, innovador y dedicado en exclusiva a los profesionales de la virtualización de sistemas y el cloud computing en español.
Esta semana tenemos una gran leccion de Aena, hablaremos sobre la renuncia por parte de Paul Maritz a la presidencia de VMware, contestaremos a una gran pregunta de un usuario relacionada con el “valor añadido” de Microsoft HyperV y su modelo de licenciamiento y descubriremos una utilidad increíble que te ayudara a gestionar tu centro de datos virtualizado y/o físico desde un único punto de gestión, el servidor de vCenter de VMware.
¿Y tú qué opinas con relación a la pregunta lanzada en el episodio de hoy?¿Cuál crees que es el motivo por el que Paul Maritz ha dejado la presidencia de VMware? Deja tu comentario en virtualizacion.TV o charlemos sobre ello en twitter.
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!!!!
VMware cambiara el modelo de licenciamiento de alguno de sus productos a partir del 1 de septiembre del 2010.
Ciertamente y, a medida que el tema del clould computing se convierte en un estándar mas en los entornos de TI, cada vez más es necesario la gestión global a nivel de máquina virtual (MV), en lugar de la gestión individual del hardware físico donde estas MVs residen.
Siendo ahora las máquinas virtuales, la nueva unidad de gestión – o al menos eso el lo que se pretende -, las empresas de TI necesitan un nuevo modelo – flexible, con opciones, que se ajuste a las exigencias del nuevo modelo – con el que puedan desplegar y configurar estas licencias.
Particularmente algunos productos de VMware vCenter pasaran de licenciarse por procesador o socket a licencias por máquina virtual. Asimismo, otros productos VMware vCenter continuarán siendo vendidos bajo el modelo de licenciamiento existente, es decir, por procesador o socket.
A continuación te muestro los productos que cambiaran el modelo de licenciamiento:
vCenter AppSpeed
vCenter CapacityIQ
vCenter Chargeback
vCenter Site Recovery Manager
Asimismo los productos siguientes no sufrirán ningún cambio en el modelo de licenciamiento:
VMware vSphere
vCenter Server
vCenter Server Hearbeat – a quien le importa!?
vCenter Lab Manager
vCenter Lifecycle Manager
Ya hora aquí va la pregunta: Que pasa si previamente has adquirido licencias por procesador para AppSpeed vCenter, vCenter CapacityIQ, vCenter Chargeback o vCenter vCenter Site Recovery Manager?
Pues bien, VMware te ofrecerá un plan de transición que te permitirá cambiar tus licencias actuales – por procesador – al nuevo modelo de licencias basado en máquina virtual por licencia.
Por consiguiente, si poses licencias por procesador de los productos mencionados, a partir del 01 de septiembre del 2010 podrás hacer la conversión a licencias por máquina virtual.
Hola amigos, soy Florián Murillo y os adjunto una tabla resumen con la misión de cada archivo de log que tenemos en un vCenter Server:
En mi vCenter Server sobre Windows 2003 Standard en español encuentro los logs en C:Documents and SettingsAll UsersDatos de programaVMwareVMware VirtualCenterLogs.
Si vCenter Server estuviera instalado sobre un Windows 2008 los logs los encontraríamos en C:Program DataVMwareVMware VirtualCenterLogs.
Los archivos de registro de actividad son:
Además, hemos de recordar que en el Visor de Sucesos encontraremos registros de actividad de la interacción de vCenter con el S.O., esta información se almacena en la categoría Aplicación, y se identifican por tener un valor de 1000 en la columna Suceso (Event ID).
Hola, que tal, como estáis? Soy Jose Mª Gris y como cada jueves(hoy miercoles) estoy aquí con vosotros para hablar de tema relacionados con el ecosistema de VMware.
Los requerimientos para una máquina virtualizada para vCenter Server son: 2 Procesadores y 3 Gb de RAM.
Pues bien, muchas veces, por aquello que pasa, que con “tanto” ya funciona y pasa lo que pasa.
Oye, ¿Por qué el servicio de vCenter Server siempre falla al arrancar?. Si miras el error, verás que ha intentado arrancar antes que el SQL, la máquina no tenía suficientes recursos para todo.
Como lo solventamos?
Primero. Poniendo suficientes recursos. Segundo. En Windows 2003 podemos configurar que un servicio dependa de otro, que vCenter dependa de SQL. Editamos la clave de registro:
La migración de máquinas físicas o maquinas virtuales (reconfiguración) con vCenter VMware Converter involucra clonar la máquina fuente o imagen y exportar este clone a su servidor destino.
Puedes convertir máquinas virtuales con formatos diferentes de VMware, (Server, workstation, hyperV, Microsoft Virtual Server, imagen) a VMware vSphere ESX/ESXi.
vCenter Converter soporta dos tipos de cloning: clones basados en discos y clones basados en volúmenes. El clone en modo disco solo esta soportado para conversiones en frio (cold cloning). Este método transfiere todos los sectores del disco y preserva los metadatos de todos los volúmenes que estamos clonando. Asimismo este método basado en disco soporta todos los discos, tanto dinámicos como básicos.
El clone en modo volumen esta soportado en las conversiones en frio y en caliente. Los discos fault-toleran en Windows NT no están soportados.
Existe una versión standalone de vCenter Converter la cual tiene una funcionalidad similar a la versión integrada dentro de vCenter Server (mostrada en el video de hoy)
El sistema operativo sobre el cual se instala vCenter Converter va a determinar que máquinas virtuales van a poder ser importadas, exportadas y reconfiguradas. En otras palabras, si instalas vCenter Converter en Windows XP solo podrás convertir máquinas físicas con Windows XP.
El asistente “Import Machine” solo estará disponible si has instalado el vCenter Converter plug-in en el cliente de vSphere.
En este episodio #24 te mostrare a convertir una máquina física con vCenter Convert en caliente (hot cloning):
.
