El único caso en el que tuve que llevar a cabo un V2P fue para una caja MS SQL que se había estado ejecutando en CPU de doble núcleo dual de 3.2Ghz (CPU total de 14.4Ghz) que migramos a un clúster ESX 2.5 donde el hardware subyacente era más nuevo con más núcleos más lentos (2.4Ghz IIRC). Agregando una sobrecarga de ~ 10% incluso con 4 vCPU, esta VM solo podría obtener una CPU agregada efectiva de 8-8.5Ghz. 60% de CPU máxima antes de que la migración se convirtiera en 90-100% después de la migración, el cliente quería espacio libre, así que volvimos a la física. Para responder a su pregunta específicamente, vimos que la caja se estaba ejecutando al 100% de CPU en todos los ámbitos en Perfmon y en el cliente VI. Una mejor solución (en mi opinión) hubiera sido actualizar a CPU más rápidas, pero hay casos extremos como este en los que eso no es económico, especialmente con la tendencia a una CPU más lenta '
Con ESX 4 podríamos aumentar una caja como esta hasta 8 vCPU, pero esa no era una opción en ese momento.
En cuanto a buscar límites de rendimiento que puedan indicar que necesita abandonar su VM y luego con un Windows Guest en un entorno VMWare, entonces la combinación de Perfmon y VI Client debería ser más que suficiente para encontrar cualquier VM que tenga un rendimiento limitado. . Agregue la posibilidad de obtener algunos análisis de SAN si puede, pero si el SAN muestra un problema, entonces seguramente estará reelaborando el almacenamiento para aislar y / o mejorar los volúmenes en los que se almacenan los discos virtuales de la VM. Lo mismo se aplica a cualquier otra combinación de sistema operativo / hipervisor: obtenga las estadísticas internas que pueda pero correlacione con la vista del hipervisor de lo que está sucediendo porque el 100% de la CPU que se informa dentro de una máquina virtual (por ejemplo) no necesariamente significa que el hipervisor nunca podría entregar más rendimiento,