Adicionando vCPUs a uma instalação do sistema operacional existente

Question

A caixa de diálogo de configuração da VM no ESXi 5 me avisa que, se eu alterar o número de vCPUs após o sistema operacional convidado ser instalado, o céu irá cair - ahem - isso pode tornar minha máquina virtual instável.

Eu sei que certas instruções de CPU envolvidas na serialização de threads exigirão um prefixo LOCK em um sistema multiprocessador, mas não em um sistema de uniprocessador (ou pelo menos não com um único núcleo). O sistema operacional geralmente omite os LOCKs onde eles não são necessários.

Se o sistema operacional usa um kernel que omite os LOCKs, mas usa várias CPUs, isso levaria a extrema instabilidade e a erros difíceis de isolar. Mas se o kernel foi projetado para um processador, então o que ele está fazendo usando mais de um (o que é necessário fazer conscientemente)? Isso parece um projeto de sistema operacional completamente absurdo que eu espero que não exista na prática.

Um design de SO mais plausível seria detectar CPUs na inicialização e escolher o kernel de uniprocessador ou multiprocessador de acordo. Caso contrário, o único outro design sensato instalaria o kernel correto, mas o kernel do uniprocessador simplesmente nunca usaria o outro processador e, portanto, não haveria nenhum dano em outra CPU além de não estar sendo usada.

O software aplicativo pode ter problemas um pouco mais fáceis, porque é fácil usar vários segmentos, mesmo em um sistema de núcleo único, sem prestar atenção ao fato de estar em um sistema multiprocessador e não em LOCKing (ou usando as instalações do sistema operacional) ) poderia causar erros horríveis. Mas algum software sério teria um design tão fraco a ponto de testar o status uni / multiprocessador somente durante a instalação?

Qual é o raciocínio por trás do aviso do dia do Juízo Final? Em quais SOs ou aplicativos eu deveria esperar problemas?

    

Answer 1

Apenas adicionar ou remover vCPUs após a instalação do sistema operacional convidado não é um problema com qualquer versão do Linux ou Windows que seja recente o suficiente para continuar sendo suportada pelo fornecedor. Esse aviso remonta aos primórdios da VMware e é mais irrelevante agora.

No início do Linux, porém, o kernel tinha que ser especificamente compilado com suporte a SMP, e ocasionalmente os kernels UP não gostavam de rodar em sistemas SMP / NUMA, ou vice-versa. Esses dias são muito esquecidos desde a maior parte do tempo.

Hoje em dia, os kernels Linux quase sempre são compilados com suporte a SMP / NUMA por padrão e funcionam bem mesmo com um processador. Isto tem sido verdade para todos os 2.6 e mais ou todos os 2.4.

O Windows se comportou de maneira semelhante desde o Server 2003. Não consegui encontrar rapidamente informações definitivas na Internet sobre como o 2000 e o NT 4.0 se comportaram, embora pareçam lembrar de memória distante que eles podem ter tido problemas ao trocar de um CPU única para múltiplas configurações de CPU.

Se você planeja usar P2V em um sistema muito antigo , é possível, teoricamente, encontrar problemas.