Si llevas años administrando entornos VMware, seguro que Host Profiles te suena. Y seguramente también te suena esa sensación de que funciona, sí, pero no siempre resulta cómodo de mantener cuando el clúster crece, cambian cosas o simplemente quieres tocar una parte concreta de la configuración sin pelearte con todo lo demás.
Aquí es donde entra vSphere Configuration Profiles.
VMware lleva ya tiempo empujando este cambio. La función apareció con vSphere 8, en la rama 8.x ya se posicionaba como gestión de configuración basada en estado deseado, y en vSphere 9 Host Profiles ya figura como deprecated, aunque sigue soportado por ahora. O dicho más claro: no ha desaparecido todavía, pero el camino nuevo ya está bastante marcado.
Además, en los últimos meses VMware ha publicado contenido oficial bastante claro sobre la transición desde Host Profiles y también sobre cómo automatizar todo esto con APIs, PowerCLI, Python e incluso un enfoque GitOps. No es una idea a futuro. Es algo que ya están enseñando a usar de forma seria.
Qué es exactamente vSphere Configuration Profiles
La idea es bastante más simple de lo que parece cuando lees el nombre.
Con vSphere Configuration Profiles pasas a gestionar la configuración de los hosts a nivel de clúster y con enfoque de desired state, es decir, defines cómo debería estar el clúster y vSphere se encarga de comprobar cumplimiento, detectar drift y aplicar correcciones donde toque. VMware lo describe justo así: gestión colectiva de la configuración de todos los hosts del clúster y validación frente a un estado deseado.
La diferencia importante frente a Host Profiles es que aquí ya no vas tan orientado a “copiar el host entero” como a trabajar con una configuración más manejable, más legible y más pensada para cambios concretos. En el propio post oficial de transición VMware explica que Host Profiles obliga a definir la configuración completa del host, mientras que Configuration Profiles solo requiere definir los cambios respecto a la configuración por defecto, lo que hace el documento más legible y bastante más mantenible.
Y esto, dicho en lenguaje de administración del día a día, se nota bastante.
Con Host Profiles muchas veces tenías la sensación de que estabas moviendo una mole enorme para cambiar una cosa pequeña. Con Configuration Profiles la lógica se acerca más a cómo trabajamos de verdad: quiero un estado común, quiero saber si alguien se ha desviado y quiero corregirlo sin montar una película.
Por qué Host Profiles se queda corto
Host Profiles no deja de ser útil, pero tiene varios problemas cuando sales del escenario simple.
El primero es que se vuelve pesado de mantener. Cuando una solución te obliga a pensar en la configuración entera del host cada vez que haces cambios, acabas con más fricción de la necesaria. VMware lo reconoce de forma bastante directa en su artículo de marzo de 2026: ese enfoque completo termina siendo poco manejable porque muchas veces el administrador solo conoce y solo quiere tocar los cambios concretos que necesita hacer.
El segundo problema es operativo. En un entorno moderno ya no quieres solo “aplicar un perfil”. Quieres validar, comparar, ver impacto, revisar cumplimiento y automatizar. Y ahí Configuration Profiles entra mucho mejor, porque encaja con APIs, con borradores de configuración, con validaciones previas y con procesos más repetibles. VMware en enero y febrero de 2026 publicó precisamente la secuencia de APIs y ejemplos de PowerCLI y Python para trabajar así.
Y el tercero es que VMware ya ha enseñado claramente la dirección del producto. En vSphere 9, Host Profiles está deprecated y Broadcom TechDocs ya indica que en lugar de Host Profiles se use vSphere Configuration Profiles.
Cuándo tiene sentido usarlo
Aquí es donde más interesa separar la teoría de la práctica.
Si estás montando un clúster nuevo y quieres hacerlo bien desde el principio, yo ya lo enfocaría con Configuration Profiles. Tiene más sentido arrancar con el modelo que VMware está empujando ahora que seguir montando algo que sabes que va de salida.
Si ya tienes un clúster con vSphere Lifecycle Manager y trabajas con images, todavía más. De hecho, el propio flujo oficial de transición que ha publicado VMware está pensado precisamente para clústeres cuyo lifecycle ya está gestionado con imágenes.
También tiene mucho sentido si quieres estandarizar varios hosts y asegurarte de que nadie te deja un ajuste tocado a mano sin control. Aquí el valor no está solo en aplicar una configuración, sino en poder comprobar cumplimiento y remediar drift desde el estado deseado del clúster.
Y si además tienes ya algo de automatización interna, este tema se pone bastante interesante. VMware ya ha publicado secuencias para trabajar con borradores, validaciones, prechecks y aplicación desde API, PowerCLI y Python. Incluso ha llevado el tema a GitOps usando ArgoCD como fuente de verdad del estado deseado.
Cuándo no me metería todavía
No todo es “activa esto y ya está”.
Si tienes un entorno antiguo, poco homogéneo o con hosts tocados a mano durante años, antes de migrar conviene limpiar la casa. VMware recomienda como buena práctica que los hosts estén cumpliendo el Host Profile actual antes de hacer la transición. Si no partes de una base sana, el cambio puede heredar inconsistencias que luego te van a tocar revisar igual.
También hay una matización importante con los clústeres gestionados por baselines. VMware indicó que vSphere Configuration Profiles sí se soporta con baseline-managed clusters en vSphere 8 U3, pero que en vSphere 9 esos clústeres ya no están soportados para este modelo, y la recomendación pasa por trabajar con image managed clusters usando vSphere Lifecycle Manager.
Así que si alguien está todavía en una mezcla rara de versiones, baselines antiguos y cambios manuales, yo no vendería esto como “migración de cinco minutos”. Primero normalizar. Luego ya migras.
Qué cambia de verdad frente a Host Profiles
Lo importante no es el nombre nuevo. Lo importante es el modelo.
Antes pensabas más en un host de referencia y un perfil que aplicar. Ahora piensas en el clúster como unidad de configuración.
Antes el perfil tendía a ser más pesado y menos cómodo de revisar. Ahora trabajas con una definición más manejable y más cercana a un documento de configuración.
Antes la automatización no era el centro. Ahora el propio diseño de la solución encaja mucho mejor con APIs, validaciones, borradores y pipelines.
Y antes podías verlo como una función útil de administración. Ahora VMware lo está llevando claramente hacia un enfoque de desired state real, mucho más alineado con cómo se administran plataformas hoy.
Cómo sería la transición en un clúster real
VMware publicó hace nada un flujo bastante claro para pasar de Host Profiles a vSphere Configuration Profiles en vSphere 9. Las capturas del artículo están hechas sobre vSphere 9.0.2, así que la interfaz puede variar un poco según versión, pero el concepto es ese.
Lo primero es entrar en el clúster y activar la parte de Desired State desde Cluster > Configure > Configuration, pulsando en Create Configuration. Ese paso lanza comprobaciones de elegibilidad para ver si el clúster puede pasar a Configuration Profiles.
Después VMware da dos opciones. Puedes importar desde un host de referencia o importar desde un fichero JSON con la configuración deseada. Si vienes de Host Profiles, la recomendación oficial es importar desde un host de referencia del propio clúster, asumiendo que los hosts ya son conformes con el perfil que estabas usando.
Tras eso viene la validación. El proceso genera el documento, lo valida contra los hosts del clúster y luego permite hacer el pre-check y aplicar la configuración. En esa fase ya se evalúa cumplimiento y, si hay drift, puede remediarse.
Y hay un detalle importante que conviene no saltarse. VMware avisa de que, al importar desde un host de referencia, las desviaciones del resto de hosts pueden quedar recogidas como host overrides. Eso hay que revisarlo si quieres un clúster realmente uniforme y no arrastrar excepciones innecesarias.
La parte interesante: automatización con PowerCLI, Python y GitOps
Aquí es donde este tema deja de ser solo “otra opción nueva en vCenter” y pasa a ser realmente útil.
En enero de 2026 VMware publicó la parte de APIs, explicando la secuencia para habilitar VCP en un clúster. Ahí se ve el flujo completo: comprobar si el clúster puede usar Configuration Profiles, validar elegibilidad, importar desde host o fichero, validar configuración y finalmente habilitarlo.
En febrero de 2026 llegó el segundo post, ya con ejemplos usando PowerCLI y Python, orientado a administradores que quieran meter esto en scripts o procesos repetibles. En esos ejemplos aparecen operaciones como validar cambios, lanzar prechecks, aplicar el draft y consultar el estado de compliance del clúster.
Un ejemplo simplificado del flujo sería algo así:
# Validar cambios del draft
$configChanges = Invoke-GetClusterDraft0 -Cluster $cluster.ExtensionData.MoRef.Value -Draft $draftId# Lanzar prechecks
Invoke-PrecheckClusterDraftAsync -Cluster $cluster.ExtensionData.MoRef.Value -Draft $draftId -Confirm:$false# Aplicar el draft
Invoke-ApplyClusterDraft -Cluster $cluster.ExtensionData.MoRef.Value -Draft $draftId -Confirm:$false# Comprobar compliance
Invoke-CheckComplianceClusterConfigurationAsync -Cluster $cluster.ExtensionData.MoRef.Value -Confirm:$false
Ese enfoque encaja bastante bien con lo que muchos ya hacemos en otros entornos: definir estado, validarlo antes, aplicarlo y luego comprobar cumplimiento. No es casualidad que el tercer post oficial, publicado el 2 de abril de 2026, ya lleve esto directamente a un enfoque GitOps, y la propia serie lo presenta como una forma de mantener configuración deseada a escala usando ArgoCD.
Problemas comunes que yo revisaría antes de lanzarme
El primer error sería pensar que esto es simplemente Host Profiles con otro nombre. No lo es. El cambio real está en pasar de un perfil de host a una gestión de configuración del clúster basada en estado deseado.
El segundo sería migrar un clúster que ya está mal de base. Si los hosts no son conformes con lo que tenías antes, te vas a llevar esa suciedad al siguiente modelo.
El tercero sería usar un host de referencia sin revisar luego los overrides. VMware lo avisa expresamente, y aquí hay trampa fácil: parece que todo ha ido bien, pero realmente te quedas con excepciones que luego hacen más difícil mantener un estado común.
Y el cuarto sería ignorar la parte de versiones. Si alguien sigue en clústeres gestionados por baseline y piensa saltar a vSphere 9 sin revisar esto, puede encontrarse con que el escenario que tenía en 8 U3 ya no es el recomendado ni el soportado para Configuration Profiles.
Requisitos
Para que este cambio tenga sentido de verdad, yo partiría de un entorno con vCenter bien ordenado, un clúster razonablemente homogéneo y, a ser posible, lifecycle gestionado con imágenes. También ayuda bastante tener claro qué configuraciones quieres estandarizar y cuáles son excepciones reales del entorno, porque eso te evita llenar el clúster de overrides que luego nadie entiende.
Arquitectura o diagrama opcional
Aquí metería un diagrama muy simple con dos bloques.
En el lado izquierdo pondría el modelo antiguo: Reference Host > Host Profile > Attach to Hosts.
En el lado derecho pondría el modelo nuevo: Desired State del Cluster > Validation > Compliance > Remediation.
Visualmente ayuda mucho porque el lector entiende en diez segundos que el cambio no es solo de interfaz, sino de forma de administrar.
Checklist final
Si me tuviera que quedar con una idea, sería esta.
Host Profiles no está muerto hoy, pero ya no es el camino que VMware está empujando. vSphere Configuration Profiles es el sustituto natural y además encaja bastante mejor con cómo administramos plataformas ahora: estado deseado, validación, compliance y automatización.
Si tienes un clúster moderno, ordenado y con intención de seguir creciendo, yo ya empezaría a mirarlo en serio.
Si tienes un entorno heredado, primero limpiaría y estandarizaría.
Pero en cualquier caso, merece la pena entenderlo ya, porque esto no pinta a función secundaria. Pinta a ser la forma normal de gestionar configuración de hosts en VMware a partir de ahora.
Espero que os sirva