VMware ESXi - VMware ESXi

VMware ESXi
VMwareESXiHostClientSummary.png
Desenvolvedor (s) VMware, Inc.
lançamento inicial 23 de março de 2001 ; 20 anos atras ( 23/03/2001 )
Versão estável
7.0 Atualização 3 (compilação 18644231) / 5 de outubro de 2021 ; 11 dias atrás ( 2021-10-05 )
Plataforma IA-32 (x86-32) (descontinuado em 4.0 em diante), x86-64 , ARM
Modelo Hipervisor nativo (tipo 1)
Licença Proprietário
Local na rede Internet www .vmware .com / products / esxi-and-esx .html

VMware ESXi (anteriormente ESX ) é uma empresa de classe , tipo 1 hypervisor desenvolvido pela VMware para implantar e servindo computadores virtuais . Como um hipervisor tipo 1, o ESXi não é um aplicativo de software instalado em um sistema operacional (SO); em vez disso, ele inclui e integra componentes vitais do sistema operacional, como um kernel .

Após a versão 4.1 (lançada em 2010), a VMware renomeou ESX para ESXi . O ESXi substitui o Service Console (um sistema operacional rudimentar) por um sistema operacional mais integrado. ESX / ESXi é o principal componente do pacote de software VMware Infrastructure .

O nome ESX originou-se como uma abreviatura de elástico Céu X . Em setembro de 2004, a substituição do ESX foi internamente chamada de VMvisor , mas depois mudou para ESXi (já que o "i" no ESXi significava "integrado").

Arquitetura

ESX é executado em bare metal (sem executar um sistema operacional), ao contrário de outros produtos VMware. Inclui seu próprio kernel. No VMware ESX histórico, um kernel Linux foi iniciado primeiro e depois usado para carregar uma variedade de componentes de virtualização especializados, incluindo ESX, que também é conhecido como o componente vmkernel. O kernel do Linux era a máquina virtual primária; ele foi invocado pelo console de serviço. No tempo de execução normal, o vmkernel estava sendo executado no computador vazio e o console de serviço baseado em Linux era executado como a primeira máquina virtual. A VMware abandonou o desenvolvimento do ESX na versão 4.1 e agora usa o ESXi, que não inclui um kernel Linux.

O vmkernel é um microkernel com três interfaces: hardware, sistemas convidados e o console de serviço (Console OS).

Interface para hardware

O vmkernel lida com CPU e memória diretamente, usando scan-before-execute (SBE) para lidar com instruções de CPU especiais ou privilegiadas e o SRAT (tabela de alocação de recursos do sistema) para rastrear a memória alocada.

O acesso a outro hardware (como rede ou dispositivos de armazenamento) ocorre por meio de módulos. Pelo menos alguns dos módulos derivam de módulos usados ​​no kernel do Linux . Para acessar esses módulos, um módulo adicional chamado vmklinuximplementa a interface do módulo Linux. De acordo com o arquivo README, "Este módulo contém a camada de emulação Linux usada pelo vmkernel."

O vmkernel usa os drivers de dispositivo:

  1. net / e100
  2. net / e1000
  3. net / e1000e
  4. net / bnx2
  5. net / tg3
  6. rede / forçada
  7. net / pcnet32
  8. bloquear / cciss
  9. scsi / adp94xx
  10. scsi / aic7xxx
  11. scsi / aic79xx
  12. scsi / ips
  13. scsi / lpfcdd-v732
  14. scsi / megaraid2
  15. scsi / mptscsi_2xx
  16. scsi / qla2200-v7.07
  17. scsi / megaraid_sas
  18. scsi / qla4010
  19. scsi / qla4022
  20. scsi / vmkiscsi
  21. scsi / aacraid_esx30
  22. scsi / lpfcdd-v7xx
  23. scsi / qla2200-v7xx

Esses drivers correspondem principalmente aos descritos na lista de compatibilidade de hardware da VMware . Todos esses módulos estão sob a GPL . Os programadores os adaptaram para rodar com o vmkernel: a VMware Inc. mudou o carregamento do módulo e algumas outras coisas menores.

Console de serviço

No ESX (e não no ESXi), o Service Console é um sistema operacional residual de uso geral mais significativamente usado como bootstrap para o kernel VMware, vmkernel e, secundariamente, usado como uma interface de gerenciamento. Ambas as funções do sistema operacional do console estão sendo descontinuadas da versão 5.0, pois o VMware migra exclusivamente para o modelo ESXi. O Console de serviço, para todos os efeitos, é o sistema operacional usado para interagir com o VMware ESX e as máquinas virtuais que são executadas no servidor.

Tela roxa da morte

Uma tela de diagnóstico roxa como vista no VMware ESX Server 3.0
Uma tela de diagnóstico roxa do VMware ESXi 4.1

No caso de um erro de hardware, o vmkernel pode capturar uma exceção de verificação de máquina. Isso resulta em uma mensagem de erro exibida em uma tela de diagnóstico roxa. Isso é coloquialmente conhecido como tela de diagnóstico roxa ou tela roxa da morte (PSoD, cf. tela azul da morte (BSoD)).

Ao exibir uma tela de diagnóstico roxa, o vmkernel grava informações de depuração na partição de despejo de núcleo. Essas informações, junto com os códigos de erro exibidos na tela roxa de diagnóstico, podem ser usadas pelo suporte da VMware para determinar a causa do problema.

Versões

O VMware ESX está disponível em dois tipos principais: ESX e ESXi, embora desde a versão 5 apenas ESXi seja continuado.

ESX e ESXi anteriores à versão 5.0 não são compatíveis com Windows 8 / Windows 2012. Esses sistemas operacionais da Microsoft só podem ser executados no ESXi 5.x ou posterior.

VMware ESXi, uma versão menor do ESX, não inclui o ESX Service Console. Ele está disponível - sem a necessidade de adquirir uma licença do vCenter - como um download gratuito da VMware, com alguns recursos desabilitados.

ESXi significa "ESX integrado".

O VMware ESXi se originou como uma versão compacta do VMware ESX que permitia uma pegada de disco menor de 32 MB no host. Com um console de configuração simples para principalmente configuração de rede e VMware Infrastructure Client Interface com base remota, isso permite que mais recursos sejam dedicados aos ambientes convidados.

Existem duas variações do ESXi:

  • VMware ESXi instalável
  • VMware ESXi Embedded Edition

A mesma mídia pode ser usada para instalar qualquer uma dessas variações, dependendo do tamanho da mídia de destino. Pode-se atualizar o ESXi para VMware Infrastructure 3 ou para VMware vSphere 4.0 ESXi.

Originalmente chamado VMware ESX Server ESXi edition, por meio de várias revisões o produto ESXi finalmente se tornou VMware ESXi 3. Seguiram-se novas edições: ESXi 3.5, ESXi 4, ESXi 5 e (a partir de 2015) ESXi 6.

Processo de violação de GPL

A VMware foi processada por Christoph Hellwig, um desenvolvedor de kernel. O processo começou em 5 de março de 2015. Foi alegado que a VMware havia se apropriado indevidamente de partes do kernel do Linux e, após a rejeição pelo tribunal em 2016, Hellwig anunciou que entraria com um recurso.

O recurso foi decidido em fevereiro de 2019 e novamente rejeitado pelo tribunal alemão, com base no não cumprimento dos "requisitos processuais para o ónus da prova do autor".

Na última fase da ação, em março de 2019, o Tribunal Regional Superior de Hamburgo também rejeitou a ação por motivos processuais. Em seguida, a VMware anunciou oficialmente que removeria o código em questão. Isso seguiu com Hellwig retirando seu caso e negando mais ações legais.

Produtos relacionados ou adicionais

Os seguintes produtos operam em conjunto com ESX:

  • vCenter Server , permite o monitoramento e gerenciamento de vários servidores ESX, ESXi e GSX. Além disso, os usuários devem instalá-lo para executar serviços de infraestrutura, como:
    • vMotion (transferência de máquinas virtuais entre servidores durante a execução, com tempo de inatividade zero)
    • svMotion, também conhecido como Storage vMotion (transferência de máquinas virtuais entre LUNs de armazenamento compartilhado em tempo real, com tempo de inatividade zero)
    • Enhanced vMotion também conhecido como evMotion (um vMotion e svMotion simultâneos, com suporte na versão 5.1 e superior)
    • Distributed Resource Scheduler (DRS) (vMotion automatizado com base em requisitos / demandas de carga de host / VM)
    • Alta disponibilidade (HA) (reinicialização dos sistemas operacionais convidados da máquina virtual em caso de falha física do host ESX)
    • Fault Tolerance (FT) (failover com estado quase instantâneo de uma VM no caso de uma falha física do host)
  • Converter , permite que os usuários criem máquinas virtuais compatíveis com VMware ESX Server ou Workstation a partir de máquinas físicas ou de máquinas virtuais feitas por outros produtos de virtualização. O Converter substitui os produtos VMware "P2V Assistant" e "Importer" - o P2V Assistant permitia aos usuários converter máquinas físicas em máquinas virtuais, e o Importer permitia a importação de máquinas virtuais de outros produtos para o VMware Workstation.
  • O vSphere Client (anteriormente VMware Infrastructure Client), permite o monitoramento e o gerenciamento de uma única instância do servidor ESX ou ESXi. Após o ESX 4.1, o vSphere Client não estava mais disponível no servidor ESX / ESXi, mas deve ser baixado do site da VMware.

Cisco Nexus 1000v

A conectividade de rede entre hosts ESX e as VMs em execução depende de NICs virtuais (dentro da VM) e switches virtuais. O último existe em duas versões: o vSwitch 'padrão' permitindo que várias VMs em um único host ESX compartilhem um NIC físico e o 'vSwitch distribuído', onde os vSwitches em diferentes hosts ESX juntos formam um switch lógico. A Cisco oferece em sua linha de produtos Cisco Nexus o Nexus 1000v , uma versão avançada do vSwitch padrão distribuído. Um Nexus 1000v consiste em duas partes: um módulo supervisor (VSM) e em cada host ESX um módulo Ethernet virtual (VEM). O VSM é executado como um dispositivo virtual dentro do cluster ESX ou em hardware dedicado (Nexus série 1010) e o VEM é executado como um módulo em cada host e substitui um dvS (switch virtual distribuído) padrão do VMware.

A configuração do switch é feita no VSM usando o NX-OS CLI padrão . Ele oferece recursos para criar perfis de porta padrão que podem ser atribuídos a máquinas virtuais usando o vCenter.

Existem várias diferenças entre o dvS padrão e o N1000v; uma é que o switch Cisco geralmente tem suporte total para tecnologias de rede, como agregação de link LACP, ou que o switch VMware oferece suporte a novos recursos, como roteamento baseado na carga física da NIC. No entanto, a principal diferença está na arquitetura: o Nexus 1000v funciona da mesma forma que um switch Ethernet físico, enquanto o dvS depende das informações do ESX. Isso tem consequências, por exemplo, na escalabilidade, onde o limite Kappa para um N1000v é 2.048 portas virtuais contra 60.000 para um dvS.

O Nexus1000v é desenvolvido em cooperação entre Cisco e VMware e usa a API do dvS

Ferramentas de gerenciamento de terceiros

Como o VMware ESX é líder no mercado de virtualização de servidores, os fornecedores de software e hardware oferecem uma variedade de ferramentas para integrar seus produtos ou serviços ao ESX. Exemplos são os produtos da Veeam Software com aplicativos de backup e gerenciamento e um plug-in para monitorar e gerenciar ESX usando HP OpenView , Quest Software com uma variedade de aplicativos de gerenciamento e backup e a maioria dos principais provedores de soluções de backup têm plug-ins ou módulos para ESX. O uso do Microsoft Operations Manager (SCOM) 2007/2012 com um pacote de gerenciamento Bridgeways ESX oferece uma visão da integridade do datacenter ESX em tempo real.

Além disso, fornecedores de hardware como Hewlett-Packard e Dell incluem ferramentas para oferecer suporte ao uso de ESX (i) em suas plataformas de hardware. Um exemplo é o módulo ESX para a plataforma de gerenciamento OpenManage da Dell.

O VMware adicionou um cliente Web desde a v5, mas ele funcionará apenas no vCenter e não contém todos os recursos. O vEMan é um aplicativo Linux que está tentando preencher essa lacuna. Estes são apenas alguns exemplos: existem vários produtos de terceiros para gerenciar, monitorar ou fazer backup de infraestruturas ESX e as VMs em execução nelas.

Limitações conhecidas

As limitações conhecidas do VMware ESXi 7.0 U1, em setembro de 2020, incluem o seguinte:

Limitações de infraestrutura

Alguns máximos no ESXi Server 7.0 podem influenciar o design dos centros de dados:

  • RAM máxima do sistema convidado: 24 TB
  • RAM máxima do sistema host: 24 TB
  • Número de hosts em um cluster de alta disponibilidade ou do Distributed Resource Scheduler: 96
  • Número máximo de processadores por máquina virtual: 768
  • Número máximo de processadores por host: 768
  • Número máximo de CPUs virtuais por núcleo de CPU físico : 32
  • Número máximo de máquinas virtuais por host: 1024
  • Número máximo de CPUs virtuais por máquina virtual tolerante a falhas: 8
  • RAM máxima do sistema convidado por máquina virtual tolerante a falhas: 128 GB
  • Tamanho máximo do volume VMFS5: 64 TB, mas o tamanho máximo do arquivo é 62 TB -512 bytes
  • Memória máxima de vídeo por máquina virtual: 4 GB

Limitações de desempenho

Em termos de desempenho, a virtualização impõe um custo no trabalho adicional que a CPU precisa realizar para virtualizar o hardware subjacente. As instruções que executam esse trabalho extra e outras atividades que exigem virtualização tendem a estar nas chamadas do sistema operacional. Em um sistema operacional não modificado, as chamadas do sistema operacional introduzem a maior parte da "sobrecarga" de virtualização.

A paravirtualização ou outras técnicas de virtualização podem ajudar com esses problemas. A VMware desenvolveu a interface de máquina virtual para esse propósito e os sistemas operacionais selecionados atualmente oferecem suporte a isso. Uma comparação entre a virtualização completa e a paravirtualização para o ESX Server mostra que, em alguns casos, a paravirtualização é muito mais rápida.

Limitações de rede

Ao usar os recursos de rede avançados e estendidos usando o switch virtual distribuído Cisco Nexus 1000v, as seguintes limitações relacionadas à rede se aplicam:

  • 64 hosts ESX / ESXi por VSM (Virtual Supervisor Module)
  • 2.048 interfaces Ethernet virtuais por VMware vDS (switch distribuído virtual)
  • e um máximo de 216 interfaces virtuais por host ESX / ESXi
  • 2048 VLANs ativas (uma para ser usada para comunicação entre VEMs e VSM)
  • 2048 perfis de portas
  • 32 NICs físicos por host ESX / ESXi (físico)
  • 256 canais de porta por VMware vDS (switch distribuído virtual)
  • e um máximo de 8 canais de porta por host ESX / ESXi

Limitações do tecido Fibre Channel

Independentemente do tipo de adaptador SCSI virtual usado, existem estas limitações:

  • Máximo de 4 adaptadores SCSI virtuais, um dos quais deve ser dedicado ao uso de disco virtual
  • Máximo de 64 LUNs SCSI por adaptador

Veja também

Referências

links externos