Jedyny przypadek, w którym musiałem przeprowadzić V2P, dotyczył MS SQL box, który działał na podwójnych dwurdzeniowych procesorach 3,2 Ghz (całkowity procesor 14,4 Ghz), które migrowaliśmy do klastra ESX 2.5, w którym podstawowy sprzęt był nowszy z większą liczbą wolniejsze (2,4 Ghz IIRC) rdzenie. Dodając ok. 10% obciążenia nawet przy 4 procesorach vCPU, ta maszyna wirtualna mogłaby kiedykolwiek uzyskać efektywny agregat 8–8,5 GHz. Szczyt 60% procesora przed migracją stał się 90-100% po migracji, klient chciał rezerwy, więc wróciliśmy do fizycznej. Aby odpowiedzieć na twoje pytanie konkretnie, zauważyliśmy, że urządzenie działało na 100% procesorze w całym systemie Perfmon i kliencie VI. Lepszym rozwiązaniem (moim zdaniem) byłoby uaktualnienie do szybszych procesorów, ale istnieją takie przypadki krawędziowe, w których nie jest to ekonomiczne, szczególnie w przypadku tendencji do wolniejszego procesora
Dzięki ESX 4 możemy podbić takie pudełko do 8 procesorów vCPU, ale wtedy nie było to możliwe.
Jeśli chodzi o szukanie pułapów wydajności, które mogą wskazywać na konieczność porzucenia maszyny wirtualnej, to w przypadku gościa Windows w środowisku VMWare połączenie Perfmon i klienta VI powinno być więcej niż zadaniem znalezienia dowolnej maszyny wirtualnej, która sama ogranicza wydajność . Dodaj do tego trochę analizy SAN, jeśli możesz, ale jeśli SAN pokazuje problem, prawie na pewno równie dobrze przerobisz pamięć masową, aby wyizolować i \ lub zwiększyć woluminy, na których przechowywane są dyski wirtualne maszyny wirtualnej. To samo dotyczy każdej innej kombinacji OS \ Hypervisor - uzyskaj wszelkie wewnętrzne statystyki, które możesz, ale skoreluj je z widokiem Hypervisora na to, co się dzieje, ponieważ 100% CPU zgłaszane w maszynie wirtualnej (na przykład) niekoniecznie oznacza, że Hypervisor nigdy nie może dostarczyć większa wydajność,