Como instalar o VMware Workstation no Ubuntu 22.04 | 20.04

Neste guia, vamos nos concentrar em como instalar o VMware Work Station Pro no Ubuntu 22.04 | 20.04.

VMware Workstation é um hypervisor tipo 2 projetado para sistemas Windows e Linux. Ele permite que você crie e gerencie máquinas virtuais em ambientes Windows ou Linux.

O VMware Workstation é amplamente categorizado em dois produtos: VMware Workstation Player e VMware Workstation Pro .

O VMware Workstation Player é gratuito para uso pessoal, enquanto o VMware Workstation Pro requer uma licença. O primeiro é uma ferramenta não comercial e fornece apenas funcionalidades básicas, enquanto o Workstation Pro é uma solução de virtualização profissional e mais avançada. Ambos rodam em sistemas Linux e Windows e possuem praticamente os mesmos requisitos de instalação. Além disso, ambos rodam em arquitetura baseada em x86 com CPUs Intel e AMD de 64 bits.

1) Baixe o VMware Workstation PRO

O VMware Workstation Player não está oficialmente hospedado nos repositórios Ubuntu 22.04 e 20.04. Para instalar o VMware Workstation no Ubuntu 22.04, visite a página oficial de download do VMWare e baixe o pacote de instalação conforme indicado abaixo.

No momento da redação deste guia, a versão mais recente é o VMware Workstation Pro 16 e o ​​tamanho do download é ligeiramente superior a 500 MB.

O pacote de instalação é baixado na pasta Downloads localizada em seu diretório inicial. Você pode confirmar isso usando o comando ls da seguinte maneira.

$ ls Downloads

2) Instale o VMware Workstation

Antes de iniciar a instalação, vamos primeiro instalar os pré-requisitos usando o comando apt abaixo,

$ sudo apt update
$ sudo apt install -y build-essential

Para instalar o VMware Workstation, execute o seguinte comando bash. Observe que o nome do arquivo de instalação do VMware Workstation será diferente do seu se uma versão mais recente for disponibilizada.

$ sudo bash VMware-Workstation-Full-16.2.4-20089737.x86_64.bundle

O comando extrai o instalador do VMware e instala o VMware em seu sistema. Isso leva cerca de 5 minutos, então seja paciente. No final, você receberá a confirmação de que a instalação foi bem-sucedida.

3) Instale os módulos de kernel adicionais necessários

Para que a estação de trabalho VMware funcione perfeitamente, alguns módulos de kernel adicionais são necessários. Como tal, instale-os da seguinte forma.

$ sudo vmware-modconfig --console --install-all

4) Inicie o VMware Workstation

A etapa final do processo de instalação é iniciar o VMware Workstation e concluir a configuração. Então, clique na aba ‘ Atividades ‘ e depois clique no ícone mostrado abaixo.

A seguinte janela irá aparecer. Certifique-se de ler o Contrato de Licença do Usuário Final e aceitar os termos. Em seguida, clique em ‘ Next’ para prosseguir para a próxima etapa.

Da mesma forma, aceite o próximo conjunto de termos do contrato de licença e clique em ‘ Next’.

Em seguida, você pode optar por verificar se há atualizações ao iniciar o VMware Workstation. Tudo depende de você decidir e, depois de fazer sua escolha, clique em ‘ Next’.

Em seguida, insira uma chave de licença se tiver adquirido o VMware Workstation. Alternativamente, se você não tiver um, pode optar por avaliar o pedido por 30 dias. Depois de fazer sua escolha, clique em ‘ Finish’.

Depois de clicar no botão ‘ Finish’, você será solicitado a autenticar e, portanto, forneça sua senha e clique no botão ‘ Authenticate’.

Por fim, a VMware Workstation será exibida. Clique em ‘ Ok ‘ na janela pop-up que aparece.

A partir daqui, você pode criar e gerenciar suas máquinas virtuais.

Conclusão

Isso encerra este guia sobre como instalar o VMware Workstation no Ubuntu 22.04 e 22.04. Agora você pode aproveitar seus recursos de virtualização para executar e testar seus sistemas operacionais favoritos com facilidade, incluindo Linux, Windows e até variedades UNIX, como BSD. Tudo de bom para você começar a usar o VMware Workstation Pro.

Correção rápida: vSphere with Tanzu – Incapaz de validar contra qualquer política de segurança de pod

• 

I’ve been grappling with vSphere with Tanzu for the past week or so and while I haven’t completely nailed how things operate end to end in this new world, i’ve been able to get to a point beyond the common “kubectl get nodes” which is where plenty of people kicking the tyres get to… and then stop. There also isn’t a lot of straight forward content out there on how to quickly fix issues that come up after the deployment of a Tanzu Kubernetes Grid instance into a fresh namespace. There are kubernetes security and kubernetes storage constructs to deal with and for those not familiar with or new to Kubernetes… it can drive you mad!

Eu tenho lutado com o vSphere with Tanzu na última semana ou então e embora eu não tenha entendido completamente como as coisas funcionam de ponta a ponta neste novo mundo, fui capaz de chegar a um ponto além do comum “kubectl get nós ”que é onde muitas pessoas chutando os pneus vão … e então param. Também não há muito conteúdo direto sobre como corrigir rapidamente os problemas que surgem após a implantação de uma instância do Tanzu Kubernetes Grid em um novo namespace. Existem construções de segurança e armazenamento do Kubernetes para lidar e para aqueles que não estão familiarizados ou são novos no Kubernetes … isso pode deixar você louco!

O problema:

Um dos primeiros problemas que encontrei foi ao tentar implantar pods ou soluções fora do namespace padrão criado como parte da instalação do TKG. Há um monte de coisas para ler aqui em termos de como o Tanzu Kubernetes funciona junto com namespaces internos e como as políticas de segurança de pod são aproveitadas junto com os papéis de cluster e vinculações de papéis que estão associados à política de segurança de pod padrão. As ligações podem ser definidas no nível padrão usando PSPs predefinidos ou podem ser aplicadas no nível do namespace usando PSPs existentes ou personalizados.

Sobre
as políticas de segurança do pod do Kubernetes As políticas de segurança do pod do Kubernetes (PSPs) são recursos no nível do cluster que controlam a segurança dos pods. O uso de PSPs oferece controle sobre os tipos de pods que podem ser implantados e os tipos de contas que podem implantá-los. Um recurso PodSecurityPolicy define um conjunto de condições que um pod deve satisfazer para ser implantado. Se as condições não forem atendidas, o pod não poderá ser implantado. Um único PodSecurityPolicy deve validar um pod em sua totalidade. Um pod não pode ter algumas de suas regras em uma política e outras em outra.

O erro:

Ao procurar implantar soluções ou PODs individuais diretamente da linha de comando kubectl ou usando Helm Charts em um namespace, os objetos eram criados, mas eu estava vendo PODs em um estado pendente e olhando para os eventos dos namespaces estava vendo entradas de eventos como visto abaixo.

1 2 3

LAST SEEN TYPE REASON OBJECT MESSAGE Warning FailedCreate job/kubeapps–internal–apprepository–jobs–cleanup Error creating: pods  “kubeapps-internal-apprepository-jobs-cleanup-“ is forbidden: unable to validate against any pod security policy: [] Warning FailedCreate job/kubeapps–internal–apprepository–jobs–cleanup Error creating: pods “kubeapps-internal-apprepository-jobs-cleanup-“ is forbidden: unable to validate against any pod security policy: []

Basicamente, o usuário não tem direitos no cluster para implantações privilegiadas. Existem algumas maneiras de consertar isso … você pode tentar implantar no namespace padrão, mas se quiser manter as implantações separadas usando namespaces, você precisa configurar e anexar algumas políticas. Há claramente uma razão para que esses PSPs estejam em vigor dentro do cluster do Kubernetes em uma implantação do Tanzu. O usuário autenticado obtém direitos de edição ou visualização controlados no nível de namespace do vSphere, mas dentro do cluster TKG também há um conjunto de políticas que precisam ser consideradas para fazer as coisas.

O conserto: 

A correção a seguir é basicamente como conceder ALLOW ANY ANY em um firewall (embora qualquer dano possível seja autocontido dentro da implantação específica do TKG) e para aqueles que desejam mergulhar um pouco mais nas implantações do Kubernetes, esta é a maneira rápida de criar um novo PSP e começar a implantar aplicativos em contêineres.

Observação : estou documentando essa correção como uma solução alternativa para fins de teste. Este artigopode ajudá-lo a configurar as coisas de uma maneira mais rígida, do jeito VMware Kubernetes Tanzu. Você pode aplicar um ClusterRoleBinding que aplica “vmware-system-privileged” ao usuário conectado.

Crie e aplique uma nova Política de Segurança de Pod (PSP)

	apiVersion: policy/v1beta1
	kind: PodSecurityPolicy
	metadata:
	name: kubeapps-psp
	spec:
	privileged: true
	seLinux:
	rule: RunAsAny
	supplementalGroups:
	rule: RunAsAny
	runAsUser:
	rule: RunAsAny
	fsGroup:
	rule: RunAsAny
	volumes:
	– ‘*‘

view raw
justwork-psp.yaml
hosted with ❤ by GitHub

Crie e aplique uma nova função de cluster vinculada ao novo PSP

	kind: ClusterRole
	apiVersion: rbac.authorization.k8s.io/v1
	metadata:
	name: kubeapps-clusterrole
	rules:
	– apiGroups:
	– policy
	resources:
	– podsecuritypolicies
	verbs:
	– use
	resourceNames:
	– kubeapps-psp

view raw
justwork-clusterrole.yaml
hosted with ❤ by GitHub

Vincule a função de cluster a uma conta de serviço associada a um namespace

	apiVersion: rbac.authorization.k8s.io/v1
	kind: RoleBinding
	metadata:
	name: kubeapps-clusterrole
	namespace: kubeapps
	roleRef:
	apiGroup: rbac.authorization.k8s.io
	kind: ClusterRole
	name: kubeapps-clusterrole
	subjects:
	– apiGroup: rbac.authorization.k8s.io
	kind: Group
	name: system:serviceaccounts
	– kind: ServiceAccount # Omit apiGroup
	name: default
	namespace: kubeapps

view raw
justwork-rolebinding.yaml
hosted with ❤ by GitHub

Use kubectl para aplicar os novos papéis e associações.

No meu exemplo acima, onde eu estava observando os eventos, assim que apliquei o novo PSP, Cluster Role e RoleBinding, as tarefas pendentes / com falha foram concluídas.

1 2 3 4 5 6 7 8 9

[root@ANSIBLE–01 bin]# kubectl get events -n kubeapps -w LAST SEEN TYPE REASON OBJECT MESSAGE 28s Normal Scheduled pod/kubeapps–internal–apprepository–jobs–cleanup–n4dbz Successfully assigned kubeapps/kubeapps–internal–apprepository–jobs–cleanup–n4dbz to tkg–cluster–001–workers–qcqqz–86b999cc5c–q7gz2 28s Normal Pulling pod/kubeapps–internal–apprepository–jobs–cleanup–n4dbz Pulling image “docker.io/bitnami/kubectl:1.18.9-debian-10-r5” 15s Normal Pulled pod/kubeapps–internal–apprepository–jobs–cleanup–n4dbz Successfully pulled image “docker.io/bitnami/kubectl:1.18.9-debian-10-r5” 14s Normal Created pod/kubeapps–internal–apprepository–jobs–cleanup–n4dbz Created container kubectl 14s Normal Started pod/kubeapps–internal–apprepository–jobs–cleanup–n4dbz Started container kubectl 28s Normal SuccessfulCreate job/kubeapps–internal–apprepository–jobs–cleanup Created pod: kubeapps–internal–apprepository–jobs–cleanup–n4dbz 05s Normal Completed job/kubeapps–internal–apprepository–jobs–cleanup Job completed

Desse ponto em diante, qualquer nova implantação direta ou via Helm não teve problemas.

Referências:

https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-152BE7D2-E227-4DAA-B527-557B564D9718.html

https://cloud.google.com/kubernetes-engine/docs/how-to/pod-security-policies

https://core.vmware.com/resource/vsphere-tanzu-quick-start-guide

pod s implantação de kubernetes política de segurança de kubernetes pod

Migrando sua máquina virtual para o Amazon EC2 usando o AWS Connector for vCenter

Você pode iniciar uma instância do EC2 a partir de uma máquina virtual que migra do VMware vCenter para o Amazon EC2. Você usará o AWS Connector for vCenter para migrar suas máquinas virtuais para o Amazon EC2.

O diagrama a seguir ilustra o processo de migração. Quando você solicita uma migração, criamos uma tarefa de conversão. Quando a tarefa de conversão é concluída com êxito, sua instância importada fica disponível.

Para migrar do vCenter 6.5, para especificar o tipo de licença BYOL durante a migração ou para usar a migração incremental, use o Serviço de Migração de Servidores da AWS. Para obter mais informações, consulte o  AWS SMS User Guide.

Nota

Recomendamos o uso do SMS (Serviço de Migração de Servidor) da AWS para migrar VMs de um ambiente do vCenter para a AWS. O SMS automatiza o processo de migração, replicando VMs locais de maneira incremental e convertendo-as em AMIs (Amazon Machine Images). Você pode continuar usando suas VMs locais enquanto a migração estiver em andamento. Para obter mais informações sobre o AWS SMS, consulte AWS Server Migration Service.

Conteúdo

• Prerequisites
• Limitations
• VM Import Authorization
• Migrating Your Virtual Machine
• Backing Up Your Instance
• Exporting a Migrated EC2 Instance
• Troubleshooting Migration

Pré-requisitos

• Um administrador deve instalar e configurar o conector. O conector faz parte do AWS Management Portal for vCenter. Para obter mais informações, consulte Setting Up AWS Management Portal for vCenter.
• Um administrador deve criar pelo menos um ambiente e conceder permissão para migrar uma máquina virtual para um ou mais ambientes. Esse ambiente é um complemento ao ambiente padrão e deve ser criado explicitamente. Para mais informações, consulte Managing Environments.
• Certifique-se de que sua VM use um dos sistemas operacionais suportados e de selecionar um dos tipos de instância suportados. Para obter mais informações, consulte  VM Import/Export Prerequisites de VMs no Amazon EC2 User Guide.
• Anexe a política VMImportExportRoleForAWSConnector à função vmimport criada por função de VM Import Service Role no Amazon EC2 User Guide.
• Verifique se a sua VM não possui um disco cujo tamanho compactado seja maior que 215 GB.

Limitações

• Consulte VM Import/Export Requirements and Limitations no Guia do usuário do Amazon EC2.
• O Amazon EC2 limita o número de migrações ativas para 5 por região. Se o conector já estiver no processo de migração de 4 máquinas virtuais, ele enfileirará todas as tarefas de migração adicionais até que uma das tarefas de migração ativas seja concluída com êxito ou cancelada.

Autorização de importação de VM

Seus usuários não têm acesso direto à AWS. O diagrama a seguir descreve o processo pelo qual um usuário pode migrar uma VM para o Amazon EC2.

1. O cliente vSphere autoriza a importação para o ambiente.
2. O portal de gerenciamento verifica se o usuário tem permissão para migrar VMs para o ambiente e retorna um token.
3. O cliente vSphere envia uma solicitação de importação ao conector junto com o token.
4. O conector verifica o token.
5. O conector verifica se o usuário tem permissão para exportar a VM.
6. O conector inicia a migração.
7. O conector envia uma resposta ao cliente vSphere com o ID da tarefa de importação.

Migrando sua máquina virtual

Para migrar uma VM para o Amazon EC2, use o vCenter com o conector. O conector pode migrar até quatro VMs simultaneamente.

Atenção

Você não pode criar uma tarefa de migração enquanto o conector estiver atualizando.

Para migrar sua máquina virtual para o Amazon EC2

1. No vCenter, clique em Home  e clique em VMs and Templates.
2. Selecione a VM.
3. Clique com o botão direito do mouse na VM e clique em Migrate VM to EC2. Se o seu administrador não lhe concedeu permissão para migrar VMs, você verá uma mensagem solicitando ao administrador que lhe conceda permissão.
4. Preencha o formulário da seguinte maneira:
   1. Selecione o sistema operacional em execução na VM.
   2. Selecione a região e o ambiente para a instância EC2 resultante. A lista de ambientes contém apenas os ambientes aos quais o administrador concedeu permissão.
   3. Selecione uma sub-rede, tipo de instância e grupo de segurança para a instância.
   4. (Opcional) Digite um endereço IP privado. Se você não especificar um endereço IP privado, selecionaremos um para você.
   5. Selecione um grupo de segurança. A lista de grupos de segurança contém apenas os grupos de segurança associados ao ambiente que você selecionou.
   6. Clique em Begin migration to Amazon EC2.
   7. [Antes do conector 2.4.0] Se o conector exibir um aviso de que já existem quatro tarefas de migração ativas e que isso afetará a velocidade dessas tarefas, você poderá continuar ou cancelar a tarefa de migração.
5. Após o início da migração, exibiremos o ID da tarefa de importação se a tarefa de migração for iniciada imediatamente ou o ID da tarefa na fila, caso contrário. Anote o ID se desejar monitorar a tarefa de migração. Caso contrário, você poderá fechar a janela de importação e seu cliente vSphere depois que o conector notificar que a tarefa de importação foi criada ou enfileirada e a migração continuará.
6. (Opcional) Para monitorar o status da migração, faça o seguinte:
   1. No vCenter, clique emHome e, em seguida, clique em AWS Management Portal.
   2.  Expanda a região da instância, selecione o ambiente e clique na guia VM-to-EC2 Migrations.
   3. Localize a entrada com o ID da tarefa de importação ou o ID da tarefa na fila que você anotou anteriormente. O ID da instância é mostrado no campo Instance ID.
7. Para iniciar a instância do EC2 após a conclusão da migração, expanda o ambiente, expanda Imported Instances, selecione a instância e clique em Summary. O ID da instância deve ser o ID da instância que você anotou na guia VM-to-EC2 Migrations. Na guia Getting Started, clique em Start instance.

Fazendo backup de sua instância

Depois de iniciar uma instância, ela é executada até ser finalizada. Se sua instância for encerrada, você não poderá se conectar ou recuperar a instância. Para garantir que você possa iniciar uma nova instância com o mesmo software que uma instância migrada, se necessário, crie uma Amazon Machine Image (AMI) a partir da instância e crie um modelo que especifique a AMI.

Para criar uma AMI, você deve usar o console do Amazon EC2 ou as ferramentas de linha de comando. Para obter informações sobre como criar uma AMI usando o Amazon EC2, consulte os seguintes tópicos no Amazon EC2 User Guide.

Plataforma	Root Volume	Tópico
Linux	EBS	Creating an Amazon EBS-Backed Linux AMI
Linux	instance store	Creating an Instance Store-Backed Linux AMI
Windows	EBS	Creating an Amazon EBS-Backed Windows AMI
Windows	instance store	Creating an Instance Store-Backed Windows AMI

Para obter informações sobre como criar um modelo para poder iniciar instâncias da AMI criada a partir da instância migrada, consulte  Managing Templates.

Exportando uma Instância EC2 Migrada

Para exportar uma instância do EC2 que você migrou anteriormente de uma VM, use o portal de gerenciamento no vCenter. O processo para exportar uma instância cria um arquivo OVA e o armazena em um bucket do Amazon S3 na sua conta da AWS.

Se você não exportou anteriormente uma instância do EC2 usando o vCenter, primeiro especifique o nome que usaremos para os buckets S3 que criamos para exportação da instância. A AWS cria um bucket S3 em cada região para esse fim, com um nome que segue o formato export-to-s3-name-region.

Exigências

• Você deve ser um administrador do portal de gerenciamento para exportar uma instância do EC2.
• Você pode configurar a exportação da instância usando as credenciais da AWS de um administrador ou de um usuário do IAM. Para permitir que um usuário do IAM conclua essas etapas, verifique se o usuário possui as permissões descritas em Creating the Required Accounts and Users.

Limites

• Há um limite de cinco tarefas de exportação simultâneas por região.
• Você não pode exportar uma instância que está sendo exportada no momento.

Para preparar, por exemplo, exportação

1. Abra o console de configuração do AWS Management Portal for vCenter.
2. Na página AWS Management Portal for vCenter, clique em  Configure Instance Export e, em seguida, clique em Create New.
3. Na página Configure Instance Export, faça o seguinte:
   1. Preencha o nome do bloco nos S3 bucket names, conforme solicitado.
   2. Clique em I agree that AWS Management Portal for vCenter may do the following on my behalf.
   3. Clique em Create.

Para exportar uma instância migrada

1. No vCenter, clique em Home e, em seguida, clique em AWS Management Portal.
2. No painel, expanda a região, o ambiente e o modelo para a instância.
3. Selecione a instância.
4. Na Getting Started, clique em Export instance to S3.
5. Na caixa de diálogo Export instance to S3, digite um nome para o arquivo OVA no S3 object file prefix e clique em Export.

   Após o início da exportação, exibimos o ID da tarefa de exportação. Anote esse ID se desejar monitorar o status da tarefa de exportação.

6. (Opcional) Para monitorar o status do processo de exportação, selecione o ambiente para a instância e clique na guia EC2-to-S3 Migrations. Essa guia exibe todas as tarefas de exportação da instância dos últimos sete dias. Localize a tarefa com o ID da tarefa de exportação que você anotou anteriormente. Se você precisar cancelar a tarefa de exportação enquanto estiver em andamento, clique com o botão direito do mouse na linha, clique em Cancel Export Task e clique em Continue quando solicitado a confirmação.
7. Para acessar o arquivo OVA após a conclusão do processo de exportação, faça o seguinte:
   1. Abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.
   2. Na barra de navegação, selecione a região que contém a instância do EC2 que você exportou. O arquivo OVA é armazenado em um bucket S3 na mesma região que a instância do EC2.
   3. No painel Buckets , selecione o bucket para suas instâncias exportadas (export-to-s3-name-region) e selecione o arquivo OVA.
   4. Clique em Actions  e, em seguida, clique em Download. Siga as instruções para concluir o download.

Como alternativa, você pode exportar uma instância do EC2 usando a CLI do Amazon EC2 em vez de usar o conector. Para obter mais informações, consulte Exportando instâncias do Amazon EC2 no Guia do usuário do Amazon EC2.

Solução de problemas de migração

Error: Additional permissions are required to migrate multidisk virtual machines “Erro: são necessárias permissões adicionais para migrar máquinas virtuais multidisco”

Ao migrar uma máquina virtual, você recebe o erro “Para migrar uma máquina virtual com mais de um disco, faça login na página de configuração do portal de gerenciamento e conceda as permissões adicionais exigidas pelo serviço de Importação / Exportação da VM”.

Use o procedimento a seguir para conceder as permissões necessárias:

1. Abra o console de configuração do AWS Management Portal for vCenter.
2. Se você vir uma mensagem de erro indicando que sua função de serviço de Importação está ausente, clique em Fix Error.
3. (Opcional) Clique em View Policy para revisar a política da função de serviço de importação.
4. Clique em I agree that AWS Management Portal for vCenter may create the above roles on my behalf.
5. Clique em Save.

Error: Connector is unable to reach ESX host “Erro: o conector não consegue acessar o host ESX”

Você recebe o seguinte erro ao migrar uma máquina virtual: “O conector não pode acessar o host ESX [nome do host] para migrar a máquina virtual [nome]”.

Se o nome do host especificado na mensagem de erro não for o nome de domínio completo de um host ESX, use o procedimento a seguir para configurar a lista de pesquisa de sufixos DNS para que o conector possa anexar o sufixo e resolver o nome do host ESX:

1. Localize a VM do conector no cliente vSphere, clique com o botão direito do mouse e selecione Open Console.
2. Efetue login como usuário ec2. Para obter mais informações, consulte Fazendo login no console da máquina virtual.
3. Execute o comando sudo setup.rb. Este comando exibe o seguinte menu:

   Choose one of the following options
   1. Reset password
   2. Reconfigure network settings
   3. Restart services
   4. Factory reset
   5. Delete unused upgrade-related files
   6. Enable/disable SSL certificate validation
   7. Display connector's SSL certificate
   8. Generate log bundle
   9. Exit
   Please enter your option [1-9]:

4. Digite 2 e pressione Enter. O comando exibe o seguinte menu:

   Reconfigure your network:
   1. Renew or acquire a DHCP lease
   2. Set up a static IP
   3. Set up a web proxy for AWS communication
   4. Set up a DNS suffix search list
   5. Exit
   Please enter your option [1-5]:

5. Digite 4e pressione Enter. O comando exibe a lista de pesquisa de sufixo DNS atual. Siga as instruções para atualizar a lista de pesquisa para incluir o nome de domínio do host ESX na mensagem de erro.

O conector não pode validar os certificados do host

Por padrão, o conector valida os certificados de todas as entidades com as quais se comunica por HTTPS, incluindo os servidores vCenter e ESXi. Isso é essencial para evitar ataques man-in-the-middle. No entanto, se você estiver migrando uma máquina virtual do ESX versão 4.1 ou anterior para o Amazon EC2, o conector não poderá validar os certificados do host, portanto, a migração falhará.

Para contornar esse problema, você pode seguir um destes procedimentos:

• Option 1: Atualize para o ESX 5.0 ou posterior..
• Option 2: Desative a validação de certificado ESX, migre a máquina virtual e reative a validação de certificado ESX da seguinte maneira:
  1. No navegador da web, abra o console de gerenciamento do conector (https: // endereço_ip / /, em que endereço_ip é o endereço IP do console de gerenciamento) e efetue login usando sua senha.
  2. Clique em Register the Connector.
  3. Na página Register Plugin, em ESX SSL certificate options, clique em Ignore any ESX certificate errors e clique em Register.

      

     Importante

     Recomendamos que você mantenha a validação do certificado ESX ativada, a menos que esteja migrando máquinas virtuais do ESX 4.1 ou anterior.

  4. Quando terminar de migrar a máquina virtual, retorne à página Plugin de registro do console de gerenciamento de conectores, clique em Trust vCenter para validar ESX certificates e clique em Register.

Dicas de desempenho do VMware ESXi

Vamos dar uma olhada em algumas dicas de desempenho para um hardware que executa o VMware ESXi. Ao instalar o hypervisor ESXi em um hardware novo (ou mais antigo), é preciso pensar em como obter o melhor desempenho possível, pois o sistema executará muitas máquinas virtuais (VMs) e precisará ser ajustado para o desempenho.

Além do aviso de que você deve usar apenas hardware compatível com VMware, que é normal, pois o hardware que não está na HCL ou está um pouco desatualizado pode não ser capaz de executar o hypervisor ESXi mais recente. Se for esse o caso, não se preocupe. Você ainda pode tentar instalar a versão mais antiga do ESXi e ainda usá-la para algumas cargas de trabalho não críticas, como monitoramento de infraestrutura ou hospedar algumas cargas de trabalho que não são críticas para os negócios.

Para o cluster de produção, você deve usar apenas um hardware certificado pela VMware, que pode ser encontrado na página VMware HCL . Todos os componentes do servidor, como controlador de armazenamento, placas de interface de rede (NICs) ou CPU, devem figurar na HCL.

Configurações do BIOS

A primeira coisa a se observar ao configurar um sistema é o BIOS da máquina. Você deve configurá-lo no modo “desempenho” e não no modo “equilibrado” referente ao estado da CPU.

Outra coisa é o hardware não utilizado. Pode haver algumas portas COM, portas LPT, controladores USB, unidades de disquete, unidades de disco óptico, NICs ou controladores de armazenamento que você não usará. Afinal, o servidor foi criado para ser compatível com vários sistemas operacionais diferentes, mas a camada de virtualização do VMware fornece todas as VMs necessárias como hardware virtual.

Portanto, depois de instalar o ESXi, você poderá voltar ao BIOS e desativar completamente as portas USB. Os modos de economia de energia também devem ser desativados.

Além disso, quando você estiver no BIOS, observe as configurações de hyperthreading que devem ser habilitadas, bem como VT-x, AMD-V, EPT, RVI etc. Essas são extensões de virtualização de hardware para CPUs x86.

Usar configurações de alto desempenho

Configuração de armazenamento

Um tópico vasto e enormes possibilidades de melhorias. Se você se preocupa com o desempenho, use o All-Flash. O desempenho do armazenamento depende da carga de trabalho, hardware, fornecedor, nível RAID, tamanho do cache, tamanho da faixa e assim por diante.

Você deve verificar a documentação da VMware e do fornecedor de armazenamento para obter dicas relacionadas ao hardware específico que planeja usar. Muitas cargas de trabalho são muito sensíveis à latência das operações de E / S.

A menos que o ESXi use armazenamento local, é um desempenho da rede de armazenamento que pode ser importante. Normalmente, o ESXi é “conectado” a uma matriz de armazenamento externo por iSCSI ou NFS ou por meio de uma conectividade Fibre Channel, para que os discos locais não sejam usados ​​para cargas de trabalho. O armazenamento local geralmente é usado para a instalação local do ESXi se o hipervisor não estiver instalado em um pendrive ou em um SATADOM.

Se você estiver selecionando a matriz de armazenamento (nova ou antiga), considere escolher o hardware de armazenamento que suporta APIs do VMware vStorage para integração de matriz (VAAI). Isso permite que algumas operações sejam transferidas para o hardware de armazenamento em vez de serem executadas no ESXi.

O VAAI pode melhorar a escalabilidade de armazenamento, reduzir a latência de armazenamento para vários tipos de operações de armazenamento, reduzir a utilização da CPU do host ESXi para operações de armazenamento e reduzir o tráfego da rede de armazenamento. Quando você clona,

Nota: O StarWind Virtual SAN possui o VAAI como um dos recursos de armazenamento. O suporte VAAI permite ao StarWind descarregar várias operações de armazenamento dos hosts VMware para o próprio storage array.

Algumas dicas de rede

Convém usar NICs de classe de servidor que suportem descarregamento de soma de verificação, descarregamento de segmentação TCP e a capacidade de lidar com endereços DMA de 64 bits e quadros de tamanho jumbo. Esses recursos permitirão que o vSphere faça uso de seu suporte avançado de rede integrado.

Para configuração no vSphere, você pode tirar proveito de algumas práticas recomendadas do VMware, pois eles publicaram muitos whitepapers sobre este tópico. Apenas alguns exemplos que devem ser aplicados após a instalação. Uma delas é a equipe da NIC, na qual você pode configurar uma ordem de failover e se beneficiar de um plano inteligente de recuperação de desastres que alterna automaticamente a NIC com falha para uma que esteja funcionando.

A equipe da NIC pode compartilhar a carga de tráfego entre redes físicas e virtuais entre todos os seus membros (ou apenas alguns) e também fornecer um failover passivo no caso de uma falha de hardware ou falta de rede.

A equipe da NIC pode garantir redundância e balancear a carga do tráfego. A configuração é possível de quatro maneiras diferentes (rota baseada na porta virtual de origem, rota baseada no hash IP, rota baseada no hash MAC de origem ou usar ordem explícita de failover). Convido você a ler o white paper detalhado da VMware chamado

Otimização de VM – usar o VMXNET3 como adaptadores virtuais para suas VMs reduzirá a sobrecarga necessária para o tráfego de rede passar entre as máquinas virtuais e a rede física. Você pode se surpreender se verificar algumas de suas VMs mais antigas e ver quais tipos de adaptadores estão usando. Talvez você encontre alguns adaptadores E1000, E1000e, VMXNET ou VMXNET 2 que são antigos e antigos.

DICA: você pode usar uma ferramenta perfeita para verificar sua infraestrutura virtual com ferramentas de RV e verificar qual das suas VMs ainda possui um tipo de NIC antigo.

O VSAN da StarWind elimina qualquer necessidade de armazenamento compartilhado físico apenas espelhando os recursos internos de flash e armazenamento entre os servidores hypervisor. Além disso, a solução pode ser executada no hardware de prateleira. Esse design permite que o VSAN da StarWind alcance não apenas alto desempenho e utilização eficiente de hardware, mas também reduza as despesas operacionais e de capital.

Substituir hardware antigo

O hardware antigo geralmente consome muita energia e não possui desempenho suficiente para lidar com as cargas de trabalho atuais. Portanto, é importante planejar e substituir o hardware antigo.

Muitas vezes os administradores tentam otimizar sua infraestrutura e software e, geralmente, o hardware atingiu seus limites.

O novo hardware do servidor geralmente fornece CPUs com vários núcleos (8, 16 ou 32 núcleos por CPU) com muita RAM. Não é incomum encontrar 256 Gb, 512 Gb ou até 1 TB de RAM.

A RAM física é o primeiro recurso que geralmente atinge o limite e somente após o início das técnicas de otimização de memória do VMware. Geralmente, centenas de VMs configuradas com muita vRAM podem ser executadas na parte superior de um sistema com muita RAM física. Não há limite na RAM física e na licença VMware.

Quando se trata de escolher uma CPU, essa pode ser uma história diferente com as mais recentes CPUs da AMD. Parece que a AMD está realmente voltando à corrida e oferece uma alternativa muito boa aos caros processadores Xeon. De fato, sua série EPYC 7002 estabeleceu novos recordes mundiais com o software de marca VMware VM. Você pode ler mais detalhes aqui .

Palavras finais

Poderíamos escrever mais sobre dicas de otimização para o VMware ESXi e há muitos tópicos que podem ser abordados. Hardware, rede e armazenamento são os mais importantes, pois formam a camada base onde as cargas de trabalho são executadas. Outro tópico de otimização poderia ser a própria infraestrutura virtual. Como configurar VMs, com quais opções, quantas vCPUs ou quanto vRAM etc. Mas podemos salvar isso na próxima vez.

Recurso De Captura De Código No VSphere 6.7

A VMware introduziu o Developer Center e o Code Capture com o lançamento do vCenter Server Appliance (VCSA) 6.7 U2 e está disponível em todos os novos lançamentos. Nesta postagem, veremos o recurso de captura de código do Developer Center disponível na versão mais recente do vSphere 6.7.

O Developer Center é um ponto de entrada único para desenvolvedores que fornece ferramentas para gerenciar a estrutura da API e capturar ações do usuário para convertê-las em código executável. Além disso, o vSphere Client Developer Center fornece ferramentas para especialistas em automação, engenheiros de DevOps e desenvolvedores para encontrar os recursos para gerenciar estruturas de API e capturar ações do vSphere Client para convertê-las em PowerCLI.

Captura de código

O Code Capture oferece a capacidade de registrar ações executadas no vSphere Client e produzi-las como código PowerCLI utilizável. E você pode facilmente copiar o código ou baixá-lo como um script e usá-lo em uma sessão do PowerShell para executar a tarefa. Esse recurso está disponível apenas no HTML5 vSphere Client e, para usá-lo, você deve habilitá-lo primeiro.

O Code Capture registra ações do usuário e as converte em código executável. Isso ajudará administradores e engenheiros a analisar e reutilizar as ações por meio do PowerCLI. E observe que apenas as chamadas do vCenter Server são gravadas. As chamadas feitas em operações relacionadas a funções, privilégios, tags, bibliotecas de conteúdo e políticas de armazenamento não são registradas.

Ativar captura de código

Você pode ativar a captura de código seguindo o procedimento abaixo

• Navegue para o menu e clique em Developer Center

• Selecionar captura de código

• Clique na alternância para ativar a Captura de código.

Você pode iniciar a gravação usando o botão vermelho de gravação no painel superior e enquanto uma gravação está em andamento, o botão vermelho de gravação no painel superior pisca.

Navegue até o painel desejado e clique no botão vermelho de gravação para iniciar a gravação. Estamos testando esse recurso executando o clone da máquina virtual e ligando.

Navegue para o Developer Center e você pode ver a única opção disponível é PARAR GRAVAÇÃO, pois a gravação está em andamento

Após a conclusão do processo, você pode verificar se a VM está em execução e interromper a gravação. E o código das operações que realizamos que está clonando a VM e o Power on é visível lá.

E há três outras opções disponíveis e a opção STOP RECORDING fica acinzentada após a interrupção do processo de gravação.

LIMPAR E INICIAR OUTRO: – Esta opção limpará o código capturado em uma sessão anterior e iniciará uma nova sessão

Você precisa selecionar a opção LIMPAR E REINICIAR na mensagem pop-up para continuar

COPIAR: – Esta opção copiará o código e você poderá colar em qualquer bloco de notas ou em qualquer outro aplicativo adequado para salvá-lo no formato PowerCLI e utilizá-lo para fins futuros.

DOWNLOAD: – Esta opção fará o download do código como um script PowerCLI

Você pode abrir no aplicativo PowerShell e verificar o código

Desativar captura de código

Você pode desativar o recurso clicando em alternar para ativar novamente na opção Captura de código. Se você desativar o Code Capture, uma mensagem pop-up aparecerá: “Desativar o Code Capture limpará as ações registradas na sessão atual e ocultará o Code Capture no cabeçalho de navegação”. Portanto, certifique-se de copiar ou baixar o código antes de continuar com esta operação.

Conclusão

O recurso Developer Center com Code Capture é muito útil para administradores e engenheiros da VMware para automatizar tarefas diferentes no ambiente do vSphere. O recurso permitirá que você “capture” as tarefas da interface do usuário executadas na interface no código do PowerCLI e copie o código ou faça o download como um script e use-o em uma sessão do PowerShell para executar as tarefas.

Dicas e truques do VMware DRS

O DRS (Distributed Resource Scheduler) do VMware é um sistema que permite equilibrar automaticamente suas máquinas virtuais (VMs) em um ambiente de cluster do VMware vSphere. Nesta postagem, revisaremos algumas dicas e truques do VMware DRS para planejar, configurar e usar o vSphere DRS.

 

Um cluster balanceado significa que seus hosts em um cluster serão igualmente (ou quase) balanceados. Se seu cluster estiver desequilibrado, suas VMs serão automaticamente migradas a quente via vMotion para os hosts com a menor utilização de recursos. Por exemplo, se você tiver DRS em seu ambiente, não deverá ver um host sendo usado em 99% e outro em 50%.

O DRS cuida do balanceamento das VMs via vMotion. Nesta postagem, daremos algumas dicas que permitirão tirar o máximo proveito do VMware DRS e fazer com que essa tecnologia valha o investimento.

O VMware DRS não faz parte do vSphere Standard e está incluído apenas nas versões Enterprise Plus ou Platinum. É sempre uma questão de optar por uma versão do vSphere que tenha DRS ou não. Se eu tivesse a chance de escolher, certamente preferiria a opção de licenciamento com o VMware DRS.

Para lhe dar uma idéia do que é necessário, vamos começar com o básico. O DRS (VMware vSphere Distributed Resources Scheduler) requer o seguinte:

• Servidor VMware vCenter
• Cluster do VMware vSphere ESXi
• Rede vMotion ativada em hosts de cluster
• Licenciamento Enterprise Plus (ou superior)
• Armazenamento compartilhado entre hosts ESXi (tradicional ou hiperconvergente via VMware VSAN)
• Se você usar DRS preditivo, também precisará executar o vRealize Operations Manager (vROPs), incluindo sua licença.

Dicas do VMware DRS 

Use hardware homogêneo – A primeira dica diz respeito ao hardware ao formar seus clusters. A regra geral do VMware é escolher hosts com o mesmo hardware ou muito semelhante.

Há uma razão para isso. Ao decidir quais hosts agrupar em clusters DRS, tente escolher hosts o mais homogêneos possível em termos de CPU e memória. Isso melhora a previsibilidade e a estabilidade do desempenho.

Velocidade DRS e menor utilização de recursos – Atualize para a versão mais recente do vSphere. O vSphere mais recente, 6.7, é muito mais eficiente no que diz respeito à velocidade do DRS e à utilização de recursos.

Embora a velocidade do vMotion em si não possa ser mais rápida, porque depende da arquitetura subjacente de rede e armazenamento, a VMware conseguiu otimizar a velocidade da tomada de decisões antes que o vMotion aconteça.

De fato, eles alcançaram uma capacidade de tomada de decisão 2-3 vezes mais rápida no vSphere 6.7. Uma das melhorias foi o posicionamento inicial simplificado, que agora no vSphere 6.7 não captura instantaneamente todo o ambiente, mas utiliza apenas o monitoramento contínuo, permitindo que sejam salvos 1 a 2 segundos antes de cada decisão ser tomada.

Isso é especialmente valioso em ambientes de alta consolidação, nos quais você verá um consumo reduzido de recursos devido a aprimoramentos do DRS e latência reduzida para gerar VMotions para balanceamento de carga. Você também verá um posicionamento inicial mais rápido das VMs.

Use o modo Totalmente Automático – O nível de Automação DRS pode ser definido como Manual, Parcialmente Automatizado ou Totalmente Automatizado. Qual é a diferença?

Vamos explicar:

• Manual – O vCenter recomendará apenas a movimentação de recursos.
• Parcialmente automatizado – Depois de criar uma VM e ativá-la, o vCenter colocará a VM automaticamente no melhor host para manter seu cluster em equilíbrio. Depois que a VM for ligada, o vCenter apresentará uma recomendação de migração, levando em consideração o consumo de CPU e memória. O administrador do vSphere precisará aprovar a migração.
• Totalmente automatizado – o vCenter controla o posicionamento inicial e as migrações da VM. Tudo é totalmente automático e o administrador não vê nenhuma mensagem sobre recomendações. Nenhuma decisão do administrador é necessária para manter o cluster equilibrado.

vSphere DRS no modo totalmente automatizado

Por padrão, quando você habilita o DRS em um cluster, o nível de automação selecionado no nível do cluster é aplicável a todas as VMs que residem nesse cluster. No entanto, você pode criar regras individuais para VMs que precisam ser separadas (ou mantidas juntas).

Limite de migração – Esta opção permite definir um limite que, quando atingido, faz com que o DRS entre em ação e mova as VMs para obter um estado perfeitamente equilibrado. Como o desempenho de cada VM varia, o uso da CPU e da memória do host também varia.

Você pode mover o controle deslizante de limite para usar uma das cinco configurações, variando de Conservador a Agressivo. As cinco configurações de migração geram recomendações com base no nível de prioridade atribuído.

Conforme você move o controle deslizante para a direita, cada configuração permite a inclusão de um nível mais baixo de prioridade. A configuração Conservadora gera apenas recomendações de prioridade um (recomendações obrigatórias), o próximo nível à direita gera recomendações de prioridade dois e superiores, e assim por diante, até o nível Agressivo, que gera recomendações de prioridade cinco e superiores (ou seja, todas as recomendações).

Para fazer isso, selecione seu Cluster> Configure > vSphere DRS> Edit > O controle deslizante permite mover da posição Conservative (esquerda) para Aggressive (direita).

Definir o limite de migração DRS no vSphere 6.7

Você deve determinar o quão agressiva ou conservadora deseja que o DRS seja executado. Eu costumo mantê-lo no meio, porque se você for muito agressivo, provavelmente estará movendo suas VMs com bastante frequência. E lembre-se de que, a cada movimento, você cria pressão na infraestrutura subjacente, como armazenamento ou uso da CPU. Isso ocorre porque as operações de cópia durante o vMotion podem saturar os links de rede e, se você não tiver 10GbE (ou mais), as operações do vMotion serão intermináveis.

Se você deixar a configuração muito baixa (muito conservadora), suas VMs não se moverão o suficiente e o desequilíbrio do cluster aumentará ou ocorrerá com mais frequência, sem ser corrigido.

Desligue as VMs que você não usa – Deixe LIGADO apenas as VMs que você realmente precisa. As VMs ativadas consomem recursos de memória e normalmente consomem alguns recursos da CPU, mesmo quando ociosos.

Mesmo VMs ociosas com sua pequena utilização de recursos podem afetar as decisões de DRS. Você pode obter um pequeno aumento de desempenho desligando ou suspendendo VMs que não estão sendo usadas.

Regras de afinidade do DRS – as regras de afinidade do DRS podem manter duas ou mais máquinas virtuais no mesmo host ESXi (“afinidade VM / VM”) ou, por outro lado, podem garantir que estejam sempre em hosts diferentes (“VM / VM anti-afinidade “).

As regras de afinidade do DRS também podem ser usadas para garantir que um grupo de máquinas virtuais seja executado apenas em um grupo específico de hosts ESXi (“afinidade de VM / host”) ou nunca seja executado em um grupo específico de hosts (“anti-afinidade de VM / host” )

Geralmente, é melhor deixar as configurações de afinidade inalteradas. Em alguns casos específicos e raros, no entanto, especificar regras de afinidade pode ajudar a melhorar o desempenho.

Para alterar as configurações de afinidade: selecione um cluster> Configure > VM/Host Rules > Add , digite um nome para a nova regra, escolha um tipo de regra e continue com a GUI conforme apropriado para o tipo de regra selecionado.

Criar regra VM: host

Além da configuração padrão, os tipos de configuração de afinidade são:

Manter máquinas virtuais juntas – esse tipo de afinidade pode melhorar o desempenho devido a latências mais baixas de comunicação entre máquinas.

Máquinas virtuais separadas – esse tipo de afinidade pode manter a disponibilidade máxima das VMs. Por exemplo, se ambos são front-ends de servidores da Web para o mesmo aplicativo, convém garantir que eles não sejam afetados pela falha do servidor (se isso acontecer). Portanto, essas duas VMs não seriam desligadas ao mesmo tempo. Isso também pode manter dois controladores de domínio separados em dois hosts diferentes, para que os usuários possam ser autenticados e acessar recursos.

Máquinas virtuais para hosts – Esses tipos de afinidade podem ser úteis para clusters com restrições de licenciamento de software ou requisitos específicos da zona de disponibilidade.

Notas finais 

Como você pode ver, o VMware vSphere DRS é adaptável a muitos cenários. As configurações padrão funcionam imediatamente, mas você tem muitas opções para adaptá-lo ao seu ambiente, se necessário.

Ao entender seus fluxos de trabalho e seus requisitos, você poderá configurar o vSphere DRS para obter o máximo desempenho e o máximo benefício de sua infraestrutura virtual.

Dicas e truques de instalação e atualização do VMware Tools

O pacote VMware Tools fornece drivers (como VMXNET3, PVSCSI, SVGA etc.) e serviços que aprimoram o desempenho das máquinas virtuais e facilitam o uso de vários recursos do vSphere. Aqui estão algumas dicas e truques ao trabalhar com o VMware Tools:

• Uma visão geral do mapeamento de versões do VMware Tools pode ser encontrada aqui, link
• As versões mais recentes do VMware Tools podem ser baixadas nos seguintes links: link e link
• No VMware ESXi, as Ferramentas VMware estão localizadas em: / vmimages / tools-isoimages
• A versão mais recente do VMware Tools 10.3.10 é compatível com o ESXi 6.0.0 a 6.7 U3
• Para visualizar quais componentes do VMware Tools estão instalados em um sistema operacional Windows: abra o Regedit e navegue até o seguinte local.

1	HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Features\10176710886A59A4C938D6DEE96B37D5

Nomes com escudeiro ou menos não estão instalados. Outro método no Windows 10, por exemplo, é acessar Aplicativos e Recursos e selecionar: modificar o VMware Tools

• Uma instalação padrão silenciosa ou autônoma pode ser feita usando o seguinte comando. Este comando não instalou os componentes do NSX:

1	Setup64.exe /s /v "/qb REBOOT=R" /l c:\windows\temp\vmware_tools_install.log

• Use a opção ADDLOCAL e REMOVE para definir quais componentes instalar. O comando a seguir instala todos os componentes esperados, o Hgfs, SVGA, VSS, AppDefense e o componente NetworkIntrospection. Essa configuração do VMware Tools pode ser usada, por exemplo, para uma imagem do Horizon View Golden.

1	setup64.exe /s /v" /qb REBOOT=R ADDLOCAL=All REMOVE=Hgfs,SVGA,VSS,AppDefense,NetworkIntrospection"" /l c:\windows\temp\vmware_tools_install.log

Os seguintes valores de componente do VMware Tools podem ser usados:

Valores dos componentes	Componente	Descrição
Drivers	Áudio	Driver de áudio para sistemas operacionais de 64 bits
	BootCamp	Suporte do Driver for Mac BootCamp
	MemCtl	Driver de controle de memória VMware para gerenciamento de memória
	Mouse	Driver de mouse VMware
	PVSCSI	Adaptador SCSI Paravirtual do VMware
	SVGA	Driver VMware SVGA
	Sync	Driver de sincronização do sistema de arquivos, que permite aos aplicativos de backup criar instantâneos consistentes com os aplicativos. Este driver é usado se o sistema operacional convidado for anterior ao Windows Server 2003. Sistemas operacionais mais recentes usam o driver VSS.
	ThinPrint	Driver que permite que as impressoras adicionadas ao sistema operacional host apareçam na lista de impressoras disponíveis na máquina virtual. O VMware Tools não suporta os recursos do ThinPrint para o vSphere 5.5 e posterior.
	VMCI	Driver da Interface de Comunicação da Máquina Virtual. Esse driver permite que as máquinas virtuais se comuniquem com os hosts nos quais são executadas sem usar a rede
	Hgfs	Driver de pastas compartilhadas do VMware. Use este driver se você planeja usar esta máquina virtual com o VMware Workstation, Player ou Fusion. A exclusão desse recurso impede o compartilhamento de uma pasta entre sua máquina virtual e o sistema host.
	VMXNet	Driver de rede VMware VMXnet.
	VMXNet3	Driver de rede VMware VMXnet de última geração para máquinas virtuais que usam hardware virtual versão 7 e superior (ESX (i) 4.xe superior)
	FileIntrospection	Driver NSX File Introspection, vsepflt.sys.
	NetworkIntrospection	Driver de introspecção de rede NSX, vnetflt.sys.
	VSS	Driver para criar backups automáticos. Este driver é usado se o sistema operacional convidado for Windows Vista, Windows Server 2003 ou outro sistema operacional mais recente. Os sistemas operacionais Linux e Windows mais antigos usam o driver Filesystem Sync.
	AppDefense	Componente do VMware AppDefense. Os componentes do AppDefense consistem no driver do modo de kernel glxgi.sys e no serviço de modo de usuário gisvc.exe.
Caixa de ferramentas	Perfmon	Driver para registro de desempenho WMI.

A versão mais recente dos valores do componente VMware Tools pode ser encontrada aqui, link

PowerCLI

Para identificar e atualizar as versões do VMware Tools, PowerCLI é seu amigo. Primeiro instale o módulo PowerCLI, link . Após a instalação do módulo, conecte-se ao vCenter Server.

1	$vcsa = "vcsa03.lab.local"

2

3	Import-Module VMware.PowerCLI

4	Connect-VIServer -Server $vcsa

Identificar versões do VMware Tools

Para obter as versões do VMware Tools das VMs em execução, use o seguinte comando PowerCLI:

1	Get-VM | Get-VMguest | Where {$_.State -eq 'Running'} | Select VmName, ToolsVersion

• Obtenha todas as VMs em execução que não possuem o VMware Tools versão 10.3.10 instalada:

1	Get-VM | Get-VMguest | Where-Object {$_.State -eq 'Running' -and $_.ToolsVersion -notlike '10.3.10'} | Select VmName, ToolsVersion

• Obtenha todas as VMs em execução que possuem uma versão desatualizada do VMware Tools:

1	Get-VM | Get-VMguest | where-object {$_.State -eq 'Running' -and $_.ExtensionData.ToolsversionStatus -eq 'GuestToolsNeedUpgrade'} | Select VmName

Atualizar ferramentas VMware

Depois de ter uma visão geral de todas as versões desatualizadas do VMware Tools, é fácil atualizá-las para a versão mais recente. Neste exemplo, a opção -NoReboot é usada para que o sistema operacional não seja reiniciado. Ao usar a opção -NoReboot, verifique se a reinicialização será planejada em uma janela de manutenção. Isso interrompe, por exemplo, a instalação das atualizações do Windows porque há uma ação de reinicialização pendente que precisa ser executada primeiro.

Primeiro exporte todas as VMs para um arquivo CSV que será salvo em c: \ temp \ vms.csv

1	Get-VM | Get-VMguest | where-object {$_.State -eq 'Running' -and $_.ExtensionData.ToolsversionStatus -eq 'GuestToolsNeedUpgrade'} | Select VmName | export-csv c:\temp\vms.csv -NoTypeInformation

Verifique o arquivo CSV e verifique se apenas as VMs estão listadas que precisam ser atualizadas. Depois disso, importe o CSV e atualize as VMware Tools usando os seguintes comandos:

1	$vms = Import-Csv c:\temp\vms.csv

2	$vms | % { get-vm -name $_.VmName | Update-Tools -NoReboot}

Minha experiência de atualização do VMware vSphere 6.7 Update 3

Esta atualização do vSphere foi anunciada oficialmente 6.7 Atualização 3 na semana passada e, ontem, ficou disponível para download . Para pessoas com apenas o VMUG Advantage EVALExperience com o (atualmente) mais antigo 6.7 Atualização 2
VMware-VMvisor-Installer-6.7.0.update02-13006603.x86_64.iso
eles podem usar o ESXCLI para atualizar quais downloads e instalações com um comando e não exigem credenciais my.vmware.com ou avaliações de software. Este é o método de atualização que testei primeiro, mas não com as coisas na ordem correta, que era atualizar meu VCSA primeiro!

My VCSA 6.7 Update 3 Upgrade

Encontrei um problema com minha atualização do VCSA usando o recurso de atualização interno. Eu recebi o seguinte erro:
Error in method invocation Timeout happens while sending message to microservice
e até reiniciar meu dispositivo VCSA, ele não me permitirá continuar com a atualização “Preparar e instalar”. As imagens de vídeo desse problema foram perdidas (quarto de hotel com pouca internet), mas fico feliz que a solução alternativa tenha sido um simples reinício. Infelizmente, não tive tempo nem mecanismo para relatar esse bug em potencial para chegar à causa raiz, mas pelo menos estou documentando aqui aqui, caso você também se depare com esse problema. A busca por esse erro no Google não me deu nenhum resultado útil, por isso parece ser um problema raro.

Minha atualização do ESXi 6.7 Update 3

Usei o ESXCLI no meu sistema de teste e ele correu sem problemas, e peguei uma transcrição dessa sessão SSH para que você possa ver todos os VIBs atualizados no meu Supermicro SYS-5028D-TN4T SuperServer Bundle .

Observe a nova página de login do VCSA. Despejo do Adobe Flash, a interface do usuário do HTML5 tem 100% de paridade de recursos desde a 6.7 Atualização 1!

Pelo menos preliminarmente, essa atualização parece funcionar muito bem no Xeon D, mas vou precisar de mais alguns dias de teste, juntamente com uma atualização da minha estação de trabalho principal quando voltar para casa, para ficar muito mais confortável com essa afirmação. . Em outras palavras, prossiga com as atualizações por seu próprio risco e faça o backup do seu ESXi primeiro, especialmente em um laboratório doméstico, onde você provavelmente não possui um mecanismo oficial de suporte da VMware. Reverter para quando as coisas funcionaram pode ser sua única opção, caso as coisas dêem errado para você.

Compartilhe sua experiência de atualização

Sinta-se à vontade para nos informar como a sua atualização ocorre, deixando um comentário abaixo, especialmente se você estiver em um hardware suportado, como um SuperServer Bundle , e tente mencionar o método de atualização usado.

Como instalar o MikroTik CHR na estação de trabalho VMware

O MikroTik é encontrado no RouterBoard, onde o RouterOS e License são pré-construídos, e o Aplicativo RouterOS, que pode ser instalado em uma Máquina Física ou Máquina Virtual. A instalação do RouterOS na máquina física ou virtual tem limitações de licença. Pacotes completos do RouterOS não podem ser usados ​​mais de 24 horas sem licença. Portanto, o aplicativo RouterOS não é adequado para o trainee ou não é adequado ao objetivo do RND. No RouterOS v6.34, o MikroTik apresenta o Cloud Hosted Router (CHR, uma nova versão do RouterOS) que possui um esquema de licenciamento diferente. O MikroTik CHR possui pacotes completos do RouterOS e pode ser usado gratuitamente com limitação de largura de banda. Portanto, o MikroTik CHR é muito útil para o trainee e o usuário do RND. Neste artigo, discutirei como instalar o MikroTik Cloud Hosted Router corretamente na estação de trabalho VMware, com o guia passo a passo.

MikroTik Cloud Hosted Router (CHR) e licença

MikroTik CHR é uma versão do RouterOS destinada a ser executada como uma máquina virtual. Ele suporta arquitetura x86 e 64 bits e pode ser usado na maioria dos hipervisores populares, como VMWare, Hyper-V, VirtualBox, KVM e outros. O MikroTik CHR possui recursos completos do RouterOS ativados por padrão, mas possui um modelo de licenciamento diferente com base na largura de banda de upload do que em outras versões do RouterOS.

O MikroTik CHR possui atualmente o seguinte esquema de licenciamento em quatro níveis.

Licença	Limite de velocidade de upload / interface	Preço
Livre	1Mbit	LIVRE
P1	1Gbit	$ 45
P10	10Gbit	$ 95
P100	Ilimitado	$ 250

Criando uma conta MikroTik, qualquer nível de licença paga pode ser usado por 60 dias (licença de teste de 60 dias). No prazo de 60 dias, você deve adquirir qualquer nível de licença, caso contrário o MikroTik CHR não poderá mais ser usado. Você precisa fazer uma instalação completa e completa do CHR.

Instalando o MikroTik CHR na estação de trabalho VMware

O MikroTik CHR pode ser facilmente instalado na estação de trabalho VMware, mas você deve conhecer o procedimento de instalação adequado. A instalação do MikroTik CHR na VMware Workstation pode ser dividida nas seguintes etapas.

• Baixando a imagem do disco MikroTik CHR (vmdk)
• Download e instalação da estação de trabalho VMware
• Personalizando o VMware Networking
• Criando uma nova máquina virtual para o MikroTik CHR
• Acessando o Virtual MikroTik Router a partir do Winbox

Etapa 1: Fazendo download da imagem do MikroTik CHR Disk

MikroTik apresenta o Cloud Hosted Router do RouterOS v6.34. Portanto, visitando a página de download do MikroTik, você pode facilmente fazer o download do MikroTik CHR. Precisamos do arquivo de imagem do VMDK para o VMware Workstation. Portanto, visite a Página de Download do MikroTik e baixe o arquivo de imagem VMDK da versão estável atual do RouterOS. A versão atual estável do RouterOS é 6.45.5 (no momento da publicação deste artigo). Portanto, estou usando a imagem VMDK chr-6.45.5.vmdk para este artigo.

Etapa 2: baixando e instalando a estação de trabalho VMware

O VMware Workstation é um hipervisor tipo 2. Portanto, ele deve ser executado em um sistema operacional host. O VMware Workstation pode ser instalado no sistema operacional Windows e Linux e pode ser baixado da página de download do VMware, mas você deve ter uma conta do VMware. Se você não possui uma conta VMware, crie uma conta no VMware, faça login na sua conta e faça o download do VMware Workstation para o seu sistema operacional na página de download do VMware. Como alternativa, você pode baixar o VMware Workstation de qualquer site de compartilhamento de software. Neste artigo, estou usando o VMware Workstation 15.0.0 no sistema operacional Windows.

A instalação do VMware Workstation no sistema operacional Windows é muito fácil. Como outro aplicativo de software, ele apenas pede para seguir algumas instruções gráficas. Conclua a instalação do VMware e execute-a. O VMware Workstation pode solicitar licença na primeira execução. Você pode encontrar licença pesquisando no Google ou pode usar a estação de trabalho por 30 dias de avaliação. A página inicial do VMware Workstation 15.0.0 é semelhante à imagem a seguir.

Página inicial da estação de trabalho VMWare 15

Etapa 3: Personalizando o VMware Networking

Por quê? Porque se você tiver várias placas / adaptadores de rede, poderá criar vários comutadores virtuais cujo uplink será um adaptador de rede físico. No VMware Workstation 15.0.0, você pode criar no máximo 20 comutadores virtuais.

Instalei o VMware Workstation no meu laptop, que possui duas placas de rede (WLAN e LAN). Se eu criar dois comutadores virtuais cujo uplink será duas interfaces de rede físicas, poderei criar dois adaptadores de rede virtual para a máquina virtual MikroTik CHR em que um adaptador de rede será conectado a um comutador virtual e outro adaptador de rede será conectado a outro comutador virtual. Portanto, meu roteador virtual terá duas interfaces de rede e uma pode ser usada como conexão WAN e outra como conexão LAN.

As etapas a seguir mostrarão como criar dois comutadores virtuais que serão conectados a dois adaptadores de rede físicos.

• Vá para o menu Editar e clique na opção Virtual Network Editor…. A janela Editor de rede virtual aparecerá onde os switches / redes virtuais atuais estão listados. Você pode achar que todas as opções estão esmaecidas se não tiver privilégio de administrador. Nesse caso, clique no botão Alterar configurações na parte inferior e você encontrará todas as opções ativas.
• Para simplificar, exclua todos os comutadores virtuais sem VMnet0 e VMnet1 (selecione qualquer comutador virtual e clique no botão Remover rede). Se você não possui VMnet0 ou VMnet1, clique em Adicionar rede … A janela Adicionar uma rede virtual será exibida. Escolha VMnet0 ou VMnet1 qual você deseja criar em Selecione uma rede para adicionar o menu suspenso e clique no botão OK. Você descobrirá que seu switch / rede virtual criado será listado agora.
• Clique no comutador virtual VMnet0 e clique no botão de opção Ponte no painel Informações da VMnet e, em seguida, escolha seu adaptador de rede físico (estou escolhendo o adaptador WLAN para este artigo) que você deseja fazer uplink para esse comutador virtual, formulário Ponte no menu suspenso.
• Da mesma forma, clique no comutador virtual VMnet1, clique no botão de opção Ponte e escolha seu adaptador de rede físico (eu estou escolhendo o adaptador LAN para este artigo) que você deseja fazer a ligação ascendente para esse comutador virtual, do ponte ao menu suspenso.
• Agora clique em Aplicar e no botão OK.

Editor de rede virtual VMware

A criação do comutador virtual para adaptadores de rede físicos foi concluída, onde um comutador será usado como conexão WAN e outro será usado como conexão LAN. Se você tiver mais adaptadores de rede físicos, poderá criar mais comutadores virtuais no VMware Workstation.

Etapa 4: Criando máquina virtual para MikroTik CHR

Agora criaremos uma máquina virtual que será usada como roteador virtual no VMware Workstation. As etapas a seguir mostrarão como criar uma nova máquina virtual para o MikroTik CHR.

• Vá para o menu Arquivo e clique em Nova máquina virtual … A janela do Assistente de nova máquina virtual será exibida.
• Agora ele perguntará que tipo de configuração você deseja. Clique no botão de opção Personalizado e, em seguida, clique em Avançar
• Não há nada a fazer na compatibilidade de hardware da máquina virtual. Então, clique no botão Avançar.
• Na instalação do sistema operacional convidado, escolha o botão de opção Instalar o sistema operacional mais tarde e clique no botão Avançar.
• Em Selecione um sistema operacional convidado, clique em Outro botão de opção e escolha Outros de 64 bits no menu suspenso da versão.
• Agora coloque o nome do seu roteador virtual desejado na caixa de entrada Nome da máquina virtual (MikroTik CHR). Opcionalmente, você pode definir o local padrão da máquina virtual para o local desejado, onde os arquivos relacionados à máquina virtual serão mantidos. Agora clique no botão Avançar.
• Em Configuração do processador, escolha quantos processadores você deseja atribuir ao seu roteador virtual no menu suspenso Número de processadores e escolha quantos núcleos você deseja atribuir por processador no menu suspenso Número de núcleos por processador. Clique no botão Avançar.
• Agora atribua a memória RAM do roteador virtual e clique no botão Avançar.
• Em Tipo de rede, clique no botão de opção Usar rede em ponte no painel Conexão de rede e clique no botão Avançar.
• Selecione o tipo de controlador de E / S LSI Logic SAS e clique no botão Avançar.
• Agora selecione o tipo de disco virtual IDE e clique no botão Avançar.
• No painel Disco, clique em Usar um botão de opção Disco virtual existente e clique no botão Avançar.
• Agora procure o arquivo de imagem VMDK baixado no painel de arquivos em disco existente e clique no botão Avançar. Agora, ele perguntará se converterá o disco de saída da máquina virtual para um formato mais recente ou não. Clique no botão Convert.
• Agora clique no botão Personalizar hardware. A janela Hardware aparecerá.
• Clique no botão Adicionar. Assistente para adicionar hardware será exibido. Clique no adaptador de rede e clique no botão Concluir. Agora você encontrará outro adaptador de rede na lista Hardware.
• Clique no primeiro adaptador de rede e clique no botão de opção Personalizado: rede virtual específica e, em seguida, escolha VMnet0 no menu suspenso. Da mesma forma, clique no segundo adaptador de rede e clique em Personalizado: botão de opção rede virtual específica e escolha VMnet1 no menu suspenso e, em seguida, clique no botão Fechar.
• Agora clique no botão Concluir para fechar a janela do Assistente de nova máquina virtual. Sua nova máquina virtual / roteador virtual agora será criada e listada na seção Meu computador.
• Clique no botão direito do mouse na nova máquina virtual e vá para a opção Energia e clique em Iniciar convidado.
• A máquina virtual / roteador virtual (MikroTik CHR) será iniciada agora e solicitará o login. O nome de usuário padrão é admin e a senha está em branco. Então, faça o login com essas informações. Após o login, você encontrará o MikroTik CHR como na imagem a seguir.

Roteador virtual MikroTik no VMware

Etapa 5: Acessando o MikroTik Virtual Router (CHR) no Winbox

Instalamos com êxito o MikroTik CHR na estação de trabalho VMware. Agora, acessaremos o MikroTik Virtual Router a partir do Winbox, para que possamos configurar facilmente nosso MikroTik Router. Para conectar o MikroTik Virtual Router a partir do Winbox, primeiro faça o download do Winbox no site do MikroTik. Conecte seus adaptadores de rede físicos ao switch físico e ligue-os. Agora abra o Winbox a partir de qualquer PC conectado a esses comutadores físicos ou do seu Desktop ou Laptop onde o VMware Workstation está instalado e clique no botão de detecção automática. Se tudo estiver correto, você encontrará o endereço MAC do seu roteador CHR. Clique no endereço MAC e coloque o nome de usuário admin, mantenha a senha em branco e clique no botão Conectar. Agora você encontrará o seu Cloud Hosted Router no Winbox.

 

MikroTik CHR Login da Winbox

Nota: Use o MikroTik CHR na VMware Workstation apenas para fins de RND. Se você deseja usar o MikroTik CHR para produção, sugerirei o uso do ESXi Hypervisor, que é um hipervisor de barra de metal que fica diretamente na camada de hardware físico e gerencia a máquina virtual. Por outro lado, o hipervisor VMware Workstation fica em um sistema operacional host (Windows ou Linux) e depende completamente desse sistema operacional host. Para isso, o VMware Workstation nem sempre é adequado para uso em produção.

Switch padrão do vSphere e switch distribuído, parte 2

Na primeira parte desta série, vimos a Visão geral do VMware vSphere Standard Switch (VSS) e vSphere Distributed Switch (VDS), como criar o VSS e como a arquitetura e o gerenciamento do VDS são diferentes do VSS.

Nesta segunda parte, veremos o seguinte:

• Switches distribuídos e grupos de portas do vSphere
• VDS – configuração passo a passo
• Diferença e semelhanças entre VSS e VDS
• Migrando entre VSS e VDS e Voltar

Junto com isso, veremos também as práticas recomendadas do vSphere Virtual Switch.

Exibindo comutadores distribuídos e grupos de portas do vSphere

Vamos dar uma olhada nas propriedades de um grupo de portas do vSphere Distributed Switch e ver as opções disponíveis para o administrador do vSphere.

Torna-se evidente que você tem mais definições de configuração disponíveis com o grupo de portas do vSphere Distributed Switch

.

 

Exibindo Switches distribuídos do vSphere no vSphere Client 

Examinando as propriedades de um grupo de portas de switch distribuído do vSphere 

Configurações avançadas do grupo de portas do vSphere Distributed Switch

Na tela de configurações da VLAN das propriedades do vSphere Distributed Switch, você vê a configuração do tipo VLAN. Observe a opção VLAN privada com o vSphere Distributed Switch.

 

As opções de VLAN incluem VLANs privadas com o vSphere Distributed Switch

Na tela Segurança, você pode configurar o modo promíscuo, as alterações de endereço MAC e as transmissões forjadas para o grupo de portas do vSphere Distributed Switch.

 

Exibindo as configurações de segurança do grupo de portas do vSphere Distributed Switch

Na tela Agrupamento e failover, você vê muitas configurações diferentes para várias funcionalidades de agrupamento e failover. Observe com o grupo de portas do vSphere Distributed Switch a rota com base na carga física da NIC como uma das opções para o balanceamento de carga.

 

Configurações de formação de equipe e de failover para um grupo de portas do vSphere Distributed Switch

As configurações de modelagem de tráfego permitem modelagem de tráfego do Ingress e modelagem do tráfego de Saída.

A tela Monitoramento permite ativar ou desativar o monitoramento do grupo de portas do vSphere Distributed Switch.

Monitorando configurações para um grupo de portas do vSphere Distributed Switch

A tela Configurações diversas permite ativar Bloquear todas as portas.

 

Exibindo as configurações diversas de um grupo de portas do vSphere Distributed Switch

Criando um Switch Distribuído do vSphere

 

As discussed, the vSphere Distributed Switch is created at the vCenter Server level and pushed

Conforme discutido, o vSphere Distributed Switch é criado no nível do vCenter Server e enviado para os hosts ESXi à medida que são associados ao VDS. Portanto, criamos o novo VDS na exibição Rede do vSphere Client.

Navegue até as configurações de rede no vSphere Client. Clique com o botão direito do mouse no nó vSphere Datacenter e selecione Distributed Switch > New Distributed Switch.

 

Criando um novo Switch Distribuído do vSphere

Isso inicia o assistente Novo Switch Distribuído. A primeira coisa que você configura é o Nome e o Local. Escolha um nome para o novo VDS.

 

Configurando o nome e o local para um novo vSphere Distributed Switch

Selecione a versão do novo vSphere Distributed Switch. Abaixo estão as versões disponíveis no assistente.

Opção	Descrição
Version 6.6.0	Compatível com ESXi versão 6.7 e posterior.
Version 6.5.0	Compatível com ESXi versão 6.5 e posterior. Os recursos lançados com versões posteriores do vSphere Distributed Switch não são suportados.
Version 6.0.0	Compatível com ESXi versão 6.0 e posterior. Os recursos lançados com versões posteriores do vSphere Distributed Switch não são suportados.

Selecione a versão do vSphere Distributed Switch para criar

Na tela Definir configurações, você define o número de uplinks, configurações de Controle de E / S de rede e também nomeia o primeiro nome do grupo de portas padrão.

Definindo as configurações do novo vSphere Distributed Switch

Pronto para concluir o assistente Novo Switch Distribuído.

Concluindo a configuração do novo switch distribuído

Você verá o novo vSphere Distributed Switch na lista de redes disponíveis na visualização Networking do vSphere Client.

Viewing the newly created vSphere Distributed SwitchCom o vSphere Distributed Switch, a criação do novo VDS é apenas parte da tarefa.

Em seguida, precisamos adicionar hosts ESXi ao novo VDS. Vamos ver como.

Adicionar hosts ESXi a um switch distribuído do vSphere

Em seguida, precisamos adicionar os hosts ESXi ao novo vSphere Distributed Switch. Para fazer isso, clique com o botão direito do mouse no novo vSphere Distributed Switch e escolha Adicionar e gerenciar hosts.

Adicione e gerencie hosts para adicionar hosts ESXi a um VDSA primeira parte do assistente Adicionar e gerenciar hosts é escolher a ação que você deseja executar. Como queremos associar hosts ESXi a um novo vSphere Distributed Switch, escolhemos a opção Adicionar hosts.

Adicionar novos hosts ao comutador distribuídoAdicionar novos hosts ao comutador distribuído Na tela Hosts selecionados, clique no sinal de “mais verde” para abrir a caixa de diálogo Selecionar novos hosts.

Selecione hosts para adicionar a esse switch distribuídoNa caixa de diálogo Selecionar novos hosts, marque a caixa de seleção ao lado dos hosts que você deseja adicionar ao novo vSphere Distributed Switch. Pense na facilidade com que isso permite adicionar o mesmo VDS configurado a todos os hosts selecionados. Com o VSS, você teria que configurar um novo comutador VSS em cada host ESXi e garantir que as configurações sejam idênticas para as VMs do vMotion e outros motivos.

Escolha os novos hosts a serem adicionados ao VDSAgora, os novos hosts ESXi estão selecionados.

Novos hosts ESXi são selecionados para serem adicionados ao novo VDSPara cada host ESXi, ele precisa de um adaptador de rede físico conectado como um uplink ao novo VDS.

Nota: temos o vmnic2 gratuito nos dois hosts.

Clique no botão Atribuir uplink.

Gerenciar adaptadores físicos para os hosts ESXi para vincular ao novo VDS 

Na caixa de diálogo Selecionar uma ligação ascendente, clique na ligação ascendente específica ou na atribuição automática. Você também pode clicar na caixa Aplicar esta atribuição de uplink ao restante dos hosts. Fazendo isso, você pode economizar muito tempo configurando as atribuições do adaptador de rede físico, pois seleciona essa opção uma vez e é aplicada a cada host que você está adicionando.

Selecionando uma ligação ascendenteOs adaptadores de rede físicos agora estão atribuídos aos hosts ESXi. Observe que eles são exibidos como (Atribuído) e também exibe em qual slot de ligação ascendente o adaptador de rede físico escolhido será atribuído.

Agora, os uplinks para cada host estão atribuídos ao VDSNa tela Gerenciar adaptador do VMkernel, você pode gerenciar e atribuir adaptadores de rede VMkernel ao comutador distribuído.

Manage VMkernel adaptersAlém disso, você pode migrar a rede da VM para selecionar máquinas virtuais ou adaptadores de rede para migrar para o comutador distribuído, se desejar. Como nosso VDS será usado para o tráfego de máquinas virtuais, não há portas do VMkernel para migrar.

 

Migrate VM networkingPor fim, você acessa a tela Pronto para concluir, agora revise suas configurações e seleções e clique em Concluir.

 

Ready to complete the Add and Manage hosts wizardComparando recursos do vSphere Standard Switch vs vSphere Distributed Switch

A tabela a seguir é uma comparação dos vários recursos oferecidos por um comutador virtual VSS ou VDS. Observe que o VSS é bastante limitado quando comparado aos recursos mais avançados encontrados no VDS.

Migrando entre VSS e VDS e Voltar

O vSphere Standard Switch e o vSphere Distributed oferecem grande flexibilidade de migração. No entanto, convém ter vários adaptadores de rede para trabalhar, para que haja uma reversão fácil entre uma migração com falha em qualquer direção.

Lembre-se dos seguintes pontos para migrar entre o VSS e o VDS e seguir na outra direção.

• Possui vários adaptadores de rede
• Primeiro, mova um adaptador de rede do VSS para VDS ou VDS para VSS
• Verifique se você criou os grupos de portas relevantes, marcados com as VLANs apropriadas para migrar o VMkernel e as máquinas virtuais
• Depois que um adaptador de rede é atribuído ao tipo de comutador de destino e os grupos de portas do comutador virtual estão em vigor, você pode migrar portas e máquinas virtuais do VMkernel
• Lembre-se de que a migração para o VDS é realizada no nível de rede do vCenter Server e a migração para o VSS é realizada nas configurações de rede do host do ESXi

O esquema básico do processo em qualquer direção após a configuração dos requisitos do comutador virtual de destino e do grupo de portas será semelhante a:

1. Retire um dos adaptadores de rede do comutador virtual de origem e atribua-o ao comutador de destino
2. Mover portas do VMkernel para o comutador virtual de destino
3. Verifique a conectividade para e entre todos os recursos
4. Mova máquinas virtuais para os novos grupos de portas no comutador virtual de destino
5. Mova todos os adaptadores de rede do comutador virtual de origem para o comutador virtual de destino

Práticas recomendadas do vSphere Virtual Switch

Existem algumas práticas recomendadas comuns aos dois tipos de comutadores virtuais do vSphere e outras um pouco mais personalizadas para cada tipo de comutador.

Abaixo estão algumas práticas recomendadas comuns a serem lembradas ao trabalhar com o vSphere Standard Switches e o vSphere Distributed Switches.

• Use vários uplinks físicos para cada comutador virtual para redundância
• Implante o mesmo número de adaptadores de rede físicos e velocidades de porta em todos os hosts conectados a qualquer tipo de comutador
• Use o controle de E / S de rede ao usar vários tipos de tráfego atravessando um único adaptador
• Verifique se os tamanhos de MTU correspondem entre os grupos de portas e o próprio comutador virtual
• Considere sua configuração e pedido de failover
• Use VLANs para separar o tráfego sem precisar usar grandes quantidades de adaptadores de rede físicos
• Use VLANs privadas quando houver necessidade de ainda mais separação e isolamento
• Se estiver usando um VDS, mantenha um VSS provisionado em cada host para conectividade de emergência, caso algo catastrófico aconteça com o VDS
• O uso de comutadores virtuais VDS ressalta a necessidade de fazer backup do vCenter Server. Como a configuração do VDS é realizada com o vCenter, verifique se você está fazendo backup do seu equipamento VCSA usando a solução de backup integrada na interface VAMI
• Mantenha as configurações de comutador virtual consistentes ao usar comutadores virtuais do VSS
• Use o PowerCLI, se possível, para implementar as configurações do VSS de forma consistente nos hosts ESXi para ajudar a eliminar o desvio de configuração

Pensamentos finais

A rede virtual do VMware vSphere fornece aos administradores do vSphere opções poderosas para controlar e gerenciar o tráfego de rede dentro e fora das máquinas virtuais na infraestrutura do vSphere. Os dois tipos de comutadores virtuais no vSphere: vSphere Standard Switch (VSS) e vSphere Distributed Switch (VDS) permitem opções realmente excelentes de conectividade para ambientes vSphere.

Enquanto o vSphere Standard Switch é um comutador básico muito capaz que pode executar ambientes de produção muito grandes do vSphere, o vSphere Distributed Switch é a opção mais poderosa e escalável dos dois. Os planos de gerenciamento e dados separados do vSphere Distributed Switch permitem gerenciamento centralizado, enquanto ainda permitem que os hosts ESXi transportem tráfego, mesmo quando o vCenter Server não está disponível. Ele requer uma licença Enterprise Plus ou vSAN para usá-lo. Se você deseja operar o ambiente do VMware vSphere em escala, o switch VDS é certamente a melhor escolha e fornece muitos dos recursos e capacidades necessários para configurações de rede mais avançadas, bem como a solução de rede definida pelo software NSX da VMware.