VMWare: Unable to power on Virtual Machine

Buf…. maldito mensaje… y además ¡genérico! Bueno, en mi caso esta noche no podía arrancar una máquina virtual porqué me daba un error de un datastore que no estaba activo (lo peté del Datacore) pero aun estaba asociado a una máquina virtual.

El error que me daba era: Virtual disk ‘Hard disk 3’ is not accessible on the host: Unable to access file [VMFS Store Name] VM Name/VM Name.vmdk

Antes que nada, ¡calma! La solución es fácil y divertida de hacer vamos a ello:

1) Primero lo que debemos hacer es (en caso de no tenerlo activado) arrancar el servicio SSH en el host donde tengamos la máquina virtual hospedada.

2) Editamos la máquina virtual y buscamos el disco vmdk que nos está dando problemas (y que muy probablemente no nos dejara remover así como así…) y vemos que en las propiedades el Virtual Device Node. Tomamos nota de él, en nuestro ejemplo SCSI (0:0) Hard disk 1

2) Nos conectamos mediante Putty al host y navegamos al siguiente directorio:

cd /vmfs/volumes/[Datastore donde está alojada la MV que no arranca]/[Nombre de la VM]

3) Una vez dentro, editamos el fichero vmx con el vi:

vi [Nombre de la VM].vmx

4) Vamos al final del fichero y buscamos las líneas que empiezan por el Virtual Device Node que nos hemos apuntado antes (en el ejemplo scsi 0:0) y las eliminamos. ¡Ojo! Solamente las que empiezan por scsi 0:0 o el valor que tengamos (suelen ser unas 4 o 5 líneas).

Nota: Para los que nos estáis familiarizados con el Putty, para editar el fichero pulsamos la tecla INSERT, eliminamos con SUPRIMIR y para guardar/salir pulsamos ESC y escribimos :wq!

5) Bien, cerramos el Putty y nos dirigimos a nuestro vCenter. Hacemos clic con el botón derecho sobre la máquina virtual que no arranca y le damos a Remove from Inventory. Esto lo hacemos ya que como hemos editado el fichero vmx, el host debe volver a leerlo.

6) Vamos al datastore donde tengamos la máquina virtual que no arrancaba, buscamos el fichero vmx y con el botón derecho seleccionamos Add to Inventory.

¡Y listo! Nuestra máquina virtual ya arranca pero esta vez sin el disco vmdk que nos daba problemas.

Error en xenserver SR_Backend_Failure_47

El otro día un cliente me llamó diciéndome que su sistema iba extremadamente lento. En un principio me acojoné un poco porqué este cliente funciona con Datacore SANsymphony en su versión 9.0 PSP4 (algún día hablaré del Virtual Storage) y con un sistema horrendo llamado Citrix XenServer.

Vale…supongo que ya habré herido algún sentimiento, pero pienso lo escribo: en mi particular ranking, este sistema ocupa el último puesto en cuanto a virtualización. No me gusta nada. Pero como tengo clientes que lo usan, debo saber aprender a manejarlo.

Siguiendo con lo que decía, mi cliente me llamó informándome que todo iba muy lento y cuando me conecté a la consola XenCenter, me fijé que todos los discos virtuales (a.k.a SR), habían perdido un path iSCSI hacia la V-SAN. (NOTA: los errores de multipathing son parecidos a la imagen siguiente, ya que podemos ver los dos servidores y en uno de ellos nos marca Connected y en el otro Unplugged)

¿Y ahora como los conecto? Bueno … pues tirando de manuales:

• Hacemos clic sobre el servidor xenserver que ha perdido la conexión (NOTA: En un entorno multipathing, los servidores tienen varios caminos o path para acceder a los discos duros de la cabina) y pulsamos la pestaña “Console”

• Veréis que es una consola Linux
• En ella sacaremos primero de todo el error que nos da. Para ello, primero de todo buscamos el uuid (Universal Unique IDentifier) de nuestro SR asociado al host que ha perdido el path

[root@nuestroservidorxen]# xe sr-list

• Cogemos el uuid del PBD (Physical Block Disk) asociado al SR anterior

[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>

• Buscamos el parámetro que nos da el problema:

[root@nuestroservidorxen]# xe pbd-param-get param-name=other-config uuid=<em>[Valor que nos a dado el comando anterior]</em>

Bien, pues nos econtramos con un SR_Backend_Failure_47, que nos viene a decir que el servidor xenserver no se puede conectar con el recurso iSCSI. Dicho esto, debemos comprobar si realmente no existe comunicación entre el host i el recurso. Para ello haremos un ping a la interface de red del recuso iSCSI. Si NO responde, deberemos hallar el problema que muy probablemente será físico, pero si el ping responde, lo más seguro es que el problema sea lógico.

En nuestro error, el problema es lógico, ya que los ping responden sin problemas. Así mismo, para terminar de verificar el problema, podemos probar los siguientes comandos:

[root@nuestroservidorxen]# iscsiadm –m node

Con este comando veremos todos los IQNs disponibles y activos

[root@nuestroservidorxen]# iscsiadm –m session

Con este comando veremos todas la conexiones activas. Si no hay ningún error en ningún comando, entonces es que nuestro xenserver no se puede conectar al SR iSCSI (problema lógico). Pues ale, vamos a probar de conectarlos de nuevo…y lo haremos de dos formas. Pero ¡ojo! la/s máquina/s virtual/es asociada/s a este SR, deben estar apagadas.

Por consola:

root@nuestroservidorxen]# xe sr-list

[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>

[root@nuestroservidorxen]# xe pbd-plug uuid=<em>[Valor que nos a dado el comando anterior]</em>

Por el XenCenter

1. Apagamos la/s máquina/s virtual/es asociada/s al SR que ha perdido la conexión
2. Hacemos clic con el botón derecho sobre el SR que ha perdido la conexión y seleccionamos Detach con lo que desconectaremos el SR de todos los xenserver
3. Hacemos clic con el botón derecho sobre el SR que hemos desconectado y seleccionamos Attach, con lo que podremos generar una conexión nueva

Si todo a ido bien, nuestro SR volverá a estar operativo con los dos (o los que sean) path iSCSI activos de nuevo.

Error en la instalación de vSphere 6.0

Ya sé que hace mucho tiempo que no escribo nada interesante y me han llegado algún que otro mail, quejándose un poco de por qué tengo el Blog desactualizado. La verdad es que no dispongo de mucho tiempo y, cuando encuentro/soluciono alguna incidencia que quiero compartir con vosotros, pues me resulta imposible poderlo hacer. Así que, espere que (por enésima vez) pueda como mínimo escribir con cierta regularidad al respecto.

Dicho esto, os comento un reciente error (de hace algunos meses) que me daba la instalación del vSphere 6.0 como appliance. Los únicos vSphere que había instalado (en su versión 6.0) y por necesidades del guion, fueron sobre Windows Server 2012 R2 y la primera vez que lo instalé como appliance no paraba de darme errores en la instalación: Firstboot script execution error.

Pues bien, la solución la hallé aquí i la comparé en este blog, y la verdad la solución me dejó perplejo: solamente hay que añadir 1 solo registro DNS durante el proceso de instalación (a ser posible el del dominio) y si así persiste el error, añadir un registro DNS al controlador de dominio antes de la instalación (a mi me funcionó el primer paso).

Como comenta alguien en los foros de VMware…

Error C:\Windows\System32\<LANG_NAME>\mstsc.exe.MUI

Pues eso, como solucionar este maldito error que me trajo de cabeza durante un día entero? Pues instalando una (o las dos) actualizaciones siguientes:

KB2574819

KB2592687

Simple y llanamente…

Como reparar el error: “Servicio de perfil de usuario al iniciar sesion» en Windows 7

Este es un error (por desgracia) bastante frecuente en sistemas Windows Vista y Windows 7. Aunque nos parezca un «problemón» en verdad no lo es y su solución es muy simple.

NOTA: lo publico aquí porqué recientemente he visto que estos últimos días se han incrementado (sin comprender porqué) y, si puedo ser de ayuda, mejor 🙂

¡Al trapo!

• Reiniciamos el PC/portátil en modo a prueba de fallos (Modo Seguro)
• Ejecutamos la herramienta de registro de sistema REGEDIT pulsando la tecla Windows+R y escribiendo «REGEDIT»
• Navegamos hacia HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList
• Dentro veremos unos registros con un nombre del estilo S-1-5-20-93829738927189372891 y deberíamos ver uno de estos registros con una extensión .bak al final. Si hay varios de ellos, deberemos fijarnos que la numeración coincida (tomad como referencia la extensión .bak)
• Pulsamos sobre el registro que no termina con .bak y, en el panel de la derecha si detectamos que en una de las keys pone C:\Users\Temp entonces debemos cambiar el registro.
• Verificamos que en la que sí que termina en .bak una de las keys contiene el parámetro C:\Users\[nombre de usuarios] Si existe, este es el registro bueno.
• Pulsamos F2 sobre el registro SIN extensión .bak y lo renombramos como .bak2
• Pulsamos F2 sobre el registro CON extensión .bak y eliminamos la extensión
• Pulsamos F2 sobre el registro CON extensión .bak2 y le borramos el 2
• Cerramos el editor
• Reiniciamos

Hecho esto, nuestro sistema iniciará sin problemas. Si por lo que sea, haciendo esto no nos arranca con normalidad, el problema será otro y deberemos averiguar de dónde viene la incidencia.

Error en imprimir con Chrome: se quedan los documentos en la cola de impresión

Desde el pasado 27 de Agosto, se ha detectado que la última actualización de Google Chrome está dando problemas cuando queremos imprimir a través del navegador, quedándose los documentos en la cola de impresión. Esto sucede tanto si queremos imprimir a través del menú de Chrome o a través de código. De momento no hay una solución oficial y lo único que podemos hacer es cambiar la ruta del directorio temporal pues al parecer, la sandbox falla al no detectar la ruta correcta.

Esto se puede solucionar con un fichero batch:

echo off
md c:\gtemp\%username%\Temp
setx TEMP c:\gtemp\%username%\Temp
setx TMP c:\gtemp\%username%\Temp

En mi caso, al sucederme esto en un entorno Windows 2012R2, he creado un fichero *.bat y lo he forzado a que se ejecute al inicio de sesión de cada usuario, mediante el Logon script de las GPO. De esta forma el cambio se ejecuta en todos los UPD.

De momento no hay parche a la vista. En cuanto salga, actualizaré el post.

Fuente | Code Google

Deshabilitar servicios o programas mediante la consola de recuperación de Windows

¿Qué ocurre cuando un servicio se bloquea y nos impide arrancar Windows? Es decir, cuando no sale una pantalla azul (o BSOD), siempre que el error mostrado sea de un controlador/servicio/programa. Os recomiendo este post y este otro post para poder identificar las distintas causas de los pantallazos así como su codificación.

Pues la solución es bastante sencilla: usando la consola de recuperación. Para ello lo que deberemos hacer es lo siguiente:

• Arrancamos nuestro Pc con el CD de instalación de Windows XP.
• Una vez se hayan cargado los controladores, pulsaremos la ‘R‘ y accederemos a la consola de recuperación.

Más adelante explicaré algunos de los comandos más usados (o los que más uso) para reparar el sistema operativo. Ahora, de momento, deberemos aprender el comando listsvc. Este comando nos listará todos los servicios en el inicio de Windows.El otro comando que debéis tener en cuenta es disable y  con el parámetro /? podréis ver sus opciones (aunque no tiene ningún secreto).

 

Fijaros que el comando disable nos presenta los distintos estados de los servicios, es decir, los start_type que son:

• SERVICE_DISABLED: nos dice que el dispositivo está deshabilitado.
• SERVICE_BOOT_START: nos indica que el controlador de dispositivo es iniciado por el propio sistema operativo.
• SERVICE_SYSTEM_START: este es un poco extraño. Nos indica que un controlador de dispositivo es iniciado por la función IoInitSystem (lo busqué en el KB de Microsoft porqué no sabía lo que era).
• SERVICE_AUTO_STAR: nos indica que un un controlador de dispositivo o servicio de Windows es iniciado por el administrador de servicios de manera automática.
• SERVICE_DEMAND_START: nos especifica que un controlador de dispositivo o servicio de Windows, es iniciado por el administrador de servicios.

Esto quiere decir que si ponemos:

C:\disable [nombre_del_servicio]

A la que hagamos un listsvc, nos mostrará el estado del servicio. Dicho esto y sabiendo cual es el servicio/controlador que nos está causando problemas, lo podremos deshabilitar y arrancar nuestro sistema operativo. Si, aun deshabilitándolo todo, nos sigue saliendo la pantalla azul, el problema ya es otro 😉

Tip: Solucionar problema de Outlook que se reinicia constantemente

A veces sucede que MS Outlook no quiere iniciarse ni en modo normal ni en modo a prueba de fallos dándonos un error como el que muestro al principio del post, y entrando en lo que parece un bucle infito. Para solucionar este error debemos antes de nada probar lo siguiente abriendo el menu «Ejecutar» de Windows:

• Inicio -> Ejecutar -> outlook.exe /safe nos inciará Outlook sin extensiones, sin Panel de lectura y sin personalizaciones de barra de herramientas.
• Inicio -> Ejecutar -> outlook.exe /safe: 1 nos iniciará Outlook con el Panel de lectura desactivado
• Inicio -> Ejecutar -> outlook.exe /safe: 2 Iniciará Outlook sin hacer comprobaciones de correo, es decir, sin hacer el «Enviar y Recibir» de inicio
• Inicio -> Ejecutar -> outlook.exe /safe: 3 Iniciará Outlook con las extensiones desactivadas
• Inicio -> Ejecutar -> outlook.exe /safe: 4 Iniciará Outlook sin cargar los archivos outcmd.dat (barras de herramientas personalizadas) y *.fav.

Este problema aun no he podido detectar al 100% porqué ocurre pero suele venir después de un culegue (y posterior reinicio) de la suite Office y del Sistema Operativo. En el caso de que no nos arranque Outlook con ninguno de estos comandos, lo que haremos será lo siguiente:

• Mediante el explorador de ficheros, si tenemos Windows XP iremos al menú Herramientas -> Opciones de carpeta y en la pestaña Ver activaremos la opción Mostrar todos los archivos y carpetas ocultos
• Navegaremos al directorio C:\Documents & Settings\[nombre_de_usuario]\Application Data\Microsoft\Outlook
• Dentro encontraremos unos ficheros con extensiones *.srs, *.nks y *xml. Cortamos estos ficheros y los copiamos en una carpeta fuera de este directorio (por ejemplo en el Escritorio).
• Iniciamos Outlook y, en teoria nos tendría que funcionar sin ningún problema

Lo que si que he visto es que cuando sucede este error es porqué hay alguno de estos 3 ficheros que no se crea correctamente y da un conflicto. Entonces, vaciando el directorio de estos ficheros, Outlook no los detecta y los genera de nuevo, creando así unos ficheros que no estan corrompidos ni dañados ni generan conflicto alguno.

Aun aplicando esta solución ¿os ha dado algún problema el Outlook? ¿Habéis podido solucionarlo correctamente?

Solucionar «Error en el servicio de perfil de usuario al iniciar sesión» en Windows Vista

Normalmente, casi todos los errores que salen en Windows Vista se pueden solucionar mediante:

• un chkdsk /f/r (completo) puesto que el sistema, como si de una forma de masoquismo se tratara, se autolesiona él mismo.
• un format c: /q (como los de antaño)

Seguro que hay más formas de solucionar los problemas pero en Windows si no es una de las anteriores se pierde el tiempo. Esta claro que estoy exagerando un poco, aunque creo que no estoy tan equivocado. En fin … A lo que vamos.

Puede ser que en Windows Vista, al iniciar el pc/portátil, no nos acceda al Escritorio (o cargue nuestro perfil de usuario) y no salga un mensaje que nos diga «Error en el servicio de perfil de usuario al iniciar sesión«. Según el Knowledgment Base de Microsoft, nos dice que se su causa es:

Este problema puede producirse si el perfil de usuario se elimina manualmente (¿?) mediante el uso de la línea de comandos o mediante el Explorador de Windows. Un perfil que se elimine manualmente no quita el identificador de seguridad (SID) de la lista de perfiles en el registro.

Si el SID (Security IDentifier) está presente, intentará cargar el perfil utilizando elProfileImagePathque señala a una ruta de acceso que no existe. Por lo tanto, no se puede cargar el perfil.

Es decir, por arte de magia nos hemos eliminado a nosotros mismos de los perfiles de usuario. ¿a qué mola? (¿entendéis lo que decía antes del masoquismo en Windows Vista?). La solución que dan es, como suele pasar en Windows, eliminar una clave del registro y reiniciar. Puede que así o nos cargamos aun más el sistema o por el contrario, se recupere el perfil de usuario de las backups. Pero existe otra solución, rápida, sencilla y sin (casi) ningún riesgo (en Windows no existe el factor «sin riesgo») y como no, deberemos tocar (un poquito) el registro de Windows. Los procesos a seguir son los siguientes:

• Reiniciamos y pulsamos F8 para cargar el menu de arranque de Windows
• Arrancamos en Modo Seguro
• Accederemos a Windows en modo Administrador
• Haremos Inicio -> Ejecutar
• Escribiremos regedit y le daremos al Ejecutar

Aquí dentro vigilad lo que tocáis puesto que nos podemos cargar el sistema operativo enterito. Deberemos buscar la siguiente clave en el registro, expandiendo las diferentes ramas del mismo:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Expandimos un poco la ventana de la derecha y veremos dos perfiles de usuario con el mismo nombre (p.ej. 000000-111111-222-333-4444) y uno de ellos terminará en .bak. Lo que se trata es de invertir la clave, es decir, cambiar la extensión .bak de una por la otra. Os pongo un ejemplo:

Siguiendo las imágenes siguientes, vemos las dos claves de registro

Modificamos (pulsando F2) el nombre de una y cambiamos .bak por .bak2. Vamos a la que no tiene extensión y le ponemos una extensión .bak

Eliminamos la extensión .bak2 dejando la clave sin extensión

Una vez hecho esto, cerramos el regedit, reiniciamos y ya no nos saldrá más el error y podremos acceder sin ningún problema a nuestra sesión de Windows Vista. Cierto es que este error me salió hace ya tiempo y lo solucioné haciendo un chkdsk del disco duro. Otros compañeros me han comentado que a base de reiniciar varias veces, se ha solucionado el problema (¿?). Si os dejáis aconsejar, en cuanto podáis quitaros el Vista y instalaros Windows 7 o Ubuntu.

No le tengo manía a Windows ni mucho menos. De hecho, uso tanto Ubuntu como Windows 7 y por motivos de faena, casi siempre tengo que lidiar con Windows XP o Windows Vista y la verdad, éste último no me gusta en absoluto.

Espero que os haya servido. Un saludo.

¡Achtung! Correo con Malware

Leo en GeeksRoom que esta corriendo un mail prometiendo películas porno gratis que esta infectando muchos ordenadores bajo sistema operativo Windows.

Una vez infectado el PC, el virus ataca a la libreta de direcciones de Outlook y empieza a enviar una réplica del correo a todos los contactos del usuario infectado. Además, anula por completo el software antivirus que tengamos instalado, con lo cual puede operar con total libertad.

Si llegáis a infectaros y corréis bajo Windows XP, os recomiendo este fabuloso How To sacado de YTuQueLeeS para limpiar vuestro Pc.

¡Andaros con cuidado!