Aplikacja „nieobsługiwana” na maszynie wirtualnej?

Kupiliśmy oprogramowanie od małej firmy, jest to 32-bitowy menedżer przepływu treści wideo w systemie Windows, który został przez nich dostosowany.

Od ponad roku działamy dobrze, uruchamiając ten kod w VMWare ESXi 4.1u2 VM na W2K3EE-32-bit (właśnie na tym obsługują).

Potem zaktualizowali swój kod mniej więcej miesiąc temu i zaczęliśmy widzieć, że jedna z vCPU okresowo ustalana jest na 100%, druga vCPU jest dość bezczynna, powiedzmy 5-7% - więc po prostu założyliśmy, że kod jest źle napisany i skontaktowaliśmy się z nimi w sprawie to.

Teraz wrócili do nas, mówiąc, że ich kod nie działa na maszynie wirtualnej, wiedzieli o tym wymaganiu od około 18 miesięcy i chcą, abyśmy to zrobili. Mówią, że widzą ten problem tylko wtedy, gdy działają w maszynach wirtualnych. Mam rozmowę z ich starszym programistą zaplanowanym za kilka godzin w celu omówienia.

Teraz na szczęście mamy kilka elementów fizycznych, na których możemy to zrobić, trochę czasochłonne, ale wykonalne.

Moje pytanie jest jednak takie, że biorąc pod uwagę, że ta maszyna wirtualna nie dotyka bezpośrednio żadnego sprzętu, jest na bardzo nowoczesnym hoście i faktycznie ma bardzo niskie wymagania (2 x vCPU, 4 GB, dysk rozruchowy 20 GB, dysk danych 100 GB, pojedynczy dysk vNIC i nic więcej) co może być problem z uruchomieniem go na maszynie wirtualnej, jeśli taka istnieje?

Oczywiście zdecydowanie staram się to osiągnąć, ale zastanawiałem się, czy ktokolwiek znalazł regularną aplikację, która jakoś źle zachowuje się w maszynie wirtualnej, ale nie w fizyce.

Chociaż nie mogę wypowiadać się za tym dostawcą ani pakietem oprogramowania, pracowałem dla dużego (międzynarodowego) dostawcy, w którym jeden z sprzedawanych przez niego programów miał bardzo znane znane problemy podczas uruchamiania na VMware.

W takim przypadku jeden problem może spowodować zakleszczenie oprogramowania, a drugi może spowodować uszkodzenie danych. W związku z tym doradzono klientom, aby nie uruchamiali oprogramowania w środowisku wirtualnym. Niektórzy nadal tak robili i we wszystkich przypadkach, o których wiedziałem, napotkali jeden lub oba problemy.

Chociaż jest to rzadkie, mogą zdarzyć się przypadki, w których oprogramowanie nie działa tak, jak można tego oczekiwać w VMware.

Chociaż zdaję sobie sprawę, że nie pomaga to bezpośrednio Twojemu problemowi, pokazuje, że VMWare nie zawsze jest idealnym systemem.

Przypis: w tym przypadku dostawca był w stanie współpracować z VMware w celu znalezienia rozwiązań (niektóre poprawki kodu, niektóre zmiany konfiguracji VMWare), a teraz mają pewne (bardzo szczegółowe) wskazówki dotyczące uruchamiania oprogramowania na VMWare.

W przypadku ESX v5 i limitu Monster VM (32vCPU 1 TB RAM) liczba aplikacji mających problemy z VM zmniejsza się. Większość z tych, których doświadczyłem, to: - poleganie na czasie, aby być liniowym (procesy w czasie rzeczywistym lub aplikacje, które muszą mieć czas liniowy ... zwykle można to poprawić) - aplikacje powodujące wiele przerwań sprzętowych lub przełączania kontekstu

W większości przypadków powinieneś być w stanie poprosić swojego przedstawiciela vmware o rozmowę z tymi facetami. Wierzę, że vmware wciąż ma zespół ludzi zaangażowanych w sprawianie, aby wszystko działało (mieli na początku laboratorium wsparcia technicznego).

Jeśli chodzi o rozwiązanie, miałem podobny problem z VM o wysokim zużyciu procesora (ale host ma dużo zasobów procesora wolnych). Rozwiązaliśmy ten problem, migrując na serwer z procesorem Nehalem i zmieniając poziom kompatybilności procesora w EVC (jeśli masz klaster z DRS / HA)

Widziałem podobny problem z VMware ESX + Debian 6 + OpenLDAP 2.4.x (niezależnie od dokładnej wersji OpenLDAP jest apt-gettable ...).

W codziennych operacjach działa OK, ale rzeczy takie jak importowanie dużego pliku LDIF zawierającego około 400 000 wpisów są bardzo wolne (50-100x wolniej niż w przypadku serwerów fizycznych). Również przy długookresowym, wysokonakładowym testowaniu wszystko idzie płynnie z czasem reakcji wynoszącym kilka milisekund, ale czasami zdarzają się dziwne wartości szczytowe od 500 do 25 000 (!) Milisekund.

W przypadku serwerów fizycznych nie jestem w stanie odtworzyć tych problemów. I tak, spędziłem około trzech tygodni próbując wyizolować problem, dostosowując wszystkie parametry od parametrów systemu operacyjnego do wartości slapd do wartości BerkeleyDB ... nic nie pomogło.