Redirecionar vCenter Server para outro vCenter Server em um domínio diferente

Você pode mover um vCenter Server de um domínio vSphere para outro domínio vSphere. Serviços como marcação e licenciamento são retidos e migrados para o novo domínio.

Os seguintes casos de uso são compatíveis:

Você pode migrar um vCenter Server de um domínio existente para outro domínio existente com ou sem replicação. O vCenter Server migrado é movido do domínio de Single Sign-On atual e ingressa no outro domínio existente como outro vCenter Server conectado por meio do modo vinculado avançado.
- Consulte Redirecionar um único nó vCenter Server para um domínio existente sem um parceiro de replicação para obter instruções sobre como redirecionar um único nó incorporado de um domínio para um domínio existente sem um parceiro de replicação.
- Consulte Redirecionar um nó do vCenter Server para um domínio existente com um parceiro de replicação para obter instruções sobre como redirecionar um nó incorporado de um domínio para um domínio existente usando a replicação.
Você pode migrar um vCenter Server de um domínio existente para um domínio recém-criado (em que o vCenter Server migrado é a primeira instância). Consulte Reapontar um nó vCenter Server para um novo domínio para obter instruções sobre esse tipo de redirecionamento. Nesse caso, não há parceiro de replicação.

Redirecionar um único nó vCenter Server para um domínio existente sem um parceiro de replicação

Você pode redirecionar um único vCenter Server de um domínio de Single Sign-On para um domínio de Single Sign-On existente sem um parceiro de replicação. Cada domínio de Single Sign-On contém um único vCenter Server.

Consulte Redirecionando um único vCenter Server de um domínio para um domínio existente para obter um exemplo de redirecionamento de um único vCenter Server de um domínio para outro domínio existente. Essa é uma das muitas maneiras de criar um nó Modo Vinculado Avançado. Nesse caso, não há replicação.

Os nós vCenter Server antes e depois do redirecionamento de um domínio para um domínio existente. — Figura 1. Redirecionando um único vCenter Server de um domínio para um domínio existente

Pré-requisitos

O redirecionamento só é compatível com o vCenter Server 6.7 Atualização 1 e posterior.
Você deve apontar novamente para um vCenter Server que seja da mesma versão.
Para garantir que não haja perda de dados, faça um backup baseado em arquivo de cada nó antes de prosseguir com o redirecionamento do vCenter Server.

Procedimento

Certifique-se de que ambos os nós vCenter Server estejam ligados antes de iniciar o processo de redirecionamento.
(Opcional) Execute o comando do modo de pré-verificação. O modo de pré-verificação busca os dados de marcação (tags e categorias) e de autorização (funções e privilégios) do vCenter Server. A pré-verificação não migra nenhum dado, mas verifica se há conflitos entre a origem e o destino vCenter Server. Por exemplo, execute a pré-verificação com a seguinte CLI:
```
cmsso-util domain-repoint -m pre-check --src-emb-admin Administrator --replication-partner-fqdn FQDN_of_destination_node --replication-partner-admin PSC_Admin_of_destination_node --dest-domain-name destination_PSC_domain
```
Observação: A pré-verificação não será necessária se um parceiro de replicação não existir (redirecionando para um domínio recém-criado).

Consulte Sintaxe do comando Domain Repoint para obter definições de argumentos para o comando cmsso-util domain-repoint.

A pré-verificação grava os conflitos no diretório /storage/domain-data.
(Opcional) Revise os conflitos e aplique resoluções para todos os conflitos ou aplique uma resolução separada para cada conflito.
As resoluções de conflito são:
- Copiar: crie uma cópia duplicada dos dados no domínio de destino.
- Ignorar: Ignora a cópia dos dados no domínio de destino.
- Mesclar: mescla o conflito sem criar duplicatas.
Observação: O modo de resolução padrão para conflitos de Etiquetas e Autorização é Copiar, a menos que seja substituído nos arquivos de conflito gerados durante a pré-verificação.
Execute o comando execute. No modo de execução, os dados gerados durante o modo de pré-verificação são lidos e importados para o nó de destino. Em seguida, o vCenter Server é redirecionado para o domínio de destino. Por exemplo, ao redirecionar sem um parceiro de replicação, execute o comando execute com o seguinte:
```
cmsso-util domain-repoint -m execute --src-emb-admin Administrator --replication-partner-fqdn FQDN_of_destination_node --replication-partner-admin PSC_Admin_of_destination_node --dest-domain-name destination_PSC_domain
```
Consulte Sintaxe do comando Domain Repoint para obter definições de argumentos para o comando cmsso-util domain-repoint.

Redirecionar um nó do vCenter Server para um domínio existente com um parceiro de replicação

Você pode redirecionar um vCenter Server de um domínio de Single Sign-On para um domínio existente usando um parceiro de replicação.

Consulte Reapontando um vCenter Server de um domínio para um domínio existente para obter um exemplo de redirecionamento para um domínio existente. Nesse caso, há replicação.

Os nós vCenter Server antes e depois do redirecionamento de um domínio para um domínio existente com um parceiro de replicação. — Figura 2. Reapontando um vCenter Server de um domínio para um domínio existente

Pré-requisitos

O redirecionamento só é compatível com o vCenter Server 6.7 Atualização 1 e posterior.
Você deve apontar novamente para um vCenter Server que seja da mesma versão.
Para garantir que não haja perda de dados, faça um backup baseado em arquivo de cada nó antes de prosseguir com o redirecionamento do vCenter Server.

Procedimento

Encerre o nó (por exemplo, Nó C) que está sendo redirecionado (movido para um domínio diferente).
Desautorize o nó vCenter Server que está sendo redirecionado. Por exemplo, para encerrar o Nó C, faça login no Nó B (no domínio original) e execute o seguinte comando:
```
cmsso-util unregister --node-pnid Node_C_FQDN --username Node_B_sso_administrator@sso_domain.com --passwd Node_B_sso_adminuser_password
```
Após cancelar o registro do Nó C, os serviços são reiniciados. As referências ao Nó C são excluídas do Nó B e de quaisquer outros nós que estavam vinculados ao Nó C no domínio original.
Ligue o Nó C para iniciar o processo de redirecionamento.
(Opcional) Execute o comando do modo de pré-verificação. O modo de pré-verificação busca os dados de marcação (tags e categorias) e de autorização (funções e privilégios) do vCenter Server. A pré-verificação não migra nenhum dado, mas verifica os conflitos entre a origem e o destino vCenter Server. Por exemplo, execute a pré-verificação com a seguinte CLI:
```
cmsso-util domain-repoint -m pre-check --src-emb-admin Administrator --replication-partner-fqdn FQDN_of_destination_node --replication-partner-admin PSC_Admin_of_destination_node --dest-domain-name destination_PSC_domain
```
Observação: A pré-verificação não será necessária se um parceiro de replicação não existir (redirecionando para um domínio recém-criado).

Consulte Sintaxe do comando Domain Repoint para obter definições de argumentos para o comando cmsso-util domain-repoint.

A pré-verificação grava os conflitos no diretório /storage/domain-data.
(Opcional) Verifique os conflitos e aplique resoluções para todos os conflitos ou aplique uma resolução separada para cada conflito.
As resoluções de conflito são:
- Copiar: crie uma cópia duplicada dos dados no domínio de destino.
- Ignorar: Ignora a cópia dos dados no domínio de destino.
- Mesclar: mescla o conflito sem criar duplicatas.
Observação: O modo de resolução padrão para conflitos de Etiquetas e Autorização é Copiar, a menos que seja substituído nos arquivos de conflito gerados durante a pré-verificação.
Execute o comando execute. No modo de execução, os dados gerados durante o modo de pré-verificação são lidos e importados para o nó de destino. Em seguida, o vCenter Server é redirecionado para o domínio de destino. Por exemplo, execute o comando execute com o seguinte:
```
cmsso-util domain-repoint -m execute --src-emb-admin Administrator --replication-partner-fqdn FQDN _of_destination_node --replication-partner-admin destination_node_PSC_Admin_user_name --dest-domain-name destination_PSC_domain
```
Consulte Sintaxe do comando Domain Repoint para obter definições de argumentos para o comando cmsso-util domain-repoint.

Reapontar um nó vCenter Server para um novo domínio

Você pode redirecionar um vCenter Server de um domínio existente para um domínio recém-criado.

Consulte Reapontando um vCenter Server de um domínio para um novo domínio para obter um exemplo de redirecionamento para um novo domínio. Nesse caso, não há parceiro de replicação.

Os nós vCenter Server antes e depois de redirecionar de um domínio para um novo domínio sem um parceiro de replicação. — Figura 3. Reapontando um vCenter Server de um domínio para um novo domínio

Pré-requisitos

O redirecionamento só é compatível com o vCenter Server 6.7 Atualização 1 e posterior.
Você deve apontar novamente para um vCenter Server que seja da mesma versão.
Para garantir que não haja perda de dados, faça um backup baseado em arquivo de cada nó antes de prosseguir com o redirecionamento do vCenter Server.

Procedimento

Encerre o nó (por exemplo, Nó C) que está sendo redirecionado (movido para um domínio diferente).
Desautorize o nó vCenter Server que está sendo redirecionado. Por exemplo, para encerrar o Nó C, faça login no Nó B (no domínio original) e execute o seguinte comando:
```
cmsso-util unregister --node-pnid Node_C_FQDN --username Node_B_sso_administrator@sso_domain.com --passwd Node_B_sso_adminuser_password
```
Após cancelar o registro do Nó C, os serviços são reiniciados. As referências ao Nó C são excluídas do Nó B e de quaisquer outros nós que estavam vinculados ao Nó C no domínio original.
Ligue o Nó C para iniciar o processo de redirecionamento.
Execute o comando execute. No modo de execução, os dados gerados durante o modo de pré-verificação são lidos e importados para o nó de destino. Em seguida, o vCenter Server é redirecionado para o domínio de destino. Por exemplo, redirecionando sem parceiro de replicação (redirecionando para um novo domínio), execute o comando execute com o seguinte:
```
cmsso-util domain-repoint -m execute --src-emb-admin Administrator  --dest-domain-name destination_PSC_domain
```
Consulte Sintaxe do comando Domain Repoint para obter definições de argumentos para o comando cmsso-util domain-repoint.

Sintaxe do comando Domain Repoint

Você pode usar argumentos de comando para definir os parâmetros de execução do comando domain repoint.

A CLI cmsso-util domain-repoint redireciona vCenter Server de um domínio para outro.

Você pode adicionar uma lista de argumentos separada por espaços ao comando repoint da CLI

Use o seguinte comando para redirecionar um vCenter Server para outro nó vCenter Server:

cmsso-util domain-repoint -m execute --src-emb-admin Administrator --replication-partner-fqdn FQDN _of_destination_node --replication-partner-admin destination_node_PSC_Admin_user_name --dest-domain-name destination_PSC_domain


Argumento	Descrição
-m, --mode	`mode` pode ser pre-check ou execute. O argumento pre-check executa o comando no modo de pré-verificação. O argumento execute executa o comando no modo de execução.
-spa, --src-psc-admin	Nome de usuário do administrador de SSO para a origem vCenter Server. Não anexe o @`domínio`.
-dpf, --dest-psc-fqdn	O FQDN do vCenter Server a ser redirecionado.
-dpa, --dest-psc-admin	Nome de usuário do administrador de SSO para o destino vCenter Server. Não anexe @`domínio`.
-ddn, --dest-domain-name	Nome de domínio de SSO do destino vCenter Server.
-dpr, --dest-psc-rhttps	(Opcional) Porta HTTPS para o destino vCenter Server. Se não for definido, o padrão 443 será usado.
-dvf, --dest-vc-fqdn	O FQDN do vCenter Server apontando para um destino vCenter Server. O vCenter Server é usado para verificar conflitos de dados do componente no modo de pré-verificação. Se não for fornecida, as verificações de conflito serão ignoradas e a resolução padrão (CÓPIA) será aplicada a quaisquer conflitos encontrados durante o processo de importação. Observação: Esse argumento é opcional apenas se o domínio de destino não tiver um vCenter Server. Se existir um vCenter Server no domínio de destino, esse argumento será obrigatório.
-sea, --src-emb-admin	Administrador do vCenter Server com vCenter Server incorporado. Não anexe @domain à ID do administrador.
-rpf, --replication-partner-fqdn	(Opcional) O FQDN do nó do parceiro de replicação para o qual o vCenter Server é replicado.
-rpr, --replication-partner-rhttps	(Opcional) A porta HTTPS para o nó de replicação. Se não for definido, o padrão será 443.
-rpa, --replication-partner-admin	(Opcional) Nome de usuário do administrador de SSO do parceiro de replicação vCenter Server.
-dvr, --dest-vc-rhttps	(Opcional) A porta HTTPS para o vCenter Server apontando para o destino vCenter Server. Se não for definido, o padrão 443 será usado.
--ignore-snapshot	(Opcional) Ignore os avisos de snapshot.
--no-check-certs	(Opcional) Ignore as validações de certificação.
--debug	(Opcional) Recupera os detalhes da execução do comando.
-h, --help	(Opcional) Exibe a mensagem de ajuda para o comando cmsso-util domain repoint.

Noções básicas sobre conflitos de marcação e autorização

Quando você executa o comando domain repoint no modo de pré-verificação, os dados do vCenter Server são exportados, examinados e os conflitos são gravados em um arquivo.

Os seguintes dados são exportados para a pasta /storage/domain-data/ ou ProgramData/VMWare/vCenterServerdata/domain-data:

All_Privileges.json
All_Roles.json
All_TagCategories.json
All_Tags.json

Esses arquivos contêm todos os dados (autorização e marcação) do vCenter Server no qual esse comando foi executado.

Se um vCenter Server secundário for fornecido usando a opção -dvf ou --dest-vc-fqdn , quaisquer conflitos também serão exportados para a mesma pasta:

Conflicts_Roles.json
Conflicts_TagCategories.json
Conflicts_Tags.json

Veja a seguir um arquivo de conflitos de amostra:

<---- Sample Conflict file code block --->
	 {
  "global" : {
    "resolution" : "MERGE|SKIP|COPY",
    "description" : "Default resolution option used to resolve Role Conflicts is COPY. The 
conflicts list describes the differences between Role entities on source and target vCenter Server. If 
the source information represents an empty JSON array, it simply means that all the entity 
attributes from source and target are identical. If the source lists few entries, it means 
that only these entity attributes are missing from the target. If the target lists few entries, 
it means that only these entity attributes are missing from the source. Though a global resolution 
can be set, it can also be overridden at each conflict level by providing individual resolution 
mode."
  },
  "conflicts-count" : 1,
  "conflicts-list" : {
    "NoCryptoAdmin" : {
      "source" : {
        "privileges" : "[]"
      },
      "target" : {
        "privileges" : "[Group-1.SamplePriv-1, Group-1.SamplePriv-4, Group-2.SamplePriv-10, 
Group-2.SamplePriv-3, Group-2.SamplePriv-7, Group-3.SamplePriv-2, Group-3.SamplePriv-9]"
      },
      "resolution" : ""
    }
}
<----- End of code block --->

As partes dos arquivos de conflito de amostra são:

description. Fornece os detalhes sobre como o respectivo arquivo de conflitos é lido e entendido.
source e target. Objetos JSON que listam apenas as diferenças entre os objetos vCenter Server de origem e de destino.
resolution. O usuário fornece uma resolução válida. As resoluções válidas são MERGE, COPY e SKIP.

Para especificar a resolução para tratamento de conflitos, você pode fornecer uma opção de resolução padrão para todos os conflitos na seção "global": "resolution" = "MERGE|SKIP|COPY". Se você não fornecer um tipo de resolução global válido para resolution ou deixá-lo sem edição, o sistema usará COPY como a opção de resolução padrão.

Você também pode fornecer uma opção de resolução válida para cada um dos conflitos editando a propriedade resolution em cada nível de conflito que substitui a opção de resolução global.

Os tipos de conflitos listados em Tipos de conflito.

Tabela 1. Tipos de conflito
Conflito	Propriedades usadas para comparar objetos de categoria	Tipos de conflito	Propriedades conflitantes	Opções de resolução de conflitos
Conflito de papéis	`name`: Nome da categoria. `privilegeId`: lista de privilégios para a função.	Ocorre um conflito de `RoleName` ao importar funções e uma função com o mesmo nome existe no destino vCenter Server, mas com privilégios diferentes.	As propriedades que podem ser conflitantes para o tipo de conflito `RoleName` podem ser `Privileges`.	`COPY`. Uma cópia da função conflitante é criada no destino vCenter Server, com `–-copy` anexado ao nome da função. A nova função é criada com uma nova ID de função com o mesmo conjunto de IDs de privilégios. A nova ID de função é atualizada na tabela `VPX_ACCESS`. A nova ID de função é aplicável tanto para conflito de nome de função quanto para conflito de ID de função. Observação: A opção de resolução padrão para resolver conflitos de função é `COPY`. `MERGE`. A opção `MERGE` é resolvida na seguinte sequência: Se a origem vCenter Server tiver uma função com o mesmo nome e a mesma lista de privilégios que uma função no destino vCenter Server, mas as IDs da função forem diferentes, a ID da função do destino vCenter Server será usada e atualizada no `VPX_ACCESS` } tabela. Se a origem vCenter Server tiver uma função com o mesmo nome que uma função no destino vCenter Server, mas com uma lista de privilégios diferente, as listas de privilégios de ambas as funções serão mescladas. `SKIP`. Não faça nada. A função específica é ignorada.
Conflito de categoria de tag: um nome de categoria deve ser exclusivo em um vCenter Server.	`name`: Nome da categoria. `cardinality`: Cardinalidade da Categoria, Simples ou Múltipla. `associableEntityType`: lista de objetos vCenter Server que podem ser associados a uma tag desta categoria. Um valor de `All` indica todos os objetos vCenter Server.	Somente um tipo de conflito pode ser visto durante a importação de categorias de tags, conflito `CategoryName`. Esse conflito indica que existe uma categoria com o mesmo nome no destino vCenter Server, mas com propriedades diferentes (`cardinality` ou `associableEntityType`).	As propriedades que podem ser conflitantes para o tipo de conflito `CategoryName` podem ser pelo menos um dos dois tipos: `Cardinality` ou `AssociableTypes`.	`COPY`. Uma cópia da categoria conflitante é criada no destino vCenter Server, com `–-copy` anexado ao nome da categoria. A nova categoria é criada com o mesmo nome de propriedade que na origem vCenter Server. Todas as tags que estavam presentes nesta categoria são importadas sob o `CategoryCopy` recém-criado. Observação: A opção de resolução padrão para resolver `CategoryName` conflitos é `COPY`. `MERGE`. As propriedades conflitantes são mescladas com a categoria que já está presente no SSO. As propriedades são mescladas da seguinte forma: `Description`. A descrição que já está presente é usada. `Cardinality`. A cardinalidade não pode diminuir. Se houver um conflito de cardinalidade, a cardinalidade será definida como `multiple`. Não pode ser reduzido a único. `AssociableTypes`. Se os valores de `associableEntityType` forem nulos, ele será definido como nulo. Caso contrário, os tipos `Objects` serão mesclados. `SKIP`. Não faça nada. Todas as tags são importadas na categoria existente.
Conflito de tags: um objeto `tag` sempre pertence a um objeto `category`. Uma tag Name deve ser exclusiva apenas dentro de uma categoria.	`name` `description`	Somente um tipo de conflito pode ser visto durante a importação de tags: conflito de `TagName`. Esse conflito indica que uma Tag com o mesmo nome existe na mesma categoria e no destino vCenter Server, mas com propriedades diferentes.	Propriedades que podem ser conflitantes para um conflito do tipo: `TagName` pode ser `Description`.	`COPY`. Uma cópia da tag conflitante é criada no destino vCenter Server, com `–-copy` anexado ao nome da tag. Pegue o `MoRef`(ID da tag interna) da tag recém-criada e atualize a associação da tag, se necessário. Observação: A opção de resolução padrão para resolver `CategoryName` conflitos é `COPY`. `MERGE`.Mantenha a descrição existente. Pegue o `MoRef`(ID da tag interna) e atualize uma ou mais associações de tags, se necessário. `SKIP`. Não faça nada. Não crie essa tag. Limpe todas as associações de tags.

vCenter Server Considerações sobre a licença de redirecionamento de domínio

O redirecionamento de domínio copia as chaves de licença para um novo domínio. A cópia das chaves de licença garante que o licenciamento válido de todos os ativos seja mantido após o redirecionamento.

vCenter Server rastreia o uso da licença por domínio. Se uma chave for usada em mais de um domínio, você deverá garantir que o uso agregado da chave não exceda sua capacidade. Para simplificar o gerenciamento de licenças, remova cada licença copiada para um segundo domínio e atribua uma nova licença aos ativos.

Considere os dois casos a seguir:

Chaves de licença que não estão mais em uso (ou seja, atribuídas a ativos) no domínio original após o redirecionamento.
Chaves de licença que estão em uso (ou seja, atribuídas a ativos) em vários domínios.

Chaves de licença que não estão em uso em um domínio

Se depois de concluir o redirecionamento, uma chave de licença aparecer em mais de um domínio, mas não estiver em uso em alguns desses domínios, você poderá removê-la de qualquer domínio no qual ela não esteja em uso. Consulte "Remover licenças" em vCenter Server e gerenciamento de host para obter instruções sobre como remover as licenças em vCenter Server.

Chaves de licença em uso em vários domínios

Se depois de concluir o redirecionamento, uma chave de licença estiver em uso (ou seja, atribuída a ativos) em mais de um domínio, para remover a chave de licença de todos os domínios, exceto um, primeiro uma chave de licença diferente deverá ser atribuída a cada ativo nos domínios de qual a chave de licença será removida. Duas abordagens comuns:

Se você tiver outras chaves de licença disponíveis com capacidade não utilizada suficiente, poderá usar essas outras chaves no lugar de uma chave de licença a ser removida. Consulte "Atribuir uma licença a vários ativos" em vCenter Server e gerenciamento de host para atribuir licenças em vCenter Server.
Você pode dividir as chaves de licença usadas em mais de um domínio em chaves de licença separadas, uma para cada domínio. Para dividir as chaves de licença, consulte o artigo da base de conhecimento VMware em http://kb.vmware.com/kb/2006972. Para determinar a capacidade a ser incluída em cada uma das chaves de licença em que o original está dividido, consulte "Visualizando informações de licenciamento" em vCenter Server e gerenciamento de host para visualizar o uso da chave de licença em vCenter Server para cada um dos domínios.
Cada uma das chaves de licença resultantes pode então ser adicionada a um domínio diferente e atribuída em vCenter Server aos ativos anteriormente licenciados com a chave de licença original. Consulte "Criar novas licenças" em vCenter Server e gerenciamento de host para criar licenças e "Atribuir uma licença a vários ativos" em vCenter Server e gerenciamento de host para atribuir uma licença a vários ativos.

Depois que diferentes licenças forem atribuídas a todos os ativos, a chave de licença original, que não é mais válida, poderá ser removida de todos os domínios usando vCenter Server. Consulte "Remover licenças" vCenter Server e gerenciamento de host.