Приложение не поддерживается в виртуальной машине?

Мы купили какое-то программное обеспечение у небольшой компании, это 32-битный диспетчер рабочих процессов для видеоконтента в Windows, они были немного изменены.

Мы работали более года, выполняя этот код на виртуальной машине VMWare ESXi 4.1u2 на W2K3EE-32-битной (это то, что они поддерживают на нем).

Затем они обновили свой код примерно месяц назад, и мы начали видеть, что один из виртуальных ЦП периодически привязан к 100%, второй виртуальный ЦП довольно проста, скажем, 5-7% - поэтому мы просто предположили, что код плохо переплетен, и связались с ними по поводу Это.

Теперь они вернулись к нам, сказав, что их код не работает на виртуальной машине, они знали об этом требовании около 18 месяцев и хотят, чтобы мы выполнили его. Они говорят, что видят эту проблему только при запуске внутри виртуальных машин. Мне нужно позвонить их старшему программисту, чтобы обсудить их через несколько часов.

Теперь, к счастью, у нас есть несколько физических упражнений, на которых мы можем сделать это, немного времени, но выполнимо.

Мой вопрос, однако, заключается в том, что, учитывая, что эта виртуальная машина не касается напрямую какого-либо оборудования, она находится на очень современном хосте и на самом деле имеет очень низкие требования (2 x vCPU, 4 ГБ, загрузочный виртуальный диск 20 ГБ, виртуальный диск данных 100 ГБ, один виртуальный сетевой адаптер и ничего больше), что Может ли быть проблема с запуском его на виртуальной машине, если она есть?

Очевидно, я решительно преследую это вместе с ними, но мне просто интересно, нашел ли кто-нибудь еще обычное приложение, которое как-то плохо себя ведет внутри ВМ, но не на физическом.

Хотя я не могу говорить об этом поставщике или программном пакете, я работал на крупного (многонационального) поставщика, где у одного из продаваемых ими компонентов были очень специфические известные проблемы при работе на VMware.

В этом случае одна проблема может привести к взаимоблокировке программного обеспечения, а другая - к повреждению данных. Таким образом, клиентам было рекомендовано не запускать программное обеспечение в виртуальной среде. Некоторые все же сделали это, и во всех известных мне случаях они столкнулись с одной или обеими проблемами.

Так что, хотя это редко, могут быть случаи, когда программное обеспечение не работает так, как вы ожидаете, в VMware.

Хотя я понимаю, что это не поможет вашей проблеме, это показывает, что VMWare не всегда идеальная система.

Сноска: в этом случае поставщик смог работать с VMware, чтобы найти решения (некоторые исправления кода, некоторые изменения конфигурации VMWare), и теперь у них есть некоторые (очень специфические) рекомендации о том, как запускать программное обеспечение на VMWare.

С ESX v5 и лимитом Monster VM (32 В ЦП 1 ТБ ОЗУ) число приложений, имеющих проблемы с ВМ, сокращается. Большинство из тех, что я испытал, это: - полагаться на время, чтобы быть линейным (процессы в реальном времени или приложения, которые должны иметь линейное время ... обычно это можно настроить) - приложения, вызывающие много аппаратных прерываний или переключение контекста

В большинстве случаев вы должны попросить своего представителя vmware поговорить с этими парнями. Я полагаю, что в vmware все еще есть команда людей, преданных своему делу (в первые дни у них была лаборатория поддержки).

Что касается решения, у меня была похожая проблема с ВМ, имеющей высокую загрузку ЦП (но на хосте было достаточно ресурсов ЦП). Мы устранили проблему, перейдя на сервер с процессором Nehalem и изменив уровень совместимости процессора в EVC (если у вас есть кластер с DRS / HA)

Я видел подобную проблему с VMware ESX + Debian 6 + OpenLDAP 2.4.x (какой бы точной версией OpenLDAP не была apt-gettable ...).

При повседневных операциях все работает нормально, но такие вещи, как импорт большого файла LDIF с 400 000 или около того записей, выполняются очень медленно (в 50-100 раз медленнее, чем на физических серверах). Кроме того, при длительном тестировании большого объема все идет гладко с временем отклика в пару миллисекунд, но иногда возникают странные пики в диапазоне от 500 до 25 000 (!) Миллисекунд.

С физическими серверами я не могу воспроизвести эти проблемы. И да, я потратил около трех недель, пытаясь изолировать проблему, настраивая все виды параметров от параметров операционной системы до значений slapd и значений BerkeleyDB ... ничего не помогло.