Error al arrancar el servicio vCenter Server al arrancar la máquina.

Hola, que tal, como estáis? Soy Jose Mª Gris y como cada jueves estoy aquí con vosotros para hablar de tema relacionados con el ecosistema de VMware.

Pregunta de Examen. Requerimientos para una máquina virtualizada para vCenter Server. 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

Saludos.

 

La máscara EAX

Hola que tal? Soy José Mª Gris y como cada semana vengo a comentaros alguna cosa sobre el ecosistema de Virtualización con VMware.

Días atrás, nuestro amigo jnavapal nos preguntaba lo siguiente:

“Te explico mi actual situación he configurado mis servidores para poder realizar vmotion y drs pero me he encontrado con al sorpresa que no me deja uno de ello por problemas con la mascara “eax” me gustaría, si pudieras, q me explicaras un poco como solucionar ese problema y que implicaciones tiene”

Como comenté en su día, no está soportado por VMware, pero lo he visto funcionar y evidentemente lo desaconsejo para producción. Quede claro que lo que aquí comento es a efectos formativos y no significa para nada ninguna recomendación.

Dicho esto, esto ocurre cuando tenemos procesadores distintos con niveles distintos. Es importante que tengamos a mano la herramienta de run virtual VMware CPU Host Info. Nos la descargamos y la ejecutamos desde un entorno windows que tenga acceso a nuestro vCenter (Vicente para los amigos) y a nuestros hosts.

Lo ejecutamos con la opción debug (importante) para que nos muestre los binary directamente.

La primera pantalla nos mostrará nuestros ESX, cuantas CPU tienen, si soportan FT, VT, etc., información interesante. Para el caso que nos ocupa, mal vamos, las CPUs parecen iguales.

Pero lo que nos interesa de verdad viene en la ventana de atrás….

Aqui vemos los registros EAX, EBX, etc de nuestas CPUs. Pues sí son iguales, podremos hacer vmotion sin problemas. Pero esto no es lo que nos preguntan. Si no falla Vmotion por este concepto, nos aparecerá un mensaje que nos dirá algo como “Hay un problema con el registro EAX”. Bien, entonces tendremos que hacerlos iguales.

imaginemos una máscara y la “distinta”

0000 1110 0000 0000 0000 0000 0000 1000

0000 0000 0000 0000 0000 0000 0000 1011

Nos vamos a una VM, “Edit Setting”, “Options”, “CPUID Mask” y ahí en “Advanced”, nos aparecen nuestros registros de las CPUs y si hacemos click sobre uno veremos las máscaras (ya llegamos…. ). Las máscaras nos interesan las X (Unused), 1 (enable feature), 0 (Hide feature) y la H (Allow Guest software to see actual feature value.) Con ello si tenemos

XXXX HHHH XXXX XXXX XXXX XXXX XXXX HHHH

Querrá decir que el segundo y el cuarto cuarteto son los que “permiten”, con ello lo que deberíamos modificar es lo siguiente

---- 000- ---- ---- ---- ---- ---- 0-00

y quedaría como final mask:

XXXX 000H  XXXX XXXX XXXX XXXX XXXX 0H00

Y esto hacerlo a las VM que queremos hacer vMotion. Reitero, no lo uséis en producción.

Aprovecho para indicar las opciones “Hide the NX flag from Guest” (Con lo que podemos ganar compatibilidad en vMotion pero podemos perder algúna feature de seguridad de nuestra CPU. “Expose th NX flag to guest” Mantendrá todas las features de seguridad activas.

Cuidado con usar la máscara porque podemos estar desabilitando alguna feature importante y podemos tener problemas. hay que mirar las documentaciones de los procesadores y perdonad si soy pesado, nunca en producción.

Hasta la semana que viene.

Cuidaros.

Error al crear Datastores locales

Hoy vamos a ver como solventar algún problema que nos puede aparecer al crear datastores locales en nuestro vSphere.

Tenemos nuestro ESX y además del disco en que bota nuestro vSphere tenemos otros discos donde queremos crear datastores locales. Cogemos nuestro vCenter, “Add storage”, “Disk”, vemos y seleccionamos el recurso, y cuando vamos a añadirlo y formatearlo nos da error. Por mucho que probamos, no podemos añadirlo.

Esto ocurre cuando queremos crear un volumen VMFS y partición que está en la misma controladora que el storage local, este volumen está continuamente bloqueado por la Service Console. Lo mismo nos puede ocurrir quitando un recurso local en las mismas circunstancias.

Si usas la línea de comandos, este estado no esta tomado en cuenta, por lo que podrás añadir o quitar estos recursos. En nuestra Service Console, identificaremos el disk que deseamos añadir http://kb.vmware.com/kb/1014953

Ejecutaremos el comando fdisk –u , donde el identificador lo substituiremos por el identificador que hemos obtenido en el paso anterior.
n para nueva partición
p para primaria
1
Indicaremos el primer cilindro (o default)
Ultimo cilindro (o default)
t para cambiar el tipo de volumen
1 para seleccionar la primera partición
fb (valor hexadecimal para vmfs)
x para expert mode
b para inicio proceso de cambio de block de inicio
1 de primera partición
128 para establecer el starting block
w para guardar la información

Guardamos y rebotamos el ESX para que tome en consideración los cambios.

Ejecutamos vmkfstools:

   

Cuidado. Si la nueva partición está en el mismo disco que la service console, el I/O funcionando y con una controladora PERC, vmkfstools puede no funcionar correctamente, habrá que hacer otro procedimiento.