Buenos días, Soy Jose Mª Gris, como cada miércoles estoy por aquí comentando temas del Ecosistema.

Despues de la presentación de vSphere 5.0 yo no esperaba updates de la 4.1, pero aquí está la update 2 de esta versión que para mi opinión ha sido una release muy estable.

Sirva este post para evitar sustos al hacer el update nuestra infraestructura, pues cuando se ha efectuado nos aparece un mensaje “Configuration Issues.  Issue detecte on  xxxxx  Warning: Syslog not configured. Please check Syslog options under Configuration.Software.Advanced Settings.”

¿Y esto? ¿Configuration issue? Pero si lo tengo configurado mas de 6 meses y no me ha dado problemas…..

Recapitulemos un poco. Syslog. Dentro de nuestro sistema o infraestructura es bueno que tengamos un syslog configurado. Este sistema (los hay gratuitos, de pago, en appliance virtual…) nos guardará todos los mensajes que nos han ido generando nuestros diversos sistemas o subsistemas y que no hemos podido ver por cónsola o sencillamente el sistema carece de ella. Podemos recoger los mensajes de nuestros switches, nuestros routers, y por supuesto nuestros ESXi.

De esta forma, ante un problema podremos ver de forma centralizada todos los mensajes que nos han enviado nuestros hosts para efectuar el troubleshooting si es preciso. Personalmente acostumbro a usarlos e implementarlos en mis instalaciones como “best practice”

Y aquí hemos llegado al punto, VMware considera que la instalación de un Syslog es una “best practice” y así nos lo advierte a partir de la versión 4.1 Update 2. Sencillamente el mensaje nos dice “no tienes configurado un sistema syslog”.

Podemos hacer dos cosas:

• Guardarlo dentro de un datastore  (para ello iremos a Configuration/Advanced Settings/Syslog/Syslog.local.DatastorePath  e introduciremos donde queremos guardar el registro)  ojo el formato es [volumen]/folder/fichero.log  (recuerda crear el folder).

• Indicar la ip o hostname de nuestro servidor syslog, informando el campo Configuration/Advanced Settings/Syslog/Syslog.Remote.Hostname

Personalmente prefiero la segunda, no utilizamos Datastores y tenemos centralizados los puntos de información.

En el mercado hay varios syslog, Kiwi Syslog, Winsyslog, syslog watcher o syslog mas complejos como syslog-ng, podemos escoger. 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. Gracias.

Hola, soy Miguel Ángel Alonso y aquí estoy como cada martes para hablar contigo sobre un nuevo tema del mundo de la virtualización de sistemas.

En el tema de hoy y como claramente has visto en el encabezado del post te voy a informar sobre un bug que impide realizar vMotion a algunas máquinas creadas con VMware View 5 sobre la plataforma de vSphere 5.0.

Vamos por partes para tenerlo claro, una primera en la que te informo de cuál es el problema y porqué ocurre y otra en la que puedes subsanarlo manualmente de varias maneras.

Error:

Ageneral system error ocurred: Failed to flush checkpoint data!

El error sólo ocurre cuando la versión de nuestro hardware es 8 y las resoluciones de pantalla en nuestros desktops virtuales son  muy altas.

Cuando tenemos activado 3D en nuestros desktops el problema se arregla por un sencillo motivo, y es que al activarlo  nuestros ESXi5 calculan de manera automática la cantidad de buffer necesario para que vMotion se realiza con total éxito. Si no lo utilizamos, tales cálculos no son tomados y nos dará un error cuando se realice un vMotion de estos escritorios, ya sea de manera manual o automática bajo DRS.

Solución:

Hay varias (3 en concreto) que se me ocurran a bote pronto:

1-    Editaremos el fichero config, localizado en /etc/vmware en nuestros ESXi 5 y le añadiremos la siguiente línea:

Migrate.baseCptCacheSize= “16777216”

Con esto se añade en cada fichero vmx de las Vms de nuestro entorno la opción de asegurarse un buffer lo suficientemente grande como para poder realizar el vMotion en caso de necesitarlo para tal fin. Se le asocian 16 MB en lugar de los 8 MB que vienen por defecto.

2-    Otra opción es habilitar como ya he indicado en el apartado de error, el activar 3D para que nos asegure el buffer necesario para la consecución de vMotion.

3-    Otra es ir a la kb de VMware en la que te mostrará otras posibles soluciones para mitigar el error como bajar la resolución a 1280X1024 o inferior, no actualizar las VMs a Hardware 8.

Bueno hasta aquí por hoy.  Espero que te haya gustado y puedas sacar provecho del post si te has encontrado o lo vas a hacer con este problema, y te emplazo hasta la semana que viene para poder seguir  hablando contigo sobre un nuevo tema de la virtualización de sistemas.

¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.

Hola, ¿como estamos?  Soy Jose Maria Gris y volvemos a estar con todos vosotros despues de este paréntesis estival.

Mientras nos preparamos para la versión 5 de View, tenemos que ir actualizando nuestras versiones y hoy vamos a comentar un caso que he vivido esta última semana. El titulo del post bien podría ser “¿y que pinta el USB en esta fiesta?” pero es mas explicativo creo el que hemos puesto.

La situación es la siguiente. Tenemos nuestro View 4.5 y estamos upgradando a 4.6. Tenemos una VM, un escritorio que lo queremos upgradar el agente. Ejecutamos el Installer y nos comenta el gracioso mensaje “Error 28030. The installer failed to install the USB driver. To ensure a successful installation, please restart your machine and relunch the installer”.

Pensamos de forma inmediata ¿”el USB?”. Dando vueltas y mas vueltas al tema, vemos que hay una KB nueva 2004509 que nos recuerda que los installer anteriores deben estar completados o bien que pueden haber tenido un fin de ejecución no correcto. Osea, que no era un problema “directo” con el USB….

La solución está en completar algun installer pendiente o bien seguir los pasos de la KB 2004509 para limpiar las keys del registro que indican.

Con ello podreis completar vuestra actualización.  Hasta la semana que viene.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

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.

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.

¿Que tal, como estáis? Soy Jose Maria Gris y estoy aquí de nuevo, para hablarte del ecosistema de virtualización.

A veces estás instalando algo y asumes que el entorno en el que estás es el habitual. Presumes que todo el mundo siempre tiene UPS, red eléctrica estable…. e Internet on line.

Bueno, alguna vez he tenido que instalar sistemas donde Internet no estaba disponible ni física ni lógicamente por razones de seguridad. Bien

Alguna vez os puede ocurrir que vayáis a instalar el vSphere Client en vuestro ordenador y no podáis, sencillamente os dará el error 1603 de .NET.

Estará mal montado el .NET? El Firewall, el Antivirus?????….. Me huelo que vamos a aprender algo nuevo…..
Si revisas los logs verás que en un momento dado, .NET busca Internet porque busca componentes opcionales. Ahí está el punto, no está todo instalado.

Solución: o bien instalas la maquina cliente con una conexión temporal a Internet o te bajas el .NET completo.

Saludos a mis colegas de l’Ajuntament de Terrasa donde estamos haciendo un curso de Virtualización.

Take care.

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd\DependOnService

Le añadimos MSSQL$SQLEXP_VIM

Con ello aseguraremos que nuestro vCenter arranque cuando deba.

Por favor, si te ha gustado este post dame tu puntuacion: [ratings]