Consideraciones sobre el cambio de artefactos de vCenter Server

El cambio de usuarios, recursos o subredes reservados para IBM Cloud® for VMware Solutions puede afectar a las operaciones de gestión.

No edite los permisos globales del grupo ic4v-vCenter en la página Usuarios y grupos del cliente web de VMware vSphere®. Estos cambios incluyen cambiar el nombre de usuario, suprimir el usuario o cambiar su contraseña. Utilice el ID de usuario de host root. El ID de usuario de host ic4vroot se crea solo para su uso por parte de IBM.

ID de automatización

El ID de automatización es una cuenta de usuario que utilizan las operaciones automatizadas que se proporcionan en la consola de VMware Solutions.

Los usuarios y las contraseñas correspondientes a las operaciones automáticas de la consola no se deben modificar porque las operaciones de la consola que dependen de estas credenciales podrían fallar.

Cuentas de usuario específicas de servicio

Cada servicio crea una cuenta de usuario interna en VMware vCenter Server®. Esta cuenta es necesaria para que las operaciones de gestión asociadas a un servicio puedan conectarse a vCenter Server para realizar las operaciones en el servicio.

Para evitar interrupciones y problemas de conexión, si cambia el ID de usuario, la contraseña o los valores de caducidad de contraseña de esta cuenta de usuario, asegúrese de actualizar también la información en el servicio asociado.

El ID de usuario de esta cuenta tiene el formato service_name-truncated_service_uuid@test.local o service_name-truncated_service_uuid@example-domain.local. Por ejemplo, el ID de usuario que el servicio Veeam® utiliza para conectarse a vCenter Server para realizar copias de seguridad planificadas es Veeam-Veeam_uuid@test.local.

El valor service_name junto con el valor service_uuid se truncan a 20 caracteres.

Recursos VMware para instancias V1.9 y posteriores

Si el estado de la instancia VMware Cloud Foundation for Classic - Automated instancia es Disponible, puede modificar el VMware, el clúster, los conmutadores, los grupos de puertos, y nombres de almacenes de datos del Sistema de archivos de red del cliente (NFS) desde el VMware vSphere Web Client.

Revise las restricciones siguientes:

No cambie el nombre de la instancia automatizada ni el nombre de la máquina virtual vCenter Server.
No cambie el valor predeterminado del nombre del almacén de datos de gestión. El valor predeterminado es vsanDatastore para instancias de VMware vSAN™ y management-share para instancias de NFS.
No cambie los nombres ni elimine ninguna de las subredes de gestión creadas para las instancias automatizadas.
No modifique el nombre de los enlaces ascendentes de red que se crean durante el suministro.
No cambie el nombre ni elimine los componentes de NSX-T. Estas operaciones pueden generar fallos o retrasos de adición y eliminación. Los componentes de NSX-T con los nombres que se documentan en Convenciones de nomenclatura se utilizan cuando la automatización añade o elimina hosts, clústeres y servicios.
No cambie los nombres de servidor de VMware ESXi™ ni las direcciones IP porque están registrados para la resolución de DNS de Windows®. Los cambios podrían causar fallos durante el despliegue o fallos en las funciones de la instancia automatizada.

Recursos VMware para instancias V1.8 y anteriores

La siguiente tabla enumera las operaciones que podrían verse afectadas si el administrador de SSO cambia los recursos fuera de la consola IBM Cloud for VMware Solutions. Si se dispone de una solución de recuperación, también se muestra.

La tabla siguiente se aplica a las instancias desplegadas en V1.8 y anteriores, incluidas las que se desplegaron inicialmente en V1.8 y anteriores y luego se actualizaron a V1.9 o posteriores.

Operaciones que se ven afectadas por los cambios en los recursos VMware
Cambio intentado	Operaciones afectadas	Gravedad	Método recuperación
Cambiar el nombre del centro de datos virtual de VMware.	La adición de un centro de datos virtual de VMware puede fallar porque el nuevo servidor ESXi no se puede unir al centro de datos virtual modificado.	Importante	Vuelva a cambiar el nombre del centro de datos virtual de VMware por el nombre original.
Cambiar cualquier nombre de grupo de puertos.	La adición de un servidor ESXi puede fallar.	Importante	Vuelva a cambiar el nombre del grupo de puertos por el nombre original.
Cambiar el nombre de clúster.	La adición de un servidor ESXi puede fallar.	Importante	Vuelva a cambiar el nombre del clúster por el nombre original.
Cambiar el nombre del conmutador virtual distribuido (DVS) público o privado.	La adición de un servidor ESXi puede fallar.	Importante	Cambie el nombre del conmutador virtual distribuido (DVS) público o privado por el nombre original.
Cambie el nombre del almacén de datos de vSAN en la instancia que utiliza vSAN.	La adición de un servidor ESXi puede fallar. La actualización de la instancia puede fallar.	Importante	Vuelva a cambiar el nombre del almacén de datos de vSAN por el nombre original, vsanDatastore.
Cambie el nombre del almacén de datos de NFS de gestión en la instancia que utiliza NFS.	La adición de un servidor ESXi puede fallar. La actualización de la instancia puede fallar.	Importante	Vuelva a cambiar el nombre del almacén de datos de NFS por el nombre original, management-share, y vuelva a montar el almacén de datos de NFS como de solo lectura en el servidor ESXi.

En la tabla siguiente se muestran las operaciones que podrían verse afectadas si se inhabilita el acceso SSH o shell para diversos recursos.

Operaciones afectadas por SSH y el acceso shell (local)
Cambio intentado	Operaciones afectadas	Gravedad	Método recuperación
Deshabilite el acceso SSH o shell para vCenter Server o PSC	El emparejamiento de una instancia primaria y secundaria puede fallar.	Importante

Si opta por inhabilitar el acceso SSH o shell, vuelva a habilitarlo temporalmente antes de completar las operaciones indicadas.

Subredes de gestión para instancias automatizadas

En la siguiente información se describen las subredes solicitadas por VMware Solutions y se proporcionan opciones para solicitar subredes adicionales para su propio uso.

Con cada pedido de servidor nativo de IBM Cloud, se solicitan de forma predeterminada los siguientes rangos de direcciones IP:

Un rango público primario de 32 direcciones IP
Un rango privado primario de 64 direcciones IP

Además, las siguientes subredes de gestión también están reservadas para IBM Cloud for VMware Solutions:

Dos subredes privadas portátiles de 64 direcciones IP en la primera VLAN: uno para la gestión y la otra para VTEPS
Dos subredes privadas portátiles de 64 direcciones IP en la segunda VLAN: uno para VMotion y una para vSAN
Una subred pública portátil de 16 direcciones IP en la VLAN pública

No utilice estos componentes para otros fines, no modifique sus nombres ni los suprima, o la estabilidad de su entorno se verá gravemente comprometida.

Si necesita utilizar más subredes, puede obtener las direcciones IP que puede utilizar de una de las siguientes formas.