Anwendung "nicht unterstützt" in einer VM?

Wir haben Software von einem kleinen Unternehmen gekauft. Es handelt sich um einen Windows 32-Bit-Workflow-Manager für Videoinhalte. Diese wurden von ihnen angepasst.

Wir arbeiten seit über einem Jahr einwandfrei daran, diesen Code in einer VMWare ESXi 4.1u2-VM auf W2K3EE-32-Bit auszuführen (genau dafür wird die Ausführung unterstützt).

Dann haben sie ihren Code vor ungefähr einem Monat aktualisiert und wir haben festgestellt, dass eine der vCPUs regelmäßig mit 100% verbunden ist. Die zweite vCPU ist ziemlich untätig, sagen wir 5-7%. Wir haben also nur angenommen, dass der Code schlecht gefädelt ist, und haben sie kontaktiert es.

Sie sind jetzt zu uns zurückgekehrt und haben gesagt, dass ihr Code in einer VM nicht funktioniert. Sie kennen diese Anforderung seit ungefähr 18 Monaten und möchten, dass wir sie mit V2P bearbeiten. Sie sagen, dass sie dieses Problem nur sehen, wenn sie in VMs ausgeführt werden. Ich habe einen Anruf mit ihrem leitenden Programmierer, der in ein paar Stunden besprochen werden soll.

Zum Glück haben wir jetzt ein paar physische Dinge, mit denen wir dies tun können, etwas zeitaufwändig, aber machbar.

Meine Frage ist jedoch, dass diese VM keine Hardware direkt berührt, sich auf einem sehr modernen Host befindet und tatsächlich sehr geringe Anforderungen hat (2 x vCPU, 4 GB, 20 GB Boot-Vdisk, 100 GB Daten-Vdisk, einzelne vNIC und sonst nichts) könnte möglicherweise das Problem beim Ausführen in einer VM sein, wenn es eine gibt?

Natürlich verfolge ich das mit ihnen nachdrücklich, aber ich habe mich nur gefragt, ob jemand eine reguläre Anwendung gefunden hat, die sich in einer VM irgendwie schlecht verhält, aber nicht auf einer physischen.

Obwohl ich nicht für diesen Anbieter oder das Softwarepaket sprechen kann, habe ich für einen großen (multinationalen) Anbieter gearbeitet, bei dem eine der von ihnen verkauften Software sehr spezifische bekannte Probleme hatte, wenn sie unter VMware ausgeführt wurden.

In diesem Fall kann ein Problem dazu führen, dass die Software blockiert, und das andere kann zu einer Beschädigung der Daten führen. Daher wurde den Kunden empfohlen, die Software nicht in einer virtuellen Umgebung auszuführen. Einige taten es immer noch, und in allen mir bekannten Fällen stießen sie auf eines oder beide Probleme.

Obwohl dies selten vorkommt, kann es Fälle geben, in denen Software nicht so funktioniert, wie Sie es in VMware erwarten würden.

Mir ist zwar klar, dass es Ihrem Problem nicht direkt hilft, aber es zeigt, dass VMWare nicht immer das perfekte System ist.

Fußnote: In diesem Fall konnte der Anbieter mit VMware zusammenarbeiten, um Lösungen zu finden (einige Codekorrekturen, einige Änderungen an der VMWare-Konfiguration), und sie haben jetzt einige (sehr spezifische) Anleitungen zum Ausführen der Software unter VMWare.

Mit ESX v5 und dem Monster VM-Limit (32 vCPU 1 TB RAM) verringert sich die Anzahl der Anwendungen, bei denen Probleme mit der VM auftreten. Die meisten, die ich erlebt habe, sind entweder: - sich auf die Zeit verlassen, um linear zu sein (Echtzeitprozesse oder Apps, die eine lineare Zeit benötigen ... dies kann normalerweise optimiert werden) - Apps, die viele Hardware-Interrupts oder Kontextwechsel verursachen

In den meisten Fällen sollten Sie Ihren VMware-Mitarbeiter bitten können, mit diesen Leuten zu sprechen. Ich glaube, vmware hat immer noch ein Team von Leuten, die sich dafür einsetzen, dass die Dinge funktionieren (sie hatten in den frühen Tagen nur dafür ein Support-Labor).

Als Lösung hatte ich ein ähnliches Problem mit VMs mit hoher CPU-Auslastung (aber Host mit vielen freien CPU-Ressourcen). Wir haben das Problem behoben, indem wir auf einen Server mit einer Nehalem-CPU migriert und die CPU-Kompatibilitätsstufe in EVC geändert haben (wenn Sie einen Cluster mit DRS / HA haben).

Ich habe ein ähnliches Problem mit VMware ESX + Debian 6 + OpenLDAP 2.4.x gesehen (unabhängig von der genauen Version von OpenLDAP ist apt-gettable ...).

Im täglichen Betrieb funktioniert es einwandfrei, aber Dinge wie das Importieren einer größeren LDIF-Datei mit etwa 400.000 Einträgen sind sehr langsam (50-100x langsamer als bei physischen Servern). Auch beim lang andauernden Benchmarking mit hohem Volumen läuft alles reibungslos mit einer Reaktionszeit von einigen Millisekunden, aber gelegentlich gibt es seltsame Spitzenwerte zwischen 500 und 25 000 (!) Millisekunden.

Mit physischen Servern kann ich diese Probleme nicht reproduzieren. Und ja, ich habe ungefähr drei Wochen damit verbracht, das Problem zu isolieren und alle Arten von Parametern von Betriebssystemparametern über Slapd-Werte bis hin zu BerkeleyDB-Werten abzustimmen ... nichts hat geholfen.