Creciendo en error, los administradores de VMware cinco errores principales

Cuando los administradores de VMware hablan sobre los errores cometidos en el trabajo, a menudo digo que si no está cometiendo errores, entonces no está aprendiendo.

Algunos errores se deben a intentos, otros se deben a la falta de conocimiento. Y hay algunas cosas estúpidas que ya deberíamos saber que no debemos hacer. Pero al final, nos convertimos en mejores administradores de VMware debido a los errores que cometimos.

Estos son los errores inolvidables cometidos por los administradores de VMware que Mike Nelson ha visto, escuchado y experimentado.

Error 1 de administrador de VMware: cambio de nombre de máquina virtual

Este tipo de error es muy típico. Cambiar el nombre de una máquina virtual en vCenter es sencillo: haga clic con el botón derecho en el cliente, seleccione Cambiar nombre e ingrese un nombre nuevo.

Pero esta operación simplemente cambia el nombre del puntero del objeto en la base de datos de vCenter, y los directorios y archivos asociados con la máquina virtual aún están bajo el nombre original. Para los administradores de VMware, es fácil limpiar rápidamente el proceso del almacén de datos, eliminar directorios y archivos de máquinas virtuales, y simplemente hacer clic en el mouse, especialmente si no hay una coincidencia de cliente y directorio actual. He visto suceder esto y las consecuencias son muy serias.

Error 2 del administrador de VMware: relleno de todo el LUN

Hace muchos años asistí a una conferencia y es una actividad relacionada con las nuevas funciones de VMware ESX 3. El presentador creó un LUN de 100 GB en la SAN y lo asignó a un grupo de dos nodos para su presentación.

Creó tres máquinas virtuales en este LUN, cada una con un disco duro de 32 GB y un almacén de datos compartidos ISO de 2 GB. Calcule, el espacio de almacenamiento utilizado es: (32 GB x 3) + 2 GB = 98 GB. Para un LUN de 100 GB, hay espacio suficiente, ¿es eso cierto?

Arrancó todas las máquinas virtuales una por una. Cuando se inicia la tercera máquina virtual, todas las máquinas virtuales están muertas. Parece que olvidó crear un archivo de intercambio al iniciar la máquina virtual. Estos archivos de intercambio llenan todo el LUN y son más interesantes porque no sabe por qué sucede esto, por lo que intenta iniciar la máquina virtual nuevamente.

Sí, él es un ingeniero de VMware.

Error 3 del administrador de VMware: Nombre de la red

Fui consultor de un pequeño proyecto institucional en Citrix, donde el ingeniero de almacenamiento estaba administrando el nuevo entorno de virtualización. Un día, recibí una llamada de él. Encontró problemas al realizar operaciones de vMotion, y la programación de recursos distribuidos (DRS) también produjo muchos errores.
(¿Mencioné que este tipo es un ingeniero de almacenamiento?

Inicié sesión en vCenter y descubrí que no todos los hosts de ESX están configurados en la misma red. Cada conmutador virtual tiene una diferente en cada host. Nombre, este es un error común cuando los hosts ESX no se crean al mismo tiempo o no siguen las convenciones de nombres (o incluso no tienen reglas de nombres). VMotion requiere que los nombres de conmutador virtual de todos los hosts en el clúster DRS sean los mismos.

Error 4 de administrador de VMware: luna de miel y funciones

Un administrador de VMware tuvo que solucionar un problema de virtualización antes de ir a la luna de miel. Antes de irse, decidió abandonar la función en vCenter. Además del personal, la infraestructura está bloqueada.

Pero eliminó el objeto vCenter, no solo una máquina virtual o clúster, una función con derechos de acceso. Esta acción evita que cualquier persona tenga acceso al objeto vCenter. >

Escuché esta historia de su novia, porque la operación incorrecta hizo que la luna de miel se quedara en tierra, no estaba nada contenta.

Error de administrador de VMware 5: La tarjeta está completamente arruinada

El archivo de configuración del host de VMware solo apareció un año después, no puedo esperar, y no puedo esperar para implementar rápidamente un host estándar en la implementación básica de más de 500 hosts. Cuando finalmente utilicé el archivo de configuración del host, todo fue incorrecto al mismo tiempo.

Creé un nuevo archivo de configuración del host y lo probé en el host del laboratorio. Después de probar algunas máquinas virtuales en el host, parece que No hubo ningún problema. Así que decidí aplicar el archivo de configuración del host en un clúster con 16 hosts en el entorno de producción.

Más tarde, vCenter se ve bien. Me alegré por 5 segundos y sucedió. Alarma. No se puede acceder a todas mis máquinas virtuales y hosts a través de la red.

Un problema con los archivos de configuración de host de ESX es que, independientemente de la tasa de NIC establecida en el archivo de configuración, todos los archivos de configuración de lectura de tasa de host están predeterminados. Ambos están configurados en modo adaptativo (por supuesto, VMware lo llama una función).

Este ajuste está codificado en 1000M en la red. En el modo completo de recuperación sin problemas, no se puede ejecutar (el puerto de red del laboratorio es automático, por lo que puede ejecutarse normalmente). Una vez que esta configuración se aplica a todos los hosts, se arrastra todo el clúster. Tengo que reiniciar cada host. Configurando manualmente 14 tarjetas de red, tomó todo un día.

¿Shenma? ¿VMware cometió errores?

¿Recuerda la Actualización 2 de ESX 3.5? Miles de hosts en todo el mundo después del fiasco Tiempo de inactividad.

VMware no admitirá fácilmente que los errores descubiertos por la comunidad de usuarios existen. Si tiene instalado ESX 3.5 Update 2, una vez que cambie el reloj a las 12:01 AM del 12 de agosto de 2008, no podrá vMotion ni iniciar ninguna máquina virtual.

VMware finalmente admitió que el problema se debió a un fragmento de código que causó que la licencia expirara, y este código de alguna manera pasó la prueba beta y el control de calidad. Este error de "bomba de tiempo" causó serios problemas. La única solución fue deshabilitar el Protocolo de tiempo de red (NTP) en el servidor y ajustar el reloj al 10 de agosto de 2008. VMware lanzó un parche el 14 de agosto, pero muchos clientes serán cautelosos acerca de los productos de VMware y las pruebas que realiza.

El Sr. Paul Maritz, CEO de VMware, envió un correo electrónico al cliente y se disculpó por el error, diciendo que este problema nunca volverá a ocurrir.