Мы купили программное обеспечение у небольшой компании, это менеджер рабочего процесса для 32-битного видеоконтента Windows, они сделали некоторые настройки.
Мы отлично работали более года, выполняя этот код в виртуальной машине VMWare ESXi 4.1u2 на 32-разрядной версии W2K3EE (это то, на чем они поддерживают его запуск).
Затем они обновили свой код около месяца назад, и мы начали видеть, что один из vCPU периодически привязан к 100%, второй vCPU довольно простаивает, скажем, 5-7% - поэтому мы просто предположили, что код плохо распределяется по потокам, и связались с ними по поводу Это.
Теперь они вернулись к нам и сказали, что их код не работает в виртуальной машине, они знают об этом требовании около 18 месяцев и хотят, чтобы мы реализовали его V2P. Они говорят, что видят эту проблему только при запуске внутри виртуальных машин. Через несколько часов у меня запланирован телефонный разговор с их старшим программистом.
Теперь, к счастью, у нас есть несколько медикаментов, на которых мы можем это сделать, что отнимет немного времени, но выполнимо.
Однако мой вопрос заключается в том, что, учитывая, что эта виртуальная машина напрямую не касается какого-либо оборудования, находится на очень современном хосте и на самом деле имеет очень низкие требования (2 x vCPU, 4 ГБ, загрузочный виртуальный диск 20 ГБ, виртуальный диск данных 100 ГБ, один vNIC и ничего больше), что может быть проблема с запуском его на виртуальной машине, если она есть?
Очевидно, я очень стараюсь с ними работать, но мне просто интересно, нашел ли кто-нибудь еще обычное приложение, которое как-то плохо себя ведет внутри виртуальной машины, но не на физическом.
С ESX v5 и ограничением Monster VM (32vCPU 1TB RAM) количество приложений, имеющих проблемы с VM, сокращается. Большинство из тех, с которыми я столкнулся, либо: - полагаться на время, чтобы быть линейным (процессы в реальном времени или приложения, которые должны иметь линейное время ... это обычно можно настроить) - приложения, вызывающие множество аппаратных прерываний или переключение контекста
В большинстве случаев вы можете попросить своего представителя VMware поговорить с этими парнями. Я считаю, что у vmware все еще есть команда людей, преданных делу, чтобы все работало (у них была лаборатория поддержки только для этого в первые дни).
Что касается решения, у меня была аналогичная проблема с виртуальной машиной, имеющей высокую загрузку ЦП (но на хосте было много свободных ресурсов ЦП). Мы исправили проблему, перейдя на сервер с ЦП Nehalem и изменив уровень совместимости ЦП в EVC (если у вас есть кластер с DRS / HA)
Хотя я не могу говорить от имени этого поставщика или программного пакета, я работал с крупным (многонациональным) поставщиком, у одного из проданных ими программных продуктов были очень специфические известные проблемы при работе с VMware.
В этом случае одна проблема может привести к зависанию программного обеспечения, а другая - к повреждению данных. Таким образом, клиентам было рекомендовано не запускать программное обеспечение в виртуальной среде. Некоторые до сих пор это делают, и во всех случаях, о которых я знал, они сталкивались с одной или обеими проблемами.
Таким образом, хотя это случается редко, могут быть случаи, когда программное обеспечение не работает так, как вы ожидаете от VMware.
Хотя я понимаю, что это напрямую не помогает решить вашу проблему, это показывает, что VMWare не всегда является идеальной системой.
Сноска: в этом случае поставщик смог работать с VMware, чтобы найти решения (некоторые исправления кода, некоторые изменения конфигурации VMWare), и теперь у них есть некоторые (очень конкретные) рекомендации по запуску программного обеспечения на VMWare.
Я видел аналогичную проблему с VMware ESX + Debian 6 + OpenLDAP 2.4.x (независимо от того, какая точная версия OpenLDAP является apt-gettable ...).
При повседневных операциях он работает нормально, но такие вещи, как импорт большого файла LDIF с 400 000 или около того записей, выполняются очень медленно (в 50-100 раз медленнее, чем с физическими серверами). Также с длительным, объемным тестированием все идет гладко, время отклика составляет пару миллисекунд, но иногда бывают странные пики от 500 до 25 000 (!) Миллисекунд.
С физическими серверами я не могу воспроизвести эти проблемы. И да, я потратил около трех недель, пытаясь изолировать проблему, настраивая все виды параметров от параметров операционной системы до значений slapd и значений BerkeleyDB ... ничего не помогло.