Chi amministra VCF Automation lavora su due piani che l’esame ama sovrapporre: il VCF Automation Provider Management Portal, dove il provider prepara le risorse condivise, e il portale dell’organizzazione, dove l’organization administrator le trasforma in qualcosa che i progetti possano consumare. La content library attraversa entrambi i piani, e la prima cosa da fissare è che qui non stiamo parlando della content library di vCenter: la documentazione la definisce un’astrazione che offre un’unica interfaccia per gestire il contenuto attraverso le regioni, mentre sotto il cofano il contenuto viene sincronizzato fra le istanze vCenter — una scelta a caso come publisher, le altre come subscriber.

La content library del provider

Nel Provider Management Portal la voce sta nel pannello di navigazione a sinistra, sotto Infrastructure → Content Libraries; dalla scheda Content Library si fa clic su New. Si danno nome e descrizione facoltativa, si decide con un toggle se sottoscrivere una libreria esterna conforme a VCSP (in quel caso si inseriscono URL e password), poi si scelgono una o più regioni con la relativa storage class e si conferma. Il risultato è una libreria condivisa in sola lettura con tutte le organizzazioni.

Due vincoli infrastrutturali che la doc mette per iscritto e che in laboratorio fanno perdere ore: le istanze vCenter devono comunicare fra loro e mantenere la connettività, e le storage class devono avere nomi identici su tutte le istanze vCenter di una regione. Gli storage cluster non sono supportati: si usano datastore con le storage policy applicabili. Dai tre puntini verticali accanto al nome si accede a Edit (aggiungere o togliere regioni, cambiare storage class), Refresh (riconcilia le modifiche arrivate dai vCenter) e Delete.

Il contenuto si carica dalla scheda Content Library Items → Upload: si carica il file sorgente, si sceglie la libreria dal menu a discesa, si dà un nome (obbligatorio) e una descrizione, e si conferma con Submit. I formati sono OVA, ISO oppure OVF con tutti i file a cui l’OVF fa riferimento. Gli item caricati qui sono automaticamente condivisi con tutte le organizzazioni.

La libreria dell’organizzazione e le VM image

Lato tenant il percorso cambia: Build & Deploy → Content Hub → Content Libraries → New. Si inserisce il nome e si decide se assegnare la libreria a tutti i namespace attuali e futuri — questa impostazione non è più modificabile in seguito. Poi regioni e storage class, Next, revisione, Confirm. Anche qui i formati ammessi sono solo ISO e OVA/OVF, e c’è una trappola operativa da ricordare: dopo la creazione, le proprietà della libreria si aggiornano solo tramite l’API di VCF Automation, non dall’interfaccia.

Per una libreria sottoscritta valgono regole più strette: il provider administrator deve prima abilitarne la creazione, si attiva il toggle Subscribe to an external content library e si indica l’URL della libreria pubblicata (con password, se protetta). La libreria risultante è in sola lettura — non si caricano né si eliminano item — la sincronizzazione automatica o pianificata non è supportata, e la creazione fallisce se gli item superano la quota di storage dell’organizzazione.

Le VM image stanno in Build & Deploy → Content Hub → VM Images. Con Upload si sceglie il file locale, la content library di destinazione e il nome; ogni immagine riceve un identificatore univoco (VMI) che si usa nei blueprint per il provisioning. Dai tre puntini, sia dalla pagina VM Images sia da Content Libraries, si può fare Publish to Catalog: nome del catalogo, progetto, condivisione fra progetti facoltativa, configurazione cloud-init facoltativa. Attenzione: le immagini OVF si pubblicano direttamente, per le ISO la pubblicazione diretta a catalogo non è supportata.

Gli altri compiti da organization administrator

Prima del contenuto viene l’accesso. L’organization administrator collega uno o più identity provider esterni (LDAP, SAML, OIDC) per importare utenti e gruppi, poi lavora in Administer → Access Control: i ruoli predefiniti dell’organizzazione sono Organization Administrator, Organization User (che per fare qualcosa deve essere aggiunto a un progetto), Organization Auditor (la versione in sola lettura dell’amministratore) e l’opzione Defer to Identity Provider; i ruoli di progetto sono Project Administrator, Project Advanced User, Project User e Project Auditor. I ruoli custom si creano da Administer → Access Control → Roles → New spuntando le caselle dei diritti.

I progetti si creano da Manage & Govern → Projects → New: nome, poi utenti o gruppi con i rispettivi ruoli (conviene partire dal solo project administrator), revisione e Create Project. I namespace si aggiungono dalla scheda Namespaces del progetto con New Namespace, scegliendo namespace class, regione, VPC e fino a tre zone; al nome viene aggiunto un suffisso univoco. Il vincolo aritmetico da ricordare: la somma dei limiti di risorse di tutti i namespace non può superare la quota dell’organizzazione, che è la region quota assegnata dal provider.

I blueprint vivono in Build & Deploy → Content Hub → Blueprint Design → Blueprints. Dalla canvas si usa Version per creare una versione e scegliere «publish this version to the catalog»; da Version History si ispezionano le versioni, si fa Restore per sovrascrivere la bozza, si confrontano con Diff (codice o topologia) e si clona da All Actions → Clone. Non si rilascia a catalogo una Current Draft finché non la si versiona. In pubblicazione si scelgono nome, icona, progetto e versione. In una Provider Consumption Organization anche i workflow di VCF Operations Orchestrator si pubblicano allo stesso modo, con l’opzione di consentire l’accesso all’item ad altre organizzazioni.

Il ciclo si chiude con le lease policy (Manage & Govern → Policies → Definitions → New Policy → Lease Policy): scope organizzazione o progetto, criteri, enforcement soft o hard, maximum lease, maximum total lease e grace period. Senza policy i deployment non scadono mai; fra più policy vince la più restrittiva; abbassare i valori anticipa la scadenza dei deployment già creati, mentre alzarli non prolunga le scadenze esistenti.

Trappole tipiche d’esame

  • Tre oggetti chiamati «content library». Quella del provider (Infrastructure → Content Libraries, sola lettura per tutte le organizzazioni), quella dell’organizzazione (Build & Deploy → Content Hub) e quella di vCenter nel vSphere Client, che è l’unica a distinguere local, published e subscribed e a gestire i VM template. Nelle librerie di VCF Automation la doc elenca ISO e OVA/OVF.
  • Subscribed non significa sincronizzata. In vSphere una subscribed library sincronizza dalla libreria pubblicata; in VCF Automation la libreria sottoscritta è in sola lettura e la sincronizzazione automatica o pianificata non è supportata — e senza abilitazione da parte del provider non la si può nemmeno creare.
  • Scelte che non si tornano indietro. L’assegnazione della libreria a tutti i namespace attuali e futuri non è modificabile dopo la creazione, e le proprietà della libreria si aggiornano solo via API. Domande scritte come «l’amministratore vuole cambiare X dall’interfaccia» hanno spesso come risposta corretta «non si può».
  • OVF sì, ISO no. La pubblicazione diretta a catalogo vale per le immagini OVF; per le ISO non è supportata. È la classica distinzione su cui si gioca una domanda a scenario.
  • VCF, non vSphere Foundation. La doc afferma che vSphere Foundation «does not include the cloud management and integrated automation capabilities» disponibili in VMware Cloud Foundation: in un ambiente VVF non esiste il Content Hub di VCF Automation, e uno scenario che lo cita presuppone VCF.