{"id":280,"date":"2019-04-09T19:21:16","date_gmt":"2019-04-09T19:21:16","guid":{"rendered":"http:\/\/94r.es\/?p=280"},"modified":"2022-06-20T21:49:18","modified_gmt":"2022-06-20T19:49:18","slug":"error-en-vdisk-tras-eliminar-snapshot","status":"publish","type":"post","link":"https:\/\/94r.es\/index.php\/2019\/04\/09\/error-en-vdisk-tras-eliminar-snapshot\/","title":{"rendered":"Error en vDisk tras eliminar snapshot"},"content":{"rendered":"<p style=\"text-align: justify;\">Hace un par de d\u00edas tuve un problema al tratar de borrar un snapshot de una m\u00e1quina virtual OpenMediaVault. Como me llev\u00f3 bastante tiempo localizar el problema (novato que es uno) y la soluci\u00f3n t\u00e9cnica es bastante sencilla la detallo por aqu\u00ed confiando en que a alguien le sea de utilidad en el futuro.<\/p>\n<p style=\"text-align: justify;\">Como dec\u00eda, el problema surgi\u00f3 al borrar el snapshot. Durante el proceso, por alg\u00fan motivo, la m\u00e1quina se queda en estado congelado. Al finalizar, trato de acceder a ella para poder apagar el sistema operativo sin recurrir al botonazo pero se encuentra inaccesible incluso desde la consola remota de vSphere. Tras apagarla de forma abrupta me encuentro con que no es posible iniciarla de nuevo de ninguna manera, de modo que trato de subsanar el problema consolidando los discos, sin \u00e9xito.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-284 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/2-error-consolidacion-discos.png\" alt=\"\" width=\"1917\" height=\"539\"><\/p>\n<p style=\"text-align: justify;\">Yendo a los detalles en el registro de eventos se indica que no se pudo encender por una sucesi\u00f3n de errores a partir de la inaccesibilidad al vmdk (disco de la vm) que soporta la m\u00e1quina OpenMediaVault. Aunque a la postre haber actuado leyendo este esbozo del log habr\u00eda sido suficiente para resolver el problema, opt\u00e9 por descargar el log de sucesos de la m\u00e1quina virtual para ver un registro m\u00e1s detallado de lo ocurrido en los momentos previos al intento de arranque.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"alignnone size-full wp-image-283\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/1-error.png\" alt=\"\" width=\"1652\" height=\"524\"><\/p>\n<p style=\"text-align: justify;\">El archivo de log de la m\u00e1quina se puede descargar usando el explorador de archivos de vSphere, navegando desde el datastore hasta el directorio de la m\u00e1quina. El archivo m\u00e1s reciente siempre es el vmware.log, ya que la rotaci\u00f3n de logs funciona de tal manera que cuando el archivo se completa se guarda como vmware-1.log y todos los que haya a mayores (desde el anterior vmware-1.log a los siguientes) suman un n\u00famero.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-285 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/3-obtencion-log.png\" alt=\"\" width=\"932\" height=\"500\"><\/p>\n<p style=\"text-align: justify;\">El log de la m\u00e1quina viene a confirmar lo que trasladaba el error de la segunda captura: que el origen del fallo al encender radica en que el sistema no puede encontrar el path del vmdk que contiene el sistema operativo.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-286 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/4-log.png\" alt=\"\" width=\"1842\" height=\"902\"><\/p>\n<p style=\"text-align: justify;\">Volviendo a vSphere, comprobamos en la m\u00e1quina que los paths de los dos discos apuntan a un vmdk que no es el del disco duro base sino el delta, que no se muestra en el explorador de archivos debido a que se elimin\u00f3 con el snap.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-287 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/5-incongruencia-vmdk.png\" alt=\"\" width=\"952\" height=\"766\"><\/p>\n<p style=\"text-align: justify;\">De manera que, identificado el problema, la operativa para resolverlo es muy sencilla: desatachamos los discos de la m\u00e1quina y volvemos a montarlos apuntando al path correcto. Aunque parece evidente, es importante no clicar en el checkbox \u00abEliminar archivos del almac\u00e9n de datos\u00bb, ya que lo que har\u00eda ser\u00eda borrar el disco del datastore, del mismo modo que si formate\u00e1semos un disco f\u00edsico. Esto s\u00f3lo lo har\u00edamos en caso de que quisi\u00e9ramos borrar la m\u00e1quina virtual y recuperar el espacio de los vdisks que contiene.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-289 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/7-desatachar-discos.png\" alt=\"\" width=\"957\" height=\"773\"><\/p>\n<p style=\"text-align: justify;\">De modo que volvemos a agregar los discos, eligiendo obviamente un disco existente, y nos aseguramos de seleccionar el archivo vmdk correcto dentro del datastore y m\u00e1quina adecuados.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-282 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/8-agregar-disco-duro-existente-y-navegamos-hasta-el-vmdk.png\" alt=\"\" width=\"253\" height=\"175\"><\/p>\n<p style=\"text-align: justify;\">En mi caso, para el disco principal debo ir al disco SSD que contiene el vmdk del sistema operativo y para el secundario, de datos, al disco NAS.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-288 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/6-incongruencia-vmdk.png\" alt=\"\" width=\"935\" height=\"495\"><\/p>\n<p style=\"text-align: justify;\">Hecho esto, comprobamos que tanto el inicio de la m\u00e1quina como la consolidaci\u00f3n de discos se realizan correctamente, con lo que queda solucionado un problema que (localizado) no lleva m\u00e1s de cinco minutos resolver.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-281 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/9-ahora-bien.png\" alt=\"\" width=\"1919\" height=\"965\"><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify;\"><strong>Bonus track: lo que sucedi\u00f3 con el sistema de archivos te sorprender\u00e1<\/strong><\/p>\n<p style=\"text-align: justify;\">En este caso en particular, adem\u00e1s, cuando encend\u00ed cu\u00e1l fue mi disgusto al comprobar que el sistema de archivos se hab\u00eda da\u00f1ado durante el proceso de borrado del snap que provoc\u00f3 la incongruencia en los paths.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-297 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/8978979.png\" alt=\"\" width=\"804\" height=\"626\"><\/p>\n<p style=\"text-align: justify;\">Por suerte, bast\u00f3 con una simple ejecuci\u00f3n de la herramienta <em>fsck<\/em>, que comprueba y repara los bloques de ficheros da\u00f1ados. Ejecutada sin especificar discos examinar\u00e1 todos los que integren el sistema y est\u00e9n desmontados. Podemos desmontar un disco usando <em>umount<\/em> seguido bien del disco, bien del punto de montaje.<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-295 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/uuuh.png\" alt=\"\" width=\"656\" height=\"213\"><\/p>\n<p style=\"text-align: justify;\">Al ejecutarse con los argumentos<em> -f<\/em> y <em>-y<\/em> fuerza el chequeo de todo el sistema de ficheros y responde afirmativamente a las peticiones de arreglo de manera autom\u00e1tica, ya que de otro modo nos pasar\u00edamos un buen rato interaccionando con la m\u00e1quina innecesariamente (dado que no s\u00e9 d\u00f3nde se localiza el problema quiero que examine el sistema \u00edntegramente).<\/p>\n<p style=\"text-align: justify;\"><img loading=\"lazy\" class=\"size-full wp-image-296 aligncenter\" src=\"https:\/\/94r.es\/wp-content\/uploads\/2019\/04\/uuuuh-3.png\" alt=\"\" width=\"748\" height=\"512\"><\/p>\n<p style=\"text-align: justify;\">Una vez reparado el sistema de ficheros ya se puede acceder a \u00e9l con normalidad. Conviene recordar que <em>fsck<\/em> no debe ser la primera opci\u00f3n a la hora de reparar un fs (y menos ejecutado de esa manera), ya que podr\u00eda dar como resultado la p\u00e9rdida de datos v\u00e1lidos.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hace un par de d\u00edas tuve un problema al tratar de borrar [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[9],"tags":[],"_links":{"self":[{"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/posts\/280"}],"collection":[{"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/comments?post=280"}],"version-history":[{"count":13,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/posts\/280\/revisions"}],"predecessor-version":[{"id":400,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/posts\/280\/revisions\/400"}],"wp:attachment":[{"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/media?parent=280"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/categories?post=280"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/94r.es\/index.php\/wp-json\/wp\/v2\/tags?post=280"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}