Aplicação “não suportada” em uma VM?

Question

Compramos alguns softwares de uma pequena empresa, um gerenciador de fluxo de trabalho de conteúdo de vídeo de 32 bits do Windows, houve alguma customização por eles.

Estamos trabalhando há mais de um ano executando esse código em uma VM VMware ESXi 4.1u2 em W2K3EE-32-bit (é isso que eles suportam executá-lo).

Depois eles atualizaram o código um mês mais ou menos e começamos a ver uma das vCPUs periodicamente marcada a 100%, a segunda vCPU está bastante ociosa, digamos de 5 a 7% - então presumimos que o código está mal e contatou-os sobre isso.

Eles agora voltam para nós dizendo que o código deles não funciona em uma VM, eles sabem sobre esse requisito por 18 meses ou mais, e querem que a V2P seja usada. Eles dizem que só veem esse problema quando são executados em VMs. Eu tenho uma ligação com o programador sênior marcado em algumas horas para discutir.

Agora, felizmente, temos alguns testes físicos nos quais podemos fazer isso, mas consomem muito tempo, mas é possível.

A minha pergunta é que, dado que esta VM não toca directamente em nenhum hardware, está num hospedeiro muito moderno e tem requisitos muito baixos (2 x vCPU, 4GB, 20GB vdisk, 100GB vdisk, vNIC e nada else) o que poderia ser o problema de executá-lo em uma VM, se houver um?

Obviamente, eu estou strongmente buscando isso com eles, mas eu só queria saber se alguém encontrou um aplicativo regular, que de alguma forma se comporta mal dentro de uma VM, mas não em um físico.

    

Answer 1

Embora não possa falar em nome desse fornecedor ou do pacote de software, trabalhei para um grande fornecedor (multinacional), onde um dos softwares que eles vendiam tinha problemas conhecidos muito específicos quando executados no VMware.

Nesse caso, um problema pode causar o deadlock do software e o outro pode corromper os dados. Como tal, os clientes foram aconselhados a não executar o software em um ambiente virtual. Alguns ainda fizeram, e em todos os casos que eu estava ciente, eles se depararam com um ou ambos os problemas.

Portanto, embora seja raro, pode haver casos em que o software não funciona como você esperaria no VMware.

Embora eu saiba que isso não ajude diretamente o seu problema, ele mostra que o VMWare nem sempre é o sistema perfeito.

Nota de rodapé: nesse caso, o fornecedor conseguiu trabalhar com o VMware para encontrar resoluções (algumas correções de código, algumas alterações de configuração do VMWare) e agora elas têm algumas orientações (muito específicas) sobre como executar o software no VMWare. / p>     

Answer 2

Com o ESX v5 e o limite da VM do Monster (32vCPU 1TB RAM), o número de aplicativos com problemas com a VM está diminuindo. A maioria dos que eu experimentei são: - confiando no tempo para ser linear (processos em tempo real ou aplicativos que precisam ter tempo linear ... isso geralmente pode ser ajustado) - aplicativos que causam muitas interrupções de hardware ou troca de contexto

Na maioria dos casos, você deve ser capaz de pedir ao seu representante VMware para conversar com esses caras. Acredito que o vmware ainda tem uma equipe de pessoas dedicada a fazer as coisas funcionarem (eles tinham um laboratório de suporte apenas para isso nos primeiros dias).

Quanto a uma solução, tive um problema semelhante com a VM tendo alto uso de CPU (mas o host tendo muitos recursos de CPU livres). Corrigimos o problema migrando para um servidor com uma CPU Nehalem e alterando o nível de compatibilidade da CPU no EVC (se você tem um cluster com DRS / HA)

    

Answer 3

Eu tenho visto um problema similar com o VMware ESX + Debian 6 + OpenLDAP 2.4.x (qualquer que seja a versão exata do OpenLDAP apt-gettable ...).

Em operações cotidianas, tudo funciona bem, mas coisas como importar um arquivo LDIF largo com 400 000 ou mais entradas são muito lentas (50 a 100 vezes mais lenta do que com servidores físicos). Também com o benchmarking de alto volume e longa duração, tudo está correndo bem, com alguns milissegundos de tempo de resposta, mas ocasionalmente há picos estranhos que variam de 500 a 25.000 (!) Milissegundos.

Com servidores físicos, não consigo reproduzir esses problemas. E sim, passei cerca de três semanas tentando isolar o problema, ajustando todos os tipos de parâmetros dos parâmetros do sistema operacional para slapd valores para valores BerkeleyDB ... nada ajudou.