Os problemas conhecidos anteriormente são agrupados da seguinte maneira.
Os seguintes defeitos eram problemas conhecidos nas versões anteriores e permanecem como problemas conhecidos nesta versão.
- A migração do vRealize Automation do 6.x para o 7.2 falhará se o ambiente de destino do 7.2 tiver um grupo de administradores do vRealize Orchestrator diferente definido como o padrão
O grupo de administradores do vRealize Orchestrator padrão, o vsphere.local/vcoadmin, não deve ser alterado no centro de controle do vRealize Orchestrator antes da migração.
Solução alternativa: Consulte o artigo 2148669 da Base de Conhecimento.
O cliente STOMP não pode estabelecer conexão após atualizar o tcServer para a versão 3.2
No vRealize Automation 7.2, o IaaS Manager Service apenas suporta a sondagem do REST como o mecanismo de conexão ao se comunicar com o serviço de agente de eventos. A definição da configuração Extensibility.Client.RetrievalMethod é ignorada.
-
Se a telemetria estiver desativada antes de você atualizar o vRealize Automation da versão 6.2.4 ou 6.2.5 para 7.2, a guia de telemetria no painel de gerenciamento do appliance do vRealize Automation poderá exibir um erro
Essa mensagem pode aparecer após a atualização: Erro: Não é possível determinar a próxima execução. Reative ou desative a telemetria. A mensagem aparece porque nenhum dado de telemetria está sendo coletado, portanto o sistema não pode determinar um tempo de execução seguinte adequado. Quando este for o caso, nenhum recurso de telemetria vai funcionar.
Solução alternativa: Escolha ativar ou desativar a telemetria usando a caixa de seleção Join the VMware Customer Experience Improvement Program e clique em Salvar Configurações.
-
Falha com erros na migração do Active Directory nativo
Atualmente, o utilitário de migração SSO não transfere um Active Directory nativo automatizado durante o processo de migração do vRealize Automation.
Solução alternativa: Se você configurar manualmente e iniciar o Active Directory nativo, poderá migrar o Active Directory com êxito. Você deve realizar essa ação depois de concluir o processo de migração do vRealize Automation.
-
Falha na migração do nó do IaaS do vRealize Automation 6.2.4 para o 7.1 quando o nome da instância do servidor PostgreSQL contém caracteres não ASCII
Solução alternativa: Use a migração a um ambiente do vRealize Automation com um procedimento de backup de banco de dados IaaS para migrar seu ambiente do Automation vRealize 6.2.4. para o 7.1.
-
A configuração do agente de gerenciamento IaaS é corrompida após a atualização de um ambiente de alta disponibilidade do vRealize Automation 6.2.3 ou versões anteriores para o 7.1
Após a atualização do vRealize Automation 6.2.2 para o 7.1, o agente de gerenciamento IaaS não pode ser iniciado. Uma mensagem de erro relata uma ID de nó ausente no arquivo de configuração do agente de gerenciamento.
Solução alternativa: Consulte o artigo 2146550 da Base de Conhecimento.
-
Ações de dimensionamento vertical ou horizontal apresentam falhas em uma implantação atualizada
Ações de dimensionamento vertical ou horizontal não têm suporte para implantações de importação em massa ou para implantações atualizadas do vRealize Automation 6.x.
Solução alternativa: Não há uma solução alternativa. Novas implantações feitas a partir de blueprints após a atualização oferecem suporte para ações de dimensionamento vertical ou horizontal.
É exibida uma mensagem de erro quando você faz login no console de gerenciamento do appliance do vRealize Automation
Depois de fazer login com as credenciais apropriadas, você recebe uma mensagem de erro informando: "Resposta inválida do servidor. Tente novamente". Isso é causado por um problema com o cache do navegador.
Solução alternativa: Faça logout, limpe o cache do navegador e faça login novamente.
Certos blueprints não podem ser totalmente atualizados devido a falhas na atualização de recursos de catálogo
Blueprints de várias máquinas atualizados que contêm redes sob demanda ou configurações do balanceador de carga podem não funcionar totalmente após a atualização para o vRealize Automation 7.x.
Solução alternativa: Após a atualização, apague e recrie as implantações associadas aos blueprints de várias máquinas. Todo trabalho de limpeza associado do NSX Edge deve ser feito no NSX.
-
Quando se atualiza do vRealize Automation 6.2.0 para o 7.0, a atualização do vPostgres apresenta falha e aparece uma mensagem de erro
Se o sistema tiver um banco de dados de RPM corrompido, essa mensagem de erro aparecerá durante o processo de atualização: Falha ao instalar atualizações (erro durante a execução de scripts de pré-instalação).
Solução alternativa: Para obter informações sobre como se recuperar de uma corrupção de banco de dados de RPM, veja o artigo "Recuperação de banco de dados de RPM" no site do RPM. Depois de corrigir o problema, execute a atualização novamente.
-
Quando se executa o verificador de pré-requisitos, ele falha com um aviso sobre RegistryKeyPermissionCheck, mas as instruções para corrigir o erro não funcionam durante a instalação
O verificador de pré-requisitos falha porque ele diferencia letras maiúsculas de minúsculas no nome do usuário.
Solução alternativa: Altere temporariamente o usuário especificado para executar o serviço do agente de gerenciamento na máquina Windows para outro usuário e, em seguida, altere novamente para o usuário original com as letras maiúsculas/minúsculas corretas no nome do usuário.
-
Ao atualizar o Serviço de Gerenciador e o sistema do DEM Orchestrator, uma mensagem de erro de validação de nome é exibida e o host do Model Manager Web não pode ser validado
Se o nome do balanceador de carga for alterado no arquivo ManagerService.exe.config, aparecerá a seguinte mensagem de erro:
Distributed Execution Manager "NAME" Cannot be upgraded because it points to Management model web host "xxxx.xxxx.xxxx.net:443", which cannot be validated. É necessário resolver este erro antes de executar o upgrade novamente: Cannot validate Model Manager Web host. The remote certificate is invalid according to the validation procedure.
Solução alternativa: Faça as seguintes alterações no arquivo de configuração do ManagerService.exe.config. O local padrão é C:\Arquivos de Programas (x86)\VMware\vCAC\Server\ManagerService.exe.config.
Altere os valores de registo para todas as instâncias de DEM. Por exemplo, ambas as instâncias de DEM nas seguintes entradas do registro devem ser atualizadas.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware vCloud Automation Center DEM\DemInstanceId02]
"Name"="DEM"
"Role"="Worker"
"RepositoryAddress"="https://host_name:443/repository/"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware vCloud Automation Center DEM\DemInstanceId03]
"Name"="DEO"
"Role"="Orchestrator"
"RepositoryAddress"="https://host_name:443/repository/"
- Uma migração pode falhar quando se sincroniza reservas do banco de dados do IaaS para com o banco de dados PostgreSQL
A falha gera esta mensagem de erro: Read timed out.
Solução alternativa: Consulte o artigo 2149882 da Base de Conhecimento.
- A adição de um novo servidor virtual a um balanceador de carga sob demanda existente em uma implantação falha
Quando você adicionar um novo servidor virtual a um balanceador de carga sob demanda existente em uma implantação atualizada a partir de uma versão anterior do vRealize Automation 7.x, a adição falhará se esta for a primeira ação de reconfiguração no balanceador de carga desde a atualização. A falha gera o Código de erro: 14623 concernente a "portas duplicadas". A falha ocorre porque o sistema armazena uma configuração padrão de versões anteriores. Essa falha não afeta qualquer outra coisa no sistema. Para implantações do vRealize Automation 7.3, se você solicitar a adição de um servidor virtual a um balanceador de carga e fazer uma mudança em outro servidor virtual ao mesmo tempo, a solicitação falhará e gerará o mesmo erro.
Solução alternativa: Para implantações atualizadas: Execute uma ação de reconfiguração no balanceador de carga e edite uma configuração em qualquer um dos servidores virtuais. Isso corrige o problema do sistema que armazena a configuração padrão de versões anteriores. Você também pode fazer isso em balanceadores de carga atualizados a partir de versões anteriores ou em balanceadores de carga que tenham a mesma falha.
Para balanceadores de carga atualizados e balanceadores de carga implantados na versão 7.3, não edite um servidor virtual e adicione um servidor virtual na mesma solicitação. Executar a ação de edição e a ação de adição em solicitações separadas impede essa falha.
- Endpoints estão ausentes após a atualização para o vRealize Automation 7.3
Após uma atualização bem-sucedida para o vRealize Automation 7.3, a página Endpoints no console do vRealize Automation não exibe todos os endpoints.
Solução alternativa: Consulte o artigo 2150252 da Base de Conhecimento.
- Não é possível gerar o arquivo CSV para importação em massa devido a entradas duplicadas
Depois de fazer logon no console do vRealize Automation, selecione Infraestrutura > Administração > Importações em Massa e clique em Gerar Arquivo CSV. Você verá a seguinte mensagem de erro: "Ocorreu um erro. Para obter mais informações, consulte os logs de eventos no servidor IaaS ou entre em contato com o administrador do sistema." Nos logs de evento da máquina Windows IaaS, serão exibidas entradas semelhantes a esta: "System.ArgumentException: Um item com a mesma chave já foi adicionado." Esse problema ocorre quando a consulta usada para recuperar blueprints para importação em massa retorna entradas duplicadas.
Solução alternativa: Use o utilitário cloudutil.exe para gerar o arquivo CSV, concluindo estas etapas.
- Baixe cloudutil.exe na página de download do instalador do Windows no appliance do vRealize Automation: https://vra-va-hostname.domain.name:5480/installer/. O CloudUtil é a interface de linha de comando para o vRealize Automation Designer. Você executa os comandos na máquina Windows em que está executando o Designer. O local de instalação padrão na máquina Windows é C:\Program Files (x86)\VMware\vCAC\vRealize Automation Designer.
- Gere o arquivo CSV executando este comando: CloudUtil.exe Machine-BulkRegisterExport
- Quando você atualiza para o vRealize Automation 7.3 em um ambiente que está integrado à versão atual do vRealize Business, as informações sobre despesas aparecem como "não disponíveis" para todos os itens de catálogo no console do vRealize Automation
Esse problema é temporário e deverá ser resolvido depois que você fizer o upgrade para a versão mais recente do vRealize Business.
Solução alternativa: Upgrade para o vRealize Business for Cloud 7.3.0.
Você ainda pode ver as informações sobre despesas das máquinas virtuais do vRealize Automation nos relatórios do vRealize Business e em outras seções.
- Após desinstalar o WEBDAV como um dos pré-requisitos para a atualização da máquina 2012 R2 IaaS, o assistente de configuração exibe uma mensagem de InternalServerError.
Esta mensagem é exibida porque o pool do aplicativo do repositório é interrompido: "O Distributed Execution Manager não pode ser atualizado porque aponta para um host Management Model Web :443 que não pode ser validado. É necessário resolver este erro antes de executar o upgrade novamente: O serviço Model Manager Web está instalado no host :443, mas não está em funcionamento nem em execução. Código do status de resposta do HTTP Web: InternalServerError".
Solução alternativa: Vá para os pools do aplicativo no servidor IIS, inicie o pool do aplicativo do repositório e prossiga com o upgrade.
- Depois de atualizar um ambiente agrupado em cluster do vRealize Automation, um dos nós Xenon não está em execução
Durante o upgrade, um dos nós do vRealize Automation não foi inicializado.
Solução alternativa: Verifique o status de cada um dos nós da guia Xenon no console de gerenciamento. Se um dos nós não estiver em execução, inicie-o manualmente. Como alternativa, você pode abrir uma conexão SSH para cada um dos nós e executar "xenon do serviço-status do serviço". Se o nó não estiver em execução, execute "xenon do serviço-status do serviço".
- Ao atualizar os appliances do vRealize Automation, você pode encontrar falhas relacionadas a duplicatas no banco de dados para o serviço do vRealize Orchestrator.
A falha mostrada na interface do usuário será semelhante ao seguinte:
- Falha ao instalar atualizações (erro durante a execução de scripts de pós-instalação).
- Verificação de VA: concluída
- Pré-instalação: concluída
- Pós-instalação: falha
- Falha na atualização (código 0-2). Verifique os logs em /opt/vmware/var/log/vami ou tente novamente a atualização mais tarde.
Os erros listados em /var/log/bootstrap/postupdate.log incluirão:
Resolva duplicadas excluindo itens desnecessários.
Entradas duplicadas encontradas no banco de dados Orchestrator:
Duplicatas de elemento de recurso:
- 1 item com ID '<UUID>' e nome 'ko.properties'
- 1 item com ID '<UUID>' e nome 'fr_FR.properties'
- 1 item com ID '<UUID>' e nome 'zh_CN.properties'
(e muito mais)
Solução alternativa: Consulte o artigo 54982 da Base de Conhecimento.
A página do appliance do vRealize Automation não carrega corretamente
Quando se usa o Internet Explorer 11 no Windows 2012 R2, a página da interface da Web do appliance do vRealize Automation não carrega corretamente.
Solução alternativa: Use um navegador alternativo para acessar a página da interface do vRealize Automation.
- O appliance virtual da réplica do vRealize Automation falha ao ingressar no cluster após a migração
Uma configuração incorreta no appliance virtual da réplica impede que a operação de reingresso seja concluída.
Solução alternativa: Remova o appliance virtual da réplica do cluster no ambiente de origem e execute o procedimento de migração para um ambiente de destino mínimo. Após a conclusão da migração, implante um appliance virtual da réplica no ambiente de destino e associe-o ao appliance primário.
- Após uma migração bem-sucedida do vRealize Automation 7.3 para a versão 7.4, você recebe uma mensagem de falha para algumas operações em recursos do Azure
Após uma migração bem-sucedida do vRealize Automation 7.3 para a versão 7.4, algumas operações, como a reinicialização, falham de maneira intermitente em recursos do Azure migrados. Essas falhas são relatadas no vRealize Automation, mesmo que o fluxo de trabalho do vRealize Orchestrator seja bem-sucedido.
Solução alternativa: Abra um novo prompt de comando, execute estes comandos, faça as edições solicitadas para aumentar os valores de tempo limite nas propriedades o11n-gateway e shindig-ui, e reinicie o vcac-server.
1. # cd /var/lib/vcac/server/webapps/vcac/WEB-INF/classes/
2. # cp shindig.properties shindig.properties.`date +%m%d%Y`
3. # vi shindig.properties
4. edit > shindig.http.client.read-timeout-ms=150000
5. # cd /usr/lib/vcac/server/webapps/o11n-gateway-service/WEB-INF/classes/META-INF/spring/root
6. # cp o11n-gateway-service-context.xml o11n-gateway-service-context.xml.`date +%m%d%Y`
7. # vi o11n-gateway-service-context.xml
8 edit >
to 150000
9. # service vcac-server restart
-
O vRealize Automation 7.1 não oferece suporte ao modo 130 do Microsoft SQL 2016
O banco de dados do Microsoft SQL 2016 criado durante a instalação do assistente do vRealize Automation está no modo 100. Se você criar manualmente um banco de dados do SQL 2016, ele também deverá estar no modo 100. Para obter informações relacionadas, consulte o artigo da Microsoft Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.
- A atualização do vRealize Automation não consegue atualizar o nó da web do IaaS primário
O sistema apresenta uma mensagem de erro semelhante a: "Erro ao atualizar o web.config do Model Manager Web: Falha na execução" ou "ERRO: Falha ao executar o comando upgrade-server no nó Mul-web1-2arm.sqa.local."
Solução alternativa: Sempre que o servidor de atualização falha no nó da web primária do IaaS após a atualização ser iniciada, o servidor Web do IaaS deve ser revertido juntamente com o banco de dados do Microsoft SQL para um estado anterior à atualização. Realize uma instalação manual dos componentes do IaaS.
Atualizações de segurança afetam a instalação silenciosa
Nesta versão, as atualizações de segurança da Microsoft 3098779 e 3097997 impedem que o novo recurso de instalação silenciosa funcione corretamente. As atualizações são as mesmas que afetam o verificador de pré-requisitos do Assistente de Instalação.
Solução alternativa: Antes da instalação silenciosa, você deve remover manualmente as atualizações dos servidores Windows IaaS. Concluída a instalação silenciosa, é possível reinstalar manualmente as atualizações 3098779 e 3097997.
- O provisionamento da máquina virtual do Azure falhará se o nome do grupo de recursos contiver caracteres que não sejam ASCII
O azure-java-sdk não é compatível com um nome de grupo de recursos que não seja ASCII.
Solução alternativa: Não use caracteres que não sejam ASCII em um nome do grupo de recursos.
- A coleta de dados de estado retorna apenas o IP Primário
Esse comportamento pode afetar sua capacidade de usar Conectar usando RDP, Conectar usando SSH ou registrar uma máquina virtual como host de contêiner no serviço de contêineres e outros que dependem do acesso a uma máquina virtual usando o endereço IP da máquina virtual.
Solução alternativa: Espera-se que o problema seja resolvido em uma versão futura.
Aparece uma mensagem de erro interno quando você adiciona uma máquina do Azure a um blueprint na guia Design
Ao usar um servidor externo do vRealize Orchestrator com o vRealize Automation, a integração do Microsoft Azure não estará disponível.
Solução alternativa: Exporte o plug-in e o pacote do Azure do vRealize Orchestrator interno no appliance virtual do vRealize Automation, e instale ou importe o plug-in e pacote para o vRealize Orchestrator externo. Após instalar o plug-in do Azure ou importar o pacote do Azure para o vRealize Orchestrator externo, o Microsoft Azure será compatível no ambiente do vRealize Automation.
- Faça login no Centro de Controle do vRealize Orchestrator para o vRealize Orchestrator interno no appliance virtual do vRealize Automation. Para obter mais instruções, consulte: Fazer login na interface de configuração do vRealize Orchestrator.
- Em Plug-Ins, clique em Gerenciar Plug-Ins.
- Localize o plug-in do Azure e clique com o botão direito em Baixar plug-in em arquivo DAR. Salve o arquivo em seu computador.
- Faça login no Centro de Controle do vRealize Orchestrator para o vRealize Orchestrator externo. Para obter mais instruções, consulte: Fazer login na interface de configuração do vRealize Orchestrator.
- Em Plug-Ins, clique em Gerenciar Plug-Ins.
- Em Instalar plug-in, clique em Navegar e localize o arquivo DAR do Azure que você baixou no computador.
- Clique em Instalar. Se solicitado a confirmar, clique em Instalar novamente.
- No Centro de Controle nas Opções de Início, clique em Reiniciar para concluir a instalação do novo plug-in.
- Faça reboot de todos os appliances virtuais do vRealize Automation ao mesmo tempo.
A funcionalidade de integração do Microsoft Azure estará restaurada.
Se a integração não funcionar corretamente após o reboot, verifique se o pacote do Azure, com.vmware.vra.endpoint.azure, está presente no vRealize Orchestrator externo. Se o pacote do Azure não estiver presente, realize estas etapas.
- Faça login no cliente do vRealize Orchestrator externo no appliance virtual do vRealize Automation.
- Exporte o pacote do Azure, com.vmware.vra.endpoint.azure. Para obter mais instruções, consulte Exportar um pacote.
- Faça login no cliente do vRealize Orchestrator para o vRealize Orchestrator externo.
- Importe o pacote do Azure, com.vmware.vra.endpoint.azure, para o vRealize Orchestrator externo. Para obter mais instruções, consulte Importar um pacote.
Solicitações concorrentes do catálogo de XaaS chamando a máquina virtual do Clone, sem fluxo de trabalho de personalização com 30 usuários, causam falha em algumas solicitações
Ao solicitar blueprints de XaaS que invocam fluxos de trabalho do vRealize Orchestrator para fazer algumas operações em endpoints lentos com alta concorrência, algumas das solicitações podem falhar com o erro java.net.SocketTimeoutException: Read timed out. Os fluxos de trabalho do vRealize Orchestrator também podem ser reativados múltiplas vezes devido à expiração das solicitações.
Solução alternativa: Realize estas etapas em todos os nós do appliance do vRealize Automation. O arquivo vcac.properties não é preservado na atualização. Você deve repetir estas etapas após atualizar.
- Abra uma sessão de SSH no appliance do vRealize Automation.
- Edite /etc/vcac/vcac.properties para aumentar o tempo de expiração do cliente para 10 minutos adicionando a linha a seguir ao arquivo: vco.socket.timeout.millis=600000
- No prompt de comando, execute este comando para reiniciar o serviço vcac-server: service vcac-server restart
- A coleta de dados do inventário para durante um failover do vCenter Server HA (VCHA)
Em raros casos, os itens de trabalho podem ficar congelados em andamento para um endpoint gerenciado do vSphere 6.5 durante um failover do VCHA.
Solução alternativa: Reinicie o agente do vRealize Automation vCenter. Se a coleta de dados ainda estiver congelada em andamento, entre em contato com o GSS.
- Há falha nas implantações de blueprint do vRealize Automation que incluem objetos NSX ao fazerem o provisionamento para um cluster no qual o NSX Manager tem a função secundária
Em uma implantação do NSX entre instâncias do vCenter, objetos universais do NSX, como gateways de borda, novas conexões virtuais e balanceadores de carga, devem ser provisionados utilizando o NSX Manager que tem a função primária. Se você tentar provisionar objetos universais para um NSX Manager secundário, o processo apresentará falha com um erro. O vRealize Automation não oferece suporte ao provisionamento de objetos universais do NSX a um endpoint do vSphere com rede e integração de segurança em que o NSX Manager especificado tenha a função secundária.
Solução alternativa: Para poder usar objetos globais do NSX, você deve criar conexões virtuais e de zonas de transporte locais do NSX específicas para cada região. Consulte o artigo da Base de Conhecimento 2147240 para obter detalhes sobre esse processo no VMware Validated Design.
-
As máquinas provisionadas para o Azure persistem após você excluir um endpoint do Azure
Excluir um endpoint do Azure deixa para trás máquinas órfãs, blueprints e reservas. Se você quiser excluir uma determinada máquina virtual do Azure antes de excluir um endpoint do Azure, exclua-o manualmente usando o console do vRealize Automation.
- Em um Mac, quando você abre um segundo VMware Remote Console para uma única máquina virtual, ambos os consoles ficam em branco
Embora você possa abrir mais de um VMware Remote Console para uma máquina virtual única no Windows, o VMRC não suporta sessões múltiplas. No Windows, cada console é um processo separado; em um Mac, cada console tenta mostrar um processo único.
Solução alternativa: Feche todas as instâncias VMRC e abra apenas uma VMRC para uma máquina em questão.
- O reprovisionamento de uma máquina virtual gerenciada no vSphere 6.5 durante um failover do vCenter High Availability (VCHA) exclui permanentemente a máquina virtual
Durante um failover VCHA com o vShpere 6.5, se você tiver um reprovisionamento com uma máquina virtual no mesmo endpoint do Vsphere, a máquina virtual poderá ser destruída. Esse é um evento raro.
Solução alternativa: Solicite o blueprint original para a máquina virtual destruída.</p>
-
O erro de credencias inválidas para o vRealize Automation aparece após o failover de alta disponibilidade do vCenter
Após um failover de VCHA em um endpoint VSphere 6.5, os registros do vRealize Automation podem conter esta mensagem de erro para o endpoint: Cannot complete login due to an incorrect user name or password.
Solução alternativa: Reinicie o agente do vRealize Automation vCenter.
-
Alterar uma reserva de máquina virtual não funciona quando o proprietário é diferente
Quando a operação de registro é invocada em máquina virtual gerenciada IaaS, a reserva utilizada deve pertencer ao proprietário atual da máquina virtual. Apenas o proprietário atual pode ser especificado para o parâmetro do usuário. Se um usuário que não for o proprietário atual for especificado, o sistema registrará na máquina virtual como se fosse pertencente a um proprietário na IaaS e a um proprietário diferente no catálogo.
Solução alternativa: Use apenas o fluxo de trabalho Alterar a reserva para uma máquina virtual IaaS para reservas que pertencem ao atual proprietário da máquina virtual.
-
Não é possível selecionar blueprints para importação em massa de máquinas não gerenciadas no vRealize Automation 7.1 para o 7.2
O IaaS passa um ID de tenant em caixa baixa para a API, que recupera blueprints para importação em lote, e não o caso apresentado pelo serviço de autorização. Se o usuário cria um ID de tenant que usa caracteres maiúsculos e minúsculos misturados, por exemplo Rainpole, em vez de rainpole, a procura apresenta falha:
Solução alternativa: Gere o arquivo CSV sem o nome ou componente do blueprint e, então, edite manualmente o arquivo CSV com os valores desejados para estes campos.
-
Contêineres aninhados não suportam redes
Você não pode adicionar uma rede a um contêiner aninhado.
Solução alternativa: Espera-se que o problema seja resolvido em uma versão futura.
-
Os conteúdos da janela não são exibidos adequadamente após se conectarem a uma máquina virtual no VSphere 6.5 usando o painel remoto.
Ao conectar a uma máquina hospedada em um endpoint do vSphere 6.5 usando o painel remoto, a conexão pode falhar ou de alguma forma ficar inutilizável.
Solução alternativa: Conecte à máquina afetada usando aplicação do cliente VMRC. Selecione Conectar usando o VMRC.
Alguns componentes podem não funcionar conforme o esperado depois de você arrastar um blueprint interno existente até um blueprint externo atual
As configurações do componente podem mudar dependendo do blueprint em que o componente está. Por exemplo, se você incluir grupos de segurança, tags de segurança ou redes sob demanda, tanto a nível de blueprint interno quanto de blueprint externo, as configurações no blueprint externo substituirão as que estão no blueprint interno. Os componentes de rede e de segurança têm suporte apenas no nível do blueprint externo, exceto para as redes existentes que funcionam no nível do blueprint interno.
Solução alternativa: Adicione todos os seus grupos de segurança, tags de segurança e redes sob demanda somente no blueprint externo.
-
Em um ambiente de alta disponibilidade, o Horizon falha ao realizar a autenticação após o failover
Solução alternativa: Após o failover, reinicie o appliance do vRealize Automation para restaurar a autenticação.
Se você criar um grupo de propriedades com um ponto no nome do grupo, não poderá usar a interface do usuário do vRealize Automation para editar esse grupo
Esse problema ocorre quando você cria um grupo de propriedades com um ponto no nome do grupo, por exemplo, propriedade.grupo. Se você usar a interface do usuário do vRealize Automation para editar esse grupo de propriedades, aparecerá uma página em branco. Você pode usar a API REST para editar esse grupo de propriedades.
Solução alternativa: evite o uso de um nome de grupo de propriedade que contém um ponto. Se isso for inevitável, use a API REST para editar o grupo.
Uma perda de comunicação entre o IaaS e o catálogo de serviços comuns durante o processo de destruição deixa a máquina virtual em um estado de descarte
Se a comunicação for perdida entre o IaaS e o catálogo de serviços comuns enquanto a solicitação de destruição estiver em andamento, mas antes de o vRealize Automation remover o registro da máquina virtual do banco de dados, a máquina permanecerá em um estado de descarte. Após a restauração da comunicação, a solicitação de destruição será atualizada com êxito ou com falha, mas a máquina ainda será visível. Embora a máquina seja excluída do endpoint, o nome permanece visível na interface de gerenciamento do vRealize Automation.
-
Quando se altera o nome do host do appliance do vRealize Automation, os serviços são marcados como não disponíveis
Solução alternativa: Se quaisquer serviços ficarem indisponíveis depois de você alterar o nome do host, reinicie o servidor do vRealize Automation.
-
Quando se ingressa em um domínio uma conta de domínio do Agente de gerenciamento em um Windows Server 2012 clonado, a conta de domínio do Agente de gerenciamento perde seus direitos sobre a chave privada do certificado de agente
Quando você usa um assistente de personalização para clonar uma máquina no vSphere que é parte de um domínio, a máquina deixa de ser parte desse domínio. Quando você ingressa novamente a máquina clonada no domínio, aparece a seguinte mensagem de erro no log do Agente de gerenciamento: CryptographicException - Keyset does not exist.
Solução alternativa: Para solucionar esse problema, use o procedimento a seguir para abrir e fechar as configurações da chave privada do certificado sem fazer quaisquer alterações.
- Localize o certificado utilizando o snap-in de certificados do Microsoft Management Console. O snap-in exibe a ID do agente na caixa de texto Nome Amigável.
- Selecione Todas as tarefas > Gerenciar chaves privadas.
- Clique em Avançado.
- Clique em OK.
- O arrastamento de um blueprint interno existente até um blueprint externo atual está restrito
Quando você arrastar um blueprint interno existente para um blueprint externo atual, as seguintes restrições se aplicarão se o blueprint interno tiver máquinas que ingressaram em grupos de segurança, tags de segurança ou redes sob demanda. Esse problema pode ocorrer também no caso de blueprints importados.
- O blueprint externo não pode conter um blueprint interno que contenha as configurações de rede sob demanda ou as configurações do balanceador de carga sob demanda. Não está disponível o uso de um blueprint interno que contém um componente de rede NSX sob demanda ou um componente do balanceador de carga sob demanda.
- Quando você adiciona grupos de segurança novos ou adicionais a máquinas no blueprint interno, as máquinas ingressam apenas em grupos de segurança novos adicionados como parte de um blueprint externo, mesmo que a página de criação de blueprint exiba grupos de segurança do blueprint interno e do blueprint externo.
- Quando você adiciona novas tags de segurança a máquinas internas de um blueprint externo, as tags de segurança originalmente associadas ao blueprint interno ficam indisponíveis.
- Quando você adiciona novas redes sob demanda a máquinas internas de um blueprint externo, as redes sob demanda originalmente associadas ao blueprint interno ficam indisponíveis. As redes existentes originalmente associadas no blueprint interno permanecem disponíveis.
Solução alternativa: Você pode resolver esse problema realizando uma das seguintes tarefas:
- Adicione grupos de segurança, tags ou redes sob demanda ao blueprint externo, mas não ao blueprint interno.
- Adicione grupos de segurança, tags ou redes existentes ao blueprint interno, mas não ao blueprint externo.
- O menu Atributo de Pesquisa do Diretório na página Adicionar Diretório contém informações incorretas
Algumas sequências de caracteres de código que aparecem primeiro no menu Atributo de Pesquisa do Diretório estão incorretas.Solução alternativa: clique no menu suspenso Atributo de Pesquisa do Diretório para exibir as sequências de caracteres corretas.
Ocorre um erro de recurso não encontrado ao solicitar um item de catálogo
Quando o vRealize Automation está no modo de alta disponibilidade, se o nó do banco de dados mestre apresentar falhas e um novo nó mestre não for promovido, todos os serviços que precisam de um acesso de gravação ao banco de dados falharão ou se corromperão temporariamente, até que um novo banco de dados mestre seja promovido.
Solução alternativa: não é possível evitar esse erro quando o banco de dados mestre está indisponível. É possível promover um novo banco de dados mestre para que esse erro desapareça e seja possível solicitar recursos.
As alterações não são salvas na página de Formulário de Blueprint de um blueprint do XaaS
Se você não clicar em Aplicar depois de atualizar cada campo na página de Formulário de Blueprint de um blueprint do XaaS, suas alterações não serão salvas.
A guia Itens não exibe informações sobre os serviços habilitados para um balanceador de carga
No caso de máquinas provisionadas por meio de um balanceador de carga associado ao vCloud Networking and Security, a guia Itens não exibe informações sobre os serviços habilitados para esse balanceador de carga.
-
Se uma máquina for destruída enquanto a operação de clonagem do vSphere estiver em andamento, a tarefa de clonagem de máquina em andamento não será cancelada
Esse problema pode causar a clonagem da máquina. A máquina virtual clonada pode ser gerenciada no vCenter e deixar de estar sob o gerenciamento do vRealize Automation.
-
Ao se solicitar um blueprint composto, a solicitação falhará imediatamente e o formulário de detalhes da solicitação não carregará
Quando o número máximo de dias de concessão para um blueprint de componente for menor que o número de dias de concessão do blueprint externo, as solicitações falharão imediatamente e o formulário de detalhes da solicitação não carregará.
-
As implantações com associações a endereços IP de DHCP não são possíveis em implantações de software
Se você tentar fazer isso, o endereço IP não permanecerá disponível se não houver nenhum perfil de rede. Esta mensagem de erro é exibida: Erro do sistema: Erro interno no processamento de solicitação de componente: com.vmware.vcac.platform.content.exceptions.EvaluationException: Nenhum dado para o campo: ip_address.
Solução alternativa: Se uma associação for necessária, utilize os endereços IP estáticos ou os endereços IP gerenciados pelo vRealize Automation no perfil de rede ou uma integração de IPAM. Se usar o DHCP, você deverá associar ao nome do host e não ao endereço IP.
Você pode usar o script a seguir para obter o endereço IP de uma máquina CentOS:
IPv4_Address = $(hostname -I | sed -e 's/[[:space:]]$//')
echo $IPv4_Address
Associe ao valor que esse script fornece quando o endereço IP for necessário para casos de uso de DHCP.
-
O diretório foi criado mesmo após uma mensagem de erro ter sido recebida
Quando você cria um diretório em Administration > Identity Stores Management > Identity Stores e clica em Salvar, a mensagem de erro: A comunicação do conector falhou devido a dados inválidos. Problema ao promover um bind DN do usuário ao administrador: o usuário já existe e está associado com uma sincronização de cliente diferente, pode aparecer. O novo Repositório de Identidades é salvo com uma configuração incorreta e não pode ser utilizado.
Isso acontecerá se você tentar salvar um novo Active Directory com os mesmos valores para a Base DN e o Bind DN que já foram usados com sucesso em um Active Directory criado previamente e existente.
Solução alternativa: Você deve excluir manualmente o novo Active Directory porque a configuração está incorreta e você sempre pode utilizar uma Bind DN e Base DN para o novo Active Directory.
Um domínio é adicionado a um UPN de usuário quando se cria um diretório que inclui o atributo de pesquisa de diretório de UserPrincipalName
Quando você cria um novo diretório e seleciona UserPrincipalName para o atributo de pesquisa de diretório, um domínio é adicionado a um UPN de usuário. Por exemplo, o nome de usuário do vRealize Automation de um usuário com o UPN usuário.domínio@domínio.local aparece como usuário.domínio@domínio.local@domínio.local. Isso acontece se o sufixo UPN estiver configurado no site de AD para ser o domínio. Se o sufixo UPN for personalizado, por exemplo, como "exemplo.com", o nome de usuário do vRealize Automation de um usuário com o UPN usuário.domínio@exemplo.com será exibido como usuário.domínio@exemplo.com@domínio.local.
Se for usado o atributo de pesquisa de diretório UserPrincipalName, os usuários deverão digitar os respectivos nomes de usuário exatamente como aparecem (usuário.domínio@domínio.local@domínio.local), incluindo o domínio, para fazer login a fim de utilizar a API REST ou o Cloud Client.
Solução alternativa: utilize sAMAccountName em vez de UserPrincipalName para usar a funcionalidade exclusiva do domínio do nome de usuário do Gerenciamento de diretórios.
O erro 404 Não Encontrado aparece quando se solicita uma máquina em nome de outro usuário
Se um blueprint incluir uma rede de NAT sob demanda ou um componente balanceador de carga sob demanda, aparecerá o erro 404 Não Encontrado quando se faz uma implantação solicitada em nome de outro usuário.
-
As máquinas importadas com a Importação em massa não são mapeadas para o blueprint convergido e para o blueprint de componente corretos
Solução alternativa: adicione a propriedade personalizada VMware.VirtualCenter.OperatingSystem a cada máquina no arquivo CSV de importação.
Por exemplo:
Yes,NNNNP2-0105,8ba90c35-9e03-4ac4-8a5d-2e6d76f37b81,development-res,ce-san-1:custom-nfs-2,UNNAMED_DEPLOYMENT-0105,BulkImport,Imported_Machine,system_blueprint_vsphere,user.admin@sqa.local,VMWare.VirtualCenter.OperatingSystem,sles11_64Guest,NOP
- Quando um usuário solicita a reconfiguração do caminho de rede de uma máquina, e o caminho de rede original não está selecionado na reserva da máquina, a solicitação parece ter êxito, e o vRealize Automation exclui silenciosamente de seu banco de dados o registro de placa de rede da máquina. Nenhuma alteração é feita na máquina real.
Não é suportada a reconfiguração do caminho de rede de uma máquina quando o caminho de rede original não está selecionado na reserva da máquina. Qualquer solicitação para fazer isso deve falhar com a mensagem de erro apropriada. Em vez disso, ela parece ter êxito e exclui silenciosamente do banco de dados do vRealize Automation o registro de placa de rede da máquina. A máquina real não é afetada.
Solução alternativa: Nenhuma. A visualização do vRealize Automation da máquina com relação ao registro de placa de rede será restaurada para seu estado original na próxima vez que a coleta de dados for executada para o cluster associado.
As ações de gerenciamento de catálogos não aparecem no vRealize Automation
Solução alternativa: Consulte o artigo 2113027 da Base de Conhecimento.
- Após um failover do vRealize Appliance, a página Integridade poderá demorar para carregar
Se a página Integridade estiver aberta antes do failover do vRealize Appliance, a página poderá demorar até 15 minutos para carregar pela primeira vez após o failover.
- O preço de uma implantação não é exato quando o blueprint contém um perfil de componente de imagem
Quando um perfil de componente de imagem é selecionado no momento de criação, o tamanho do disco de clone é desconhecido quando um usuário solicita uma máquina. Quando o usuário solicita o preço de uma máquina, o preço exibido não é exato. O preço não inclui o disco de clone no modelo que foi selecionado como parte do perfil de componente de imagem.
Solução alternativa: Quando um usuário solicita um item de catálogo, o custo de implantação é corrigido pelo vRealize Business após o vRealize Business incluir o tamanho do disco de clone que a máquina usa.
-
Depois de promover uma instância de réplica para a instância mestre, são exibidas informações incorretas na guia Banco de Dados, na interface de gerenciamento do nó mestre do vRealize Automation
Quando ocorre uma falha no nó mestre do appliance do vRealize Automation, é preciso usar a interface de gerenciamento do appliance do vRealize Automation do nó íntegro nas operações de gerenciamento de cluster.
- Uma operação de Destruição executada em um membro do cluster evita que as ações de dimensionamento horizontal ou dimensionamento vertical funcionem conforme o esperado
Após destruir manualmente uma máquina que faz parte de um cluster multi-máquina, você não poderá mais executar ações de pós-provisionamento de dimensionamento vertical e dimensionamento horizontal confiáveis. Você introduz uma contagem errada ao destruir manualmente um membro de um cluster usando a ação de destruição na máquina. Com uma contagem errada, uma operação de dimensionamento horizontal assume que a máquina destruída ainda é parte do cluster. Isso evita que uma operação de dimensionamento horizontal adicione algumas ou todas as máquinas necessárias. Se a contagem estiver incorreta por 1 máquina, e o limite de cluster for 5, poderá haver no máximo 4 máquinas virtuais reais e 1 máquina fantasma. Para uma ação de dimensionamento vertical, o serviço de composição poderá tentar dimensionar verticalmente para uma única máquina, resultando na destruição de todos os membros do cluster.
Solução alternativa: Para implantações em que as ações de dimensionamento horizontal ou dimensionamento vertical estão habilitadas, não autorize as ações de destruição. Isso evita a criação de uma contagem incorreta. Se você achar que sua implantação tem uma máquina em um cluster que foi destruído manualmente, um administrador poderá verificar isso contando o número de membros de cluster que aparecem na página Implantações. Se houver um cluster com uma máquina virtual destruída, reimplante a implantação e não autorize as ações de destruição na implantação reimplantada.
Mover um repositório de dados de um vSphere Storage DRS para outro faz com que o sistema exclua, em vez de criar, uma máquina virtual
Se você mover um repositório de dados de um cluster do vSphere Storage DRS para outro cluster do vSphere Storage DRS e o nível de automação do cluster do destino não for automático, o reprovisionamento de uma máquina criada fará com que o sistema exclua a máquina com o seguinte erro: Posicionamento do armazenamento: datastore não especificado para o disco na VM desabilitada para sdrs. Esse problema não acontecerá se a máquina virtual estiver clonada.
Solução alternativa: Verifique se o nível de automação do cluster de destino está definido como automático antes de mover um repositório de dados de um cluster do vSphere Storage DRS para outro. Somente há suporte para implantações de máquinas individuais.
- As implantações com vários balanceadores de carga exibem incorretamente os servidores virtuais do balanceador de carga
Em implantações com vários balanceadores de carga implantados no vRealize Automation 7.2 ou anteriores, cada balanceador de carga mostra servidores virtuais de todos os balanceadores de carga presentes na implantação.
Solução alternativa: Nenhuma.
- Após uma conexão de teste bem-sucedida e o salvamento do endpoint com uma impressão digital válida, os logs do agente do vSphere ou os logs DEM contêm mensagens de erro sobre uma conexão fechada, a incapacidade de estabelecer uma relação de confiança ou um certificado remoto é inválido
No vRealize Automation 7.3, os endpoints do vSphere e do NSX têm a validação de certificado habilitada. Você não pode mais usar um certificado não confiável com esses endpoints. Embora você possa usar o botão Testar Conexão para validar a impressão digital do certificado nesses endpoints, se o certificado for gerado de forma que o certificado raiz na cadeia de certificados não seja autoassinado, o processo de validação de certificado para esses dois endpoints poderá falhar e causar uma falha funcional nas ações de coleta de dados, de provisionamento ou de pós-provisionamento.
Solução alternativa:
Para o vSphere
Baixe o certificado raiz na cadeia de certificados do endpoint.
- Para o vCenter endpoint 6.0 ou posteriores, confira o artigo da Base de Conhecimento http://kb.vmware.com/kb/2108294.
- Para o vCenter endpoint 5.5 ou anteriores, baixe o certificado RAIZ do caminho de certificação do certificado do endpoint.
Conclua estas etapas.
- Primeiro baixe o certificado do endpoint acessando o endpoint diretamente no navegador.
- Vá para Caminho de Certificação para obter o certificado raiz.
- Baixe o certificado raiz na cadeia.
- Instale o certificado no armazenamento raiz Confiável das máquinas de Agente e do DEM.
Para o endpoint do NSX
- Baixe o certificado do endpoint acessando o endpoint diretamente no navegador.
- Vá para Caminho de Certificação para obter o certificado raiz.
- Baixe o certificado raiz na cadeia.
- Instale o certificado no armazenamento raiz Confiável das máquinas do DEM.
- A ação de pós-provisionamento Reconfigurar o balanceador de carga falha para um blueprint importado do YAML
Às vezes, quando você executa a ação de pós-provisionamento Reconfigurar o Balanceador de Carga em uma implantação, a ação falha. Isso acontece quando o blueprint associado à implantação é importado de um arquivo YAML que contém um balanceador de carga sob demanda com um valor no campo de nome diferente do valor no campo de ID.
Solução alternativa: Execute as seguintes etapas para corrigir o blueprint de modo a permitir que as ações de pós-provisionamento sejam executadas no balanceador de carga em implantações futuras. No console do vRealize Automation, selecione o blueprint que não possui valores correspondentes nos campos de nome e ID. Clique em Editar e insira novamente o nome do componente do balanceador de carga. Salve o blueprint. Isso define os valores de nome e ID incorporados no blueprint como o mesmo valor. Quando você fornece uma nova implantação usando o blueprint editado, a ação Reconfigurar o Balanceador de Carga funciona. É possível evitar esse problema ao se certificar de que todos os arquivos YAML tenham valores idênticos de nome e ID em cada componente do balanceador de carga sob demanda.
- O uso de dois pontos (:) como separador não é reconhecido corretamente em um arquivo YAML quando você cria um blueprint de contêiner do Windows
Esse problema ocorre quando você cria um blueprint com um volume de contêiner no qual o caminho do contêiner e o caminho do host incluem uma letra de unidade do Windows com dois pontos, por exemplo D:/DBFILES/:c:/temp/. Depois de salvar e abrir o blueprint, o valor do caminho do contêiner e do caminho do host não é reconhecido corretamente, pois os primeiros dois pontos da letra de unidade é mal interpretado como separador.
Solução alternativa: Nenhuma.
- A partição raiz fica sem espaço de armazenamento
A rotação incorreta de log no /var/lib/vrhb pode levar a uma alta utilização na partição raiz que eventualmente enche a partição /.
Solução alternativa: Consulte o artigo 2151693 da Base de Conhecimento.
- Não é possível provisionar novamente uma máquina virtual que foi provisionada com o System Center Virtual Machine Manager (SCVMM)
Antes do vRealize Automation 7.3, quando era feito novamente o provisionamento de uma máquina virtual que havia sido provisionada com SCVMM, o reprovisionamento falhava apresentando a seguinte mensagem de erro: "Fluxo de trabalho 'ScvmmCreateVM' falhou com a seguinte exceção: DynamicOps.Repository.Activities.PowerShellException: Você não pode chamar um método em uma expressão de valor nulo." Esse problema foi corrigido na versão 7.3. No entanto, se você atualizar o sistema para a versão 7.3 a partir de uma versão anterior, qualquer máquina provisionada com SCVMM antes da atualização ainda falha ao realizar o reprovisionamento.
Solução alternativa:
Conclua estas etapas.
- Faça login no Console do Gerenciador de máquina Virtual do SCVMM.
- No menu à esquerda, clique em Biblioteca > Modelos.
- Na tabela do painel direito, classifique os modelos por nome.
- Exclua todos os modelos que tenham o prefixo TemporaryTemplate, seguido por um GUID contendo uma sequência de letras e números.
- Depois de excluir os modelos, provisione novamente suas máquinas virtuais.
- Se uma propriedade de associação estiver configurada para ser transmitida para um script de software CMD do Windows, a propriedade de associação não será recebida pelo script no tempo de execução
Não há suporte para a transmissão de propriedades de entrada de associação a um script de software CMD do Windows. Todos os outros tipos de script de software, como o bash ou o Windows PowerShell, dão suporte à transmissão de propriedades a scripts de software como uma matriz de valores, mas o CMD do Windows não dá suporte ao tipo (argv) de matriz de argumentos.
Solução alternativa: Nenhuma.
- Erro 401 não autorizado recebido.
A interface de programação de aplicativos do vRealize Automation chama a interface de programação de aplicativos do VMware Identity Manager (vIDM). Porque o vIDM não oferece suporte a autenticação de API para um Provedor de Identidade externo ou de terceiros e para IDP de terceiros, a autenticação falha quando o IDP de terceiros é utilizado. No entanto, o IDP de terceiros é um pré-requisito para habilitar e configurar o recurso de provisionamento de usuário Just-in-Time (JIT) do vIDM. Assim os usuários JIT não podem se autenticar usando a API do vRealize Automation.
Solução alternativa: Autenticação de API, usando o tipo de senha de concessão OAuth2 requer que exista um dos seguintes métodos de autenticação de senha no vIDM:
- Autenticação de senha do conector
- Autenticação de senha (saída) do conector
- Senha de usuário local
- Senha Acc
Mesmo quando um IDP de terceiros é configurado para autenticação, uma das senhas deve existir. Para contornar esse problema, os usuários locais podem se autenticar usando a API do vRealize Automation.
- Falha na solicitação para retomar
A solicitação para retomar pode falhar nestas situações:
- A solicitação para retomar falha em uma solicitação de componente em que uma máquina é alocada com êxito, mas o provisionamento falha. Isso acontece quando o sistema tenta reprovisionar uma máquina usando as informações de alocação que não são mais válidas.
- Falha na solicitação para retomar em um blueprint aninhado. A operação de solicitação para retomar falha ao inicializar as solicitações do blueprint interno corretamente durante a recriação das solicitações do componente.
Solução alternativa: Nenhuma
- Um campo de XaaS que está vinculado ao _asd.requestInfo_~requestedBy ou _asd.requestInfo_~requestedFor é avaliado incorretamente quando o XaaS está em um blueprint de componente
Um campo de XaaS com uma restrição de valor que está vinculado ao _asd.requestInfo_, requestedFor ou requestedBy é avaliado para a última pessoa que editou e salvou o blueprint do XaaS.
Solução alternativa:
- Remova a restrição de valor do campo de XaaS vinculado.
- Defina um valor padrão nesse campo e vincule-o a _asd.requestInfo_~requestedBy~principalId.
- Exclua e arraste novamente o componente do XaaS para a tela de criação do blueprint composto.
- Salve o blueprint composto.
- Editar um adaptador de autenticação do conector pode requerer login
Os administradores podem usar o console do vRealize Automation para configurar Adaptadores de Autenticação para Conectores que correspondem a um diretório, dentro de até 30 minutos após fazer o login no console. Se um administrador tentar realizar essa configuração após 30 minutos, uma página de login será exibida e a autenticação será necessária.
Solução alternativa: Faça login, novamente, no console com credenciais de administrador.
- Você será solicitado a fazer login novamente no Gerenciamento do Appliance do vRealize Automation após ter feito o login com êxito
Após clicar em Gerenciamento de Patch no Gerenciamento do Appliance do vRealize Automation, você será solicitado a inserir suas credenciais novamente.
Solução alternativa: Autentique novamente como usuário raiz para usar a página de gerenciamento de patch.
- Quando o controlador de domínio primário não está disponível, o login é muito lento ou falha
Quando uma tentativa de entrar em contato com o controlador de domínio primário falha, o vIDM entra em contato com o controlador de domínio secundário. Em função do vIDM sempre entrar em contato com o controlador de domínio primário antes de entrar em contato com o controlador de domínio secundário, há um atraso no processamento das solicitações de login. Isso faz com que as solicitações se acumulem e reduzam a velocidade do sistema.
Solução alternativa: Consulte o artigo 52840 da Base de Conhecimento.
- Clicar nos botões Iniciar, Parar ou Reinicializar na guia Xenon, no Gerenciamento do Appliance do vRealize Automation, não afeta o serviço
Em um ambiente agrupado em cluster, as operações iniciar, parar ou reinicializar na guia Xenon, no Gerenciamento do Appliance do vRealize Automation Appliance, não afetarão o serviço se forem executadas de um nó de réplica.
Solução alternativa: As operações do serviço Xenon só devem ser executadas no nó mestre.
- Quando você inicia um navegador e abre o Gerenciamento do Appliance do vRealize Automation, uma mensagem de erro sobre um certificado autoassinado será exibida e não será possível prosseguir
Navegadores com HTTP Strict Transport Security (HSTS) habilitados impedem o acesso a sites com um certificado autoassinado.
Solução alternativa: Consulte o artigo 53533 da Base de Conhecimento.
- Em um ambiente em cluster do vRealize Automation, os appliances de réplica podem atingir 100% de utilização da CPU
Em um ambiente em cluster do vRealize Automation, os appliances de réplica podem atingir 100% de utilização da CPU devido a vários processos socat.
Solução alternativa: Consulte o artigo 54143 da Base de Conhecimento.
- Falha na sincronização do Active Directory
1. O AD tem mais de 200 mil usuários e 60 mil grupos.
2. O domínio de nível superior, como abc.com, é usado para sincronizar em vez de subdomínios, como subdomínio1.abc.com.
Sintoma:
o log do conector (localizado em /var/log/vmware/horizon folder of cafe) emite um erro:
2018-03-23 18:01:22,122 ERROR (SimpleAsyncTaskExecutor-168) [3259@JNJ;local@JNJ;127.0.0.1] com.vmware.horizon.directory.ldap.LdapConnector - Problem reading from LDAP directory: javax.naming.OperationNotSupportedException: [LDAP: error code 12 - 00002040: SvcErr: DSID-03140395, problem 5010 (UNAVAIL_EXTENSION), data 0
1. A sincronização do AD precisa ser realizada para cada UO individual, permitindo um máximo de 120 mil usuários e 40 mil grupos em uma UO.
2. As proteções precisam ser ignoradas na página Configurações de Sincronização > Proteções.
- A remoção de um host com mais de 400 contêineres falha com o erro de serialização
No vRealize Automation 7.2 e 7.3, a tentativa de remover um host de contêiner com mais de 400 contêineres pode falhar com o erro de serialização.
Solução alternativa: Remova os contêineres, 400 por vez, do host usando o console, API ou CLI do vRealize Automation e, em seguida, remova o host de contêiner.
