Muy buenas,
Solo por un día, me olvido de NetApp y vamos con una cosa curiosa de VMware.
Esto que vamos a ver suele pasar cuando se pasa de 32 niveles de snapshots, aunque cómo vamos a ver hoy, también puede pasar si un mv va acumulando snapshots “ocultos”
Nos solemos dar cuenta del error cuando vemos algo similar a este error:
Create virtual machine snapshot
An error occurred while saving the snapshot: msg.disklib.TOOMANYREDO.
En este caso es creando un snapshot, pero nos dará errores similares cuando intentemos migrar, clonar, compactar o arrancar la mv
Si editamos las propiedades de la mv, veremos que el vmdk tiene el disco con un nº muy elevado. No me he parado a contar todas, pero casi seguro que esta mv tiene 254 snapshots ocultos
Desde el vsphere client no nos va a dejar hacer mucho, asi que tendremos que habilitar el ssh el en host y conectarnos
Navegando hasta la carpeta en la que esta la mv, vemos que esto no pinta bien…
En este punto, os recomiendo que os hagáis una copia de la mv, porque vamos a compactar todos estos archivos, y siempre puede ir algo mal. Para ello, desde el Datastore browser de vsphere client, seleccionáis la carpeta y la copiáis a otro Datastore.
Y ahora biene el proceso tedioso de compactar.
Si intentamos hacerlo de una sola vez, nos da un error que dice que hemos pasado el límite de ficheros abiertos
**Inicio del proceso**
Así que nos toca jod…nos y hacerlo a mano. Yo he ido seleccionando de 30 en 30, y lo que hacemos es que con vmkfstools vamos compactando el vmdk en varios pasos, con el comando de la foto.
Como vemos, esto nos genera un nuevo vmdk
Ahora nos tenemos que asegurar de que la cadena de snapshots de los restantes disco está correcta, así que tenemos que ver el CID del vmdk que acabamos de crear
Anotamos el CID y tenemos que editar el vmdk siguiente al que hemos puesto en el comando vmkfstools. En este caso, pusimos el mfc-000030.vmdk, por lo que tenemos que editar el mfc-000031.vmdk
Lo editamos con vi
Vi mfc-000031.vmdk
Si os fijáis en la foto de arriba (previa a modificación) hay 2 campos que tenemos que chequear, 1 parentCID y 2 parentFileNameHint
El parentCID está bien por lo que no lo editamos, pero el parentFileNameHint sí que lo tenemos que modificar
Lo cambiamos y guardamos
**Fin de proceso**
Ahora tememos que repetir este proceso tantas veces como sea necesario para llegar a un vmdk totalmente compactado, todos los pasos desde la marca **inicio proceso** hasta **Fin de proceso**
En nuestro caso fueron 9 pasos, y al vmdk del último paso le llamamos mcf_final.vmdk
Si la mv tiene varios discos con el mismo problema, hay que hacerlo con cada disco
Una vez tenemos el vmdk compactado hay que renombrar el fichero .vmsd, para que la mv no tenga snapshots
Ahora tenemos que editar el .vmx de la mv
Lo hacemos con vi, con el comando vi nombre_mv.vmx
Nos movemos hasta donde están los discos configurados
Y modificamos esas líneas con los discos que hemos compactado
Guardamos los cambios y desinventariamos la mv del vcenter
Ahora tenemos que volver a inventariar la mv. Como la carpeta sigue teniendo un monton de vmdk, si lo hacéis desde el Datastore browser se va a pegar un buen rato hasta que os muestre el contenido, por lo que os recomiendo que lo hagáis por comando
Vim-cmd solo/registervm /vmfs/volumes/nombre_datastore/nombre_mv/nombre_mv.vmx
Con esto volvemos a tener la mv en el inventario. Si la editamos, vemos que los discos ya están bien
Al arrancar, es posible que nos pregunte si hemos movido o copiado la mv
Ya vamos terminando. Aunque la mv ya esta otra vez funcional, la carpeta en la que esta sigue teniendo mucha basura, por lo que os recomiento hacer un storage vmotion
De ese modo, conseguimos que los discos de la mv tengan el mismo nombre de la máquina (y así evitar líos), y los archivos útiles se muevan al nuevo Datastore.
Tras esto podemos borrar la carpeta antigua
Y esto es todo, ya sé que no es un método muy elegante, pero funciona y nos puede sacar de algún apuro
Ale, hasta otra