La belleza y el horror de los errores de VDDK es que, por un lado, está absolutamente claro dónde se rompió y, por otro lado, es completamente incomprensible por qué y cómo solucionarlo ahora. Es como si la función de llamada RPC fallara en el mundo de Windows.
Aunque no todo es tan terrible, claro. Algunos errores tienen causas y tratamientos muy específicos. Y algunos: una lista largamente conocida de las causas y opciones más comunes para corregirlas.
Nuestro Soporte Técnico de Veeam, por supuesto, acumula ese conocimiento, y hoy echaremos un vistazo a sus entradas. Por lo tanto, es un gran placer presentarles los errores de VDDK más comunes y los métodos para eliminarlos.
Errores de VDDK. ¿Qué es y cómo se obtienen?
Como puede adivinar por el nombre, estos son algunos tipos de problemas a nivel de VDDK Api (Virtual Disk Development Kit), la mejor manera de interactuar con la infraestructura de vSphere. No importa si es un host ESXi separado o un vCenter extenso, pero si necesitamos escribir o leer algo de nuestra infraestructura, la mejor manera de hacerlo es el VDDK gratuito.
Para simplificar tanto como sea posible, esta interacción se parece a esto: el servidor de Veeam quiere, por ejemplo, leer algo del host (o escribir) y le envía una solicitud. Se crea una llamada de lectura que indica desde qué disco, cuánto desea leer, desde qué desplazamiento y hasta qué búfer en la memoria. O escriba, de manera similar, desde el búfer especificado. Es simple.
Pero este es un mundo perfecto.
En la vida real, a veces se producen errores en el camino de este simple algoritmo, por lo que es imposible completar la solicitud. Y en lugar de la respuesta esperada, nos llega un número de error, que se registra cuidadosamente en los registros.
Hoy hablaremos sobre los errores más comunes.
¡Aviso importante!
No estoy seguro, ¡no lo hagas! ¡No presione y no toque nada en absoluto! Llamar o escribir al soporte de Veeam siempre es mejor que experimentar con su producto. Afortunadamente, nuestro soporte es de habla rusa y extremadamente técnico.
Ante la menor duda, llame y pregunte: "Tengo tal problema, encontré esta solución en la red, ¿me ayudará a solucionarlo?" - normal y correcto. Lo que no es normal y no es correcto es no estar seguro de tus acciones para hacer muchas cosas, y luego pedir restaurar todo desde las ruinas en cinco minutos, y para que no se pierda nada.
Sí, por supuesto, ayudaremos en este caso, pero la mejor batalla es la que no existía. Por lo tanto, siempre trate de evaluar críticamente sus acciones y todo el gran tiempo de actividad.
Error 1 de VDDK: error desconocido
De hecho, tenemos un artículo completo de HF sobre este error . Y, como dice, la mayoría de las veces este error ocurre si tiene demasiados contadores de rendimiento instalados y descarga un parche de VMware que solucionará todo por usted.
Por un lado, ni siquiera hay nada que comentar. Aquí está el problema, aquí hay una descripción (incluso si no está muy clara) y, lo más importante, aquí hay un enlace al medicamento. Sin embargo, no todo es tan sencillo. Según nuestras observaciones, este error puede ocurrir no solo por un problema aburrido con los contadores, sino también por:
- VMDK . , , . — — . , . , , .
- datastore. . , .
- HBA . , . . ?
- , : ESXi vCenter.
Bueno, bueno, me he puesto al día, dices. ¿Y entonces que? ¿Cómo entender que es hora de buscar con urgencia nuevos discos, o es suficiente ponerse un parche y exhalar?
Y te responderé: lleva un conjunto de pruebas sencillas que te ayudarán a tomar la decisión correcta si sucede algo.
- Lanzamos Storage vMotion o simplemente clonamos una máquina sospechosa en otro almacén de datos y luego intentamos iniciar una copia de seguridad. Si la clonación falla, definitivamente hay un problema en algún lugar del subsistema del disco. Modo de paranoia al máximo, y verifique todo, desde los variadores hasta los controladores.
Si se clonó y se guardó con éxito, significa que el VMDK estaba dañado, porque durante la clonación VMware recrea su contenido y ahora definitivamente no hay errores allí.
- , . , . « — » .
- , , , — VMware.
- , . , .
VDDK error 2: Value: 0x0000000000000002
Casi siempre va de la mano con el error 1 de VDDK. Según nuestras estadísticas, la aparición de un error suele estar asociada con ciertas versiones del paquete vCenter / ESXi, por lo que el mejor consejo aquí es actualizar al menos a la versión 6.7. Y mejor y 7.0.
Si no ayuda, vaya al plan B.
El error en sí aparece cuando el host ESXi se queda sin memoria asignada para el búfer de lectura NFC. Por defecto, Veeam opera en modo de lectura asíncrono NBD / NFC, que en condiciones normales puede requerir expandir este búfer. Pero esto no siempre sucede. Por tanto, para desactivar este modo, hay una tecla especial:
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1Después de crearlo, debe reiniciar Veeam Backup Service y estar preparado para un rendimiento que se ha reducido en aproximadamente un 10%.
Otra opción es iniciar sesión desde el lado del host y reiniciar los agentes de administración:
/etc/init.d/hostd restart
/etc/init.d/vpxa restartEl procedimiento se describe en detalle en la KB de VMware , por lo que no lo reescribiremos.
Y un conjunto estándar de opciones que no serán superfluas para clasificar a través del proceso de diagnóstico:
- Migre máquinas con errores a otro host.
- Pruebe otro modo de transporte: HotAdd con proxy virtual o DirectSAN.
Error 3 de VDDK: uno de los parámetros no es válido
Un error que casi siempre ocurre cuando se usa el modo de dispositivo virtual (también conocido como modo HotAdd).
No hay nada especial que contar aquí, solo daré enlaces a dos de nuestras bases de conocimiento, donde se describen muchas opciones, e incluso si viene inmediatamente al soporte, se le pedirá que haga todo lo que está escrito allí.
KB1218 - Descripción general de posibles problemas y métodos para su eliminación.
KB1332 : si su servidor Veeam actúa como proxy para el modo HotAdd
Error 13 de VDDK: no tiene derechos de acceso a este archivo
Y para este caso, tenemos KB2008 . Sí, hay muchas opciones para eliminar este problema, pero tal error. Es casi imposible decir de manera inequívoca qué sucedió exactamente en su caso, por lo que debe tomar e iterar sobre toda la lista.
Lo que me gustaría decir además. Tenga mucho cuidado con la sección Solución de problemas adicionales. Sí, las hay escritas, quizás demasiado obvias para muchas cosas. Pero incluso esos tópicos eluden a los profesionales más profesionales. A menudo hay casos en los que, después de una semana, en un intento de resolver todo por sí mismos, acuden a soporte solo para descubrir que no han leído la lista de requisitos técnicos con atención, o algo así. Y es una pena y una pena por el tiempo invertido.
Y dos consejos para todos los tiempos:
- Veeam proxy , UUID . - , . , , .
- ( — ), , VDDK .
VDDK error 18000: Cannot connect to the host
En la mayoría de los casos, la culpa de este error radica en un error en el propio VDDK. Específicamente, la biblioteca gvmomi.dll tiene la culpa. Y se muestra solo bajo carga pesada. Por ejemplo, cuando se realiza una copia de seguridad de muchas máquinas en paralelo, una de las funciones se convierte en 0 y la biblioteca puede colapsar. Y luego todo lo demás cae.
Ésa es la triste historia.
Pero lo peor de esta historia es que es imposible reproducir con precisión las condiciones del error. Esto es lo que los probadores llaman errores flotantes. Por lo tanto, es imposible decir exactamente cuántas máquinas paralelas están causando el bloqueo.
Sin embargo, según las notas de la versión oficialeste error se ha solucionado por completo. Entonces, la salida correcta es actualizar su host. Pero si por alguna razón es imposible hacer esto, la única forma en que podemos ayudarlo es aconsejarle que reduzca el número de máquinas procesadas simultáneamente.
Ninguna otra manera.
Error 14008 de VDDK: no se pudo establecer contacto con el servidor especificado
Entonces, si este problema le sucedió, lo primero que debe hacer es verificar la red. Lo más probable es que la comunicación entre vCenter y Veeam proxy esté inactiva. Compruebe si todos los puertos están abiertos y accesibles, si todos los nombres DNS se han resuelto correctamente en las direcciones IP esperadas. Además, debe verificar el proxy específico involucrado en el trabajo fallido, y no el que está junto a él (hay casos).
El 95% de los casos con este error se cierran con la marca "Problema con DNS / puertos en la infraestructura del cliente".
Por eso, una vez más les insto a que comprueben con mucho cuidado si el servidor DNS correcto está indicado en todas partes, si hay puertos cerrados y en qué IP se resuelven los nombres de FQDN.
En versiones anteriores de VDDK, había un error similar al usar un puerto no predeterminado para trabajar con vCenter, que representaba el 5% restante, pero ahora VMware ha ocultado la KB con su descripción, lo que probablemente significa que la KB ya no es relevante. Pero puede buscarlo en los archivos de Internet en 2108658 (la copia de seguridad falla cuando se especifica un puerto no predeterminado para VMware vCenter Server).
Error de VDDK 14009: el servidor rechazó la conexión
Y el último error en nuestro top de hoy es El servidor rechazó la conexión. Aquí todo es absolutamente banal: algo impide la conexión entre el host y el proxy. En la mayoría de los casos, el servidor de seguridad es el culpable. Pero, el punto sutil, no por los puertos cerrados, sino por los retrasos introducidos. Entonces, primero que nada, verificamos la apertura del puerto 443, y luego miramos los tiempos de espera.
Si ambas opciones no dieron nada, acuda a soporte. Tendremos que comprobar el host en sí. Quizás simplemente está demasiado ocupado y no tiene tiempo para responder a tiempo, y quizás algo más.
Y finalmente, algunos enlaces útiles:
- Portal de nuestro galardonado soporte técnico.
- Base de conocimientos de soporte de Veeam