Archive for the 'Virtualización' Category

Recuperar password en VMWare vCenter Server Appliance 6.5

Esta mañana he estado leyendo un interesantísimo artículo de Alex Samoylenko, CEO de Nova Games y escritor en el blog de StarWind, que creo que os puede ser de mucha mucha utilidad:

Recuperar el password en un vCenter Server Appliance

Si ya lo habéis instalado, veréis que este nuevo vCenter está basado en Photon (https://vmware.github.io/photon/) y para poder recuperar el password, nos explica:

¡Antes de nada hacer un Snapshot!

– Una vez que cargue el sistema operativo, pulsamos <e> para acceder al menú de edición de GRUB.

– Buscamos la sección done se inicia Linux (empieza con “linux”) i añadimos al final lo siguiente: rw init=/bin/bash

reset root password on vCenter Server Appliance

– Pulsamos F10 para continuar con la descarga

– Escribimos passwd en la línea de comandos y escribimos el password de root

– Desmontamos el sistema de ficheros con unmount /

– Reiniciamos el vCenter Server Appliance 6.5 con el comando reboot –f

– Hecho esto, el password del vCenter se reiniciarà. Una vez lo comprobéis que funciona todo, ¡recordad de eliminar el sanpshot!

Fuente | 3 useful tricks with VMware vCenter Server Appliance

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 Smile 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

image

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”

image

  • 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.

Powershell: creación y eliminación de snapshots Hyper-V

índice

En un entorno virtual, es una muy buena práctica tener controlados los snapshots de nuestras máquinas virtuales. A diferencia de VMWare, en Hyper-V són puntos de control que se crean muy rápidamente y se consolidan de la misma forma. Es per ello que es una muy buena opción a contemplar como complemento de los backups.

En un caso concreto yo lo uso como estrategia de prevención contra Cryptolockers y ransomware varios haciendo que cada día, antes de que las empresas entren a trabajar se cree un punto de control. Para ello uso una tasca programada con el siguiente script:

Get-VM  * | checkpoint-vm -SnapshotName "[Nombre que le queramos dar] $((Get-Date).toshortdatestring())" –AsJob

Con este script en powershell, cada día se nos ejecutará un punto de control de TODAS nuestras máquinas virtuales. Podemos acotar la búsqueda o filtrar con el comando:

Get-VM –Name [Nombre de la M]

y que podremos filtrar. Por ejemplo: si todas nuestras máquinas virtuales se llaman SRV-[nombre] pero algunas son OLDSRV y solo queremos snapshots de las primeras, podemos hacer:

Get-VM SRV-*

Hecho esto, el siguiente paso es controlar cuantos snapshots queremos guardar. En mi caso solamente guardo un día puesto que como he dicho antes, es una medida de control contra los ransomware, no una backup. Para ello, uso el script siguiente:

Get-VMSnapshot –VMName [nombre_MV]* | Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-1) } | Remove-VMSnapshot

Donde:

  • (Get-Date).AddDays(-1) son los días que quiero almacenar. En mi caso 1. Este valor lo podéis cambiar por el que queráis.
  • [nombre_MV]* es una string del nombre, como si fuera un sufijo. Es para filtrar.

De esta forma, puedo controlar que si nos entra algo que nos engorrine el sistema y es crítico, podemos en tan solo dos clics de ratón, volver al inicio del día. Eso si, para clientes o sistemas más críticos, uso el script varias veces al día y los elimino todos al día siguiente. La secuencia de comandos de la tasca programada es la siguiente:

powershell.exe –ExecutionPolicy Bypass –file “[ruta_del_script]”

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…

vmware_please


Categorias

Enter your email address to follow this blog and receive notifications of new posts by email.

Únete a otros 386 seguidores

RSS Acceso Directo

  • Regresa La Familia Monster en nueva serie de TV 08/18/2017
    La cadena de televisión CBS, creadora de la original serie cómica The Munster (mejor conocida en habla hispana como La Familia Monster), cedió los derechos de dicha serie a la cadena de televisión NBC para su regreso a las pantallas chicas. La Familia Monster fue trasmitida de 1964 a 1966 …

RSS Microsiervos

RSS Bitelia

  • Cómo usar y aprovechar los escritorios virtuales de Windows 10 08/18/2017
    Más espacio para jugar, divertirte o trabajar en la misma pantalla. Cuando Windows implementó la multitarea, nadie pensó en que eso haría que tuviéramos varias ventanas abiertas, ocupando toda la pantalla aunque sin poder verlas todas. En las sucesivas actualizaciones, Windows ha intentado solucionar este problema. En Windows Vista y 7 pudimos mostrar las ve […]