Documentazione dei prodotti
Citrix DaaS™
Visualizza PDF

Creare un catalogo Google Cloud Platform

September 16, 2025
Grazie al contributo di: 
C C

Creare cataloghi di macchine descrive le procedure guidate per la creazione di un catalogo di macchine. Le seguenti informazioni riguardano i dettagli specifici degli ambienti Google Cloud.

Nota:

Prima di creare un catalogo Google Cloud Platform (GCP), è necessario completare la creazione di una connessione a GCP. Vedere Connessione agli ambienti Google Cloud.

Preparare un’istanza VM master e un disco persistente

Suggerimento:

Il disco persistente è il termine di Google Cloud per disco virtuale.

Per preparare l’istanza VM master, creare e configurare un’istanza VM con proprietà che corrispondano alla configurazione desiderata per le istanze VDA clonate nel catalogo di macchine pianificato. La configurazione non si applica solo alle dimensioni e al tipo dell’istanza. Include anche attributi dell’istanza come metadati, tag, assegnazioni GPU, tag di rete e proprietà dell’account di servizio.

Come parte del processo di masterizzazione, MCS utilizza l’istanza VM master per creare il modello di istanza di Google Cloud. Il modello di istanza viene quindi utilizzato per creare le istanze VDA clonate che compongono il catalogo di macchine. Le istanze clonate ereditano le proprietà (eccetto le proprietà di VPC, subnet e disco persistente) dell’istanza VM master da cui è stato creato il modello di istanza.

Dopo aver configurato le proprietà dell’istanza VM master in base alle proprie specifiche, avviare l’istanza e quindi preparare il disco persistente per l’istanza.

Si consiglia di creare manualmente uno snapshot del disco o un’immagine del disco. In questo modo è possibile utilizzare una convenzione di denominazione significativa per tenere traccia delle versioni, offre più opzioni per gestire le versioni precedenti dell’immagine master e consente di risparmiare tempo per la creazione del catalogo di macchine. Se non si crea il proprio snapshot, MCS ne crea uno temporaneo (che viene eliminato alla fine del processo di provisioning). La creazione manuale di uno snapshot multiregionale del disco del sistema operativo o dell’immagine consente inoltre di utilizzare la stessa immagine master per i cataloghi di macchine in diverse regioni GCP.

Abilitare la selezione della zona

Citrix DaaS™ supporta la selezione della zona. Con la selezione della zona, si specificano le zone in cui si desidera creare le VM. Con la selezione della zona, gli amministratori possono posizionare i nodi a tenant singolo nelle zone di loro scelta. Per configurare la tenancy singola, è necessario completare quanto segue su Google Cloud:

Riservare un nodo a tenant singolo di Google Cloud

Per riservare un nodo a tenant singolo, fare riferimento alla documentazione di Google Cloud.

Importante:

Un modello di nodo viene utilizzato per indicare le caratteristiche prestazionali del sistema riservato nel gruppo di nodi. Tali caratteristiche includono il numero di vGPU, la quantità di memoria allocata al nodo e il tipo di macchina utilizzato per le macchine create sul nodo. Per ulteriori informazioni, consultare la documentazione di Google Cloud.

Creare l’immagine master VDA

Per distribuire correttamente le macchine sul nodo a tenant singolo, è necessario eseguire passaggi aggiuntivi durante la creazione di un’immagine VM master. Le istanze di macchina su Google Cloud hanno una proprietà chiamata etichette di affinità del nodo. Le istanze utilizzate come immagini master per i cataloghi distribuiti sul nodo a tenant singolo richiedono un’etichetta di affinità del nodo che corrisponda al nome del gruppo di nodi di destinazione. Per raggiungere questo obiettivo, tenere presente quanto segue:

Nota:

Se si intende utilizzare la tenancy singola con un VPC condiviso, vedere Virtual Private Cloud condiviso.

Impostare un’etichetta di affinità del nodo durante la creazione di un’istanza

Per impostare l’etichetta di affinità del nodo:

  1. Nella console Google Cloud, accedere a Compute Engine > Istanze VM.

  2. Nella pagina Istanze VM, selezionare Crea istanza.

  3. Nella pagina Creazione istanza, digitare o configurare le informazioni richieste e quindi selezionare gestione, sicurezza, dischi, networking, tenancy singola per aprire il pannello delle impostazioni.

  4. Nella scheda Tenancy singola, selezionare Sfoglia per visualizzare i gruppi di nodi disponibili nel progetto corrente. Viene visualizzata la pagina Nodo a tenant singolo, che mostra un elenco di gruppi di nodi disponibili.

  5. Nella pagina Nodo a tenant singolo, selezionare il gruppo di nodi applicabile dall’elenco e quindi selezionare Seleziona per tornare alla scheda Tenancy singola. Il campo delle etichette di affinità del nodo viene popolato con le informazioni selezionate. Questa impostazione garantisce che i cataloghi di macchine creati dall’istanza vengano distribuiti al gruppo di nodi selezionato.

  6. Selezionare Crea per creare l’istanza.

Impostare un’etichetta di affinità del nodo per un’istanza esistente

Per impostare l’etichetta di affinità del nodo:

  1. Nella finestra del terminale Google Cloud Shell, utilizzare il comando gcloud compute instances per impostare un’etichetta di affinità del nodo. Includere le seguenti informazioni nel comando gcloud:

    • Nome della VM. Ad esempio, utilizzare una VM esistente denominata s*2019-vda-base.*
    • Nome del gruppo di nodi. Utilizzare il nome del gruppo di nodi creato in precedenza. Ad esempio, mh-sole-tenant-node-group-1.
    • La zona in cui risiede l’istanza. Ad esempio, la VM risiede nella zona *us-east-1b*.

    Ad esempio, digitare il seguente comando nella finestra del terminale:

    • gcloud compute instances set-scheduling "s2019-vda-base" --node-group="mh-sole-tenant-node-group-1" --zone="us-east1-b"

    Per ulteriori informazioni sul comando gcloud compute instances, consultare la documentazione di Google Developer Tools all’indirizzo https://cloud.google.com/sdk/gcloud/reference/beta/compute/instances/set-scheduling.

  2. Accedere alla pagina Dettagli istanza VM dell’istanza e verificare che il campo Affinità nodo sia popolato con l’etichetta.

Creare un catalogo di macchine

Nota:

Creare le risorse prima di creare un catalogo di macchine. Utilizzare le convenzioni di denominazione stabilite da Google Cloud durante la configurazione dei cataloghi di macchine. Vedere Linee guida per la denominazione di bucket e oggetti per ulteriori informazioni.

È possibile creare un catalogo di macchine in due modi:

Creare un catalogo di macchine utilizzando Studio

Seguire le istruzioni in Creare cataloghi di macchine. La seguente descrizione è specifica per i cataloghi Google Cloud.

  1. Da Studio, selezionare Cataloghi di macchine nel riquadro sinistro.
  2. Selezionare Crea catalogo di macchine nella barra delle azioni.
  3. Nella pagina Tipo di macchina, selezionare Sistema operativo multi-sessione e quindi selezionare Avanti. Citrix DaaS supporta anche il sistema operativo a sessione singola.
  4. Nella pagina Gestione macchine, selezionare le opzioni Macchine con gestione dell’alimentazione e Citrix Machine Creation Services™ e quindi selezionare Avanti. Se sono presenti più risorse, selezionarne una dal menu.

  5. Nella pagina Immagine, completare questi passaggi secondo necessità, quindi fare clic su Avanti.

    1. Selezionare l’immagine master. È possibile selezionare i seguenti tipi di immagine:
      • Macchina virtuale (le cui regioni sono le stesse delle unità di hosting selezionate).
      • Snapshot (supportano snapshot multiregionali).
      • Immagine del sistema operativo (supporta immagini pubbliche e non pubbliche multiregionali). Se si desidera utilizzare la funzionalità di tenancy singola, assicurarsi di selezionare un’immagine la cui proprietà del gruppo di nodi sia configurata correttamente. Vedere Abilitare la selezione della zona.

    2. Nella pagina Seleziona un profilo macchina, selezionare le risorse dalla scheda Macchina virtuale o dalla scheda Modelli di istanza.

      Nota:

      • Attualmente, le VM in questo catalogo ereditano le impostazioni di archiviazione, tipo di macchina e crittografia del disco dal profilo macchina selezionato.
      • Se si seleziona un modello di istanza come profilo macchina, tutte le zone vengono selezionate per impostazione predefinita. È possibile selezionare le zone come richiesto.
    3. Selezionare il livello funzionale minimo per il catalogo.

  6. Nella pagina Archiviazione, selezionare il tipo di archiviazione utilizzato per contenere il sistema operativo per questo catalogo di macchine. Ciascuna delle seguenti opzioni di archiviazione ha caratteristiche di prezzo e prestazioni uniche. Un disco di identità viene sempre creato utilizzando il disco persistente standard zonale.

    • Disco persistente standard
    • Disco persistente bilanciato
    • Disco persistente SSD

    Per i dettagli sulle opzioni di archiviazione di Google Cloud, vedere Opzioni di archiviazione.

  7. Nella pagina Macchine virtuali, specificare quante VM si desidera creare, visualizzare le specifiche dettagliate delle VM, selezionare il tipo di macchina Google Cloud e quindi selezionare Avanti. Se si utilizzano gruppi di nodi a tenant singolo per i cataloghi di macchine, assicurarsi di selezionare solo le zone in cui sono disponibili nodi a tenant singolo riservati. Vedere Abilitare la selezione della zona.

    Nota:

    Il tipo di macchina Google Cloud viene selezionato automaticamente in base al profilo macchina scelto. È possibile selezionare un tipo di macchina diverso, se necessario.

  8. Nella pagina Impostazioni disco, è possibile configurare le seguenti impostazioni:

    • Scegliere se abilitare la cache di write-back. Dopo aver abilitato la cache di write-back, è possibile eseguire quanto segue:

      • Configurare le dimensioni del disco e della RAM utilizzati per la memorizzazione nella cache dei dati temporanei. Per ulteriori informazioni, vedere Configurare la cache per i dati temporanei.
      • Selezionare il tipo di archiviazione per il disco della cache di write-back. Le seguenti opzioni di archiviazione sono disponibili per il disco della cache di write-back:
        • Disco persistente standard
        • Disco persistente bilanciato
        • Disco persistente SSD

        Per i dettagli sulle opzioni di archiviazione di Google Cloud, vedere Opzioni di archiviazione.

      • Selezionare il tipo per il disco della cache di write-back.
        • Utilizzare un disco della cache di write-back non persistente. Se selezionato, il disco della cache di write-back non persiste per le VM di cui è stato eseguito il provisioning. Il disco viene eliminato durante i cicli di alimentazione e tutti i dati reindirizzati al disco andranno persi.
        • Utilizzare un disco della cache di write-back persistente. Se selezionato, il disco della cache di write-back persiste per le VM di cui è stato eseguito il provisioning. L’abilitazione di questa opzione aumenta i costi di archiviazione.
    • Quando l’ottimizzazione dell’archiviazione MCS (MCS I/O) è abilitata, è possibile eseguire una delle seguenti operazioni:

    • Scegliere se utilizzare la propria chiave per proteggere il contenuto del disco. Per utilizzare la funzionalità, è necessario prima creare le proprie chiavi di crittografia gestite dal cliente (CMEK). Per ulteriori informazioni, vedere Utilizzare le chiavi di crittografia gestite dal cliente (CMEK).

      Nota:

      È disponibile solo nell’interfaccia di Studio.

      Dopo aver creato le chiavi, è possibile selezionarne una dall’elenco. Non è possibile modificare la chiave dopo aver creato il catalogo. Google Cloud non supporta la rotazione delle chiavi su dischi persistenti o immagini esistenti. Pertanto, dopo aver eseguito il provisioning di un catalogo, il catalogo è legato a una versione specifica della chiave. Se tale chiave viene disabilitata o distrutta, le istanze e i dischi crittografati con essa diventano inutilizzabili finché la chiave non viene riabilitata o ripristinata.

      Le impostazioni della chiave di crittografia gestita dal cliente (CMEK) seguono una sequenza di priorità come segue:

      • La CMEK personalizzata di un catalogo ha la priorità più alta.
      • Se il profilo macchina selezionato è crittografato, le impostazioni CMEK utilizzano automaticamente la CMEK del profilo macchina come priorità successiva.
      • Se il profilo macchina selezionato non è crittografato, le impostazioni CMEK utilizzano automaticamente la CMEK dell’immagine master.

  9. Nella pagina Identità macchina, selezionare un account Active Directory e quindi selezionare Avanti.

    • Se si seleziona Crea nuovi account Active Directory, selezionare un dominio e quindi immettere la sequenza di caratteri che rappresenta lo schema di denominazione per gli account computer VM di cui è stato eseguito il provisioning creati in Active Directory. Lo schema di denominazione dell’account può contenere 1-64 caratteri e non può contenere spazi vuoti, caratteri non ASCII o caratteri speciali.
    • Se si seleziona Usa account Active Directory esistenti, selezionare Sfoglia per accedere agli account computer Active Directory esistenti per le macchine selezionate.

  10. Nella pagina Credenziali di dominio, selezionare Immetti credenziali, digitare il nome utente e la password, selezionare Salva e quindi selezionare Avanti.

    • Le credenziali digitate devono disporre delle autorizzazioni per eseguire operazioni sull’account Active Directory.

  11. Nella pagina Ambiti, selezionare gli ambiti per il catalogo di macchine e quindi selezionare Avanti.

    • È possibile selezionare ambiti facoltativi o selezionare ambito personalizzato per personalizzare gli ambiti secondo necessità.

  12. Nella pagina Riepilogo, confermare le informazioni, specificare un nome per il catalogo e quindi selezionare Fine.

    Nota:

    Il nome del catalogo può contenere 1-39 caratteri e non può contenere solo spazi vuoti o i caratteri \ / ; : # . * ? = < > | [ ] { } " ' ( ) ' ).

La creazione del catalogo di macchine potrebbe richiedere molto tempo per essere completata. Una volta completata, il catalogo viene elencato. È possibile verificare che le macchine siano state create sui gruppi di nodi di destinazione nella console Google Cloud.

Importare macchine Google Cloud create manualmente

Utilizzando questa funzionalità, è possibile:

  • Importare macchine Google Cloud con sistema operativo multi-sessione create manualmente in un catalogo Citrix DaaS.
  • Rimuovere macchine Google Cloud con sistema operativo multi-sessione create manualmente da un catalogo Citrix DaaS.
  • Utilizzare le funzionalità di gestione dell’alimentazione esistenti di Citrix DaaS per gestire l’alimentazione delle macchine Google Cloud Windows con sistema operativo multi-sessione. Ad esempio, impostare una pianificazione di riavvio per tali macchine.

Questa funzionalità non richiede modifiche a un flusso di lavoro di provisioning Citrix DaaS esistente, né la rimozione di alcuna funzionalità esistente.

Si consiglia di utilizzare MCS per eseguire il provisioning delle macchine in Studio anziché importare macchine Google Cloud create manualmente.

Virtual Private Cloud condiviso

I Virtual Private Cloud (VPC) condivisi comprendono un progetto host, da cui vengono rese disponibili le subnet condivise, e uno o più progetti di servizio che utilizzano la risorsa. I VPC condivisi sono opzioni desiderabili per installazioni più grandi perché forniscono controllo, utilizzo e amministrazione centralizzati delle risorse Google Cloud aziendali condivise. Per ulteriori informazioni, consultare il sito della documentazione di Google.

Con questa funzionalità, Machine Creation Services (MCS) supporta il provisioning e la gestione dei cataloghi di macchine distribuiti su VPC condivisi. Questo supporto, che è funzionalmente equivalente al supporto attualmente fornito nei VPC locali, differisce in due aree:

  • È necessario concedere autorizzazioni aggiuntive all’account di servizio utilizzato per creare la connessione host. Questo processo consente a MCS di accedere e utilizzare le risorse VPC condivise. Vedere Nuove autorizzazioni richieste.
  • È necessario creare due regole firewall, una per l’ingresso e una per l’uscita. Queste regole firewall vengono utilizzate durante il processo di masterizzazione dell’immagine. Vedere Regole firewall.

Per informazioni sulla configurazione del VPC condiviso, vedere Configurare il VPC condiviso.

Nuove autorizzazioni richieste

È richiesto un account di servizio Google Cloud con autorizzazioni specifiche durante la creazione della connessione host. Queste autorizzazioni aggiuntive devono essere concesse a tutti gli account di servizio utilizzati per creare connessioni host basate su VPC condivisi.

Suggerimento:

Queste autorizzazioni aggiuntive non sono nuove per Citrix DaaS. Vengono utilizzate per facilitare l’implementazione dei VPC locali. Con i VPC condivisi, queste autorizzazioni aggiuntive consentono l’accesso ad altre risorse VPC condivise.

Un massimo di quattro autorizzazioni aggiuntive devono essere concesse all’account di servizio associato alla connessione host per supportare il VPC condiviso:

  • compute.firewalls.list - Questa autorizzazione è obbligatoria. Consente a MCS di recuperare l’elenco delle regole firewall presenti sul VPC condiviso.
  • compute.networks.list - Questa autorizzazione è obbligatoria. Consente a MCS di identificare le reti VPC condivise disponibili per l’account di servizio.
  • compute.subnetworks.list – Questa autorizzazione è facoltativa a seconda di come si utilizzano i VPC. Consente a MCS di identificare le subnet all’interno dei VPC condivisi visibili. Questa autorizzazione è già richiesta quando si utilizzano i VPC locali, ma deve essere assegnata anche nel progetto host del VPC condiviso.
  • compute.subnetworks.use - Questa autorizzazione è facoltativa a seconda di come si utilizzano i VPC. È necessaria per utilizzare le risorse della subnet nei cataloghi di macchine di cui è stato eseguito il provisioning. Questa autorizzazione è già richiesta per l’utilizzo dei VPC locali, ma deve essere assegnata anche nel progetto host del VPC condiviso.

Quando si utilizzano queste autorizzazioni, considerare che esistono approcci diversi in base al tipo di autorizzazione utilizzata per creare il catalogo di macchine:

  • Autorizzazione a livello di progetto:
    • Consente l’accesso a tutti i VPC condivisi all’interno del progetto host.
    • Richiede che le autorizzazioni compute.subnetworks.list e compute.subnetworks.use siano assegnate all’account di servizio.
  • Autorizzazione a livello di subnet:
    • Consente l’accesso a subnet specifiche all’interno del VPC condiviso.
    • Le autorizzazioni compute.subnetworks.list e compute.subnetworks.use sono intrinseche all’assegnazione a livello di subnet e pertanto non devono essere assegnate direttamente all’account di servizio.

Selezionare l’approccio che corrisponde alle proprie esigenze organizzative e agli standard di sicurezza.

Suggerimento:

Per ulteriori informazioni sulle differenze tra le autorizzazioni a livello di progetto e a livello di subnet, vedere Amministratori del progetto di servizio.

Regole firewall

Durante la preparazione di un catalogo di macchine, viene preparata un’immagine di macchina per fungere da disco di sistema dell’immagine master per il catalogo. Quando si verifica questo processo, il disco viene temporaneamente collegato a una macchina virtuale. Questa VM deve essere eseguita in un ambiente isolato che impedisca tutto il traffico di rete in entrata e in uscita. Ciò si ottiene tramite una coppia di regole firewall di negazione totale; una per il traffico in ingresso e una per il traffico in uscita. Quando si utilizzano i VCP locali di Google Cloud, MCS crea questo firewall nella rete locale e lo applica alla macchina per la masterizzazione. Una volta completata la masterizzazione, la regola firewall viene rimossa dall’immagine.

Si consiglia di ridurre al minimo il numero di nuove autorizzazioni richieste per l’utilizzo dei VPC condivisi. I VPC condivisi sono risorse aziendali di livello superiore e in genere hanno protocolli di sicurezza più rigidi in atto. Per questo motivo, creare una coppia di regole firewall nel progetto host sulle risorse VPC condivise, una per l’ingresso e una per l’uscita. Assegnare loro la priorità più alta. Applicare un nuovo tag di destinazione a ciascuna di queste regole, utilizzando il seguente valore:

citrix-provisioning-quarantine-firewall

Quando MCS crea o aggiorna un catalogo di macchine, cerca le regole firewall che contengono questo tag di destinazione. Esamina quindi le regole per verificarne la correttezza e le applica alla macchina utilizzata per preparare l’immagine master per il catalogo. Se le regole firewall non vengono trovate, o le regole vengono trovate ma le regole o le loro priorità non sono corrette, viene visualizzato un messaggio simile al seguente:

"Impossibile trovare regole firewall di quarantena INGRESSO ed USCITA valide per il VPC <nome> nel progetto <progetto>. " Assicurarsi di aver creato regole firewall 'nega tutto' con il tag di rete 'citrix-provisioning-quarantine-firewall' e la priorità appropriata." "Fare riferimento alla documentazione Citrix per i dettagli."

Configurare il VPC condiviso

Prima di aggiungere il VPC condiviso come connessione host in Citrix DaaS Studio, completare i seguenti passaggi per aggiungere account di servizio dal progetto in cui si intende eseguire il provisioning:

  1. Creare un ruolo IAM.
  2. Aggiungere un account di servizio al ruolo IAM del progetto host.
  3. Aggiungere l’account di servizio Cloud Build al VPC condiviso.
  4. Creare regole firewall.

Creare un ruolo IAM

Determinare il livello di accesso del ruolo:

  • Accesso a livello di progetto, o
  • Un modello più restrittivo che utilizza l’accesso a livello di subnet.

Accesso a livello di progetto per il ruolo IAM. Per il ruolo IAM a livello di progetto, includere le seguenti autorizzazioni:

  • compute.firewalls.list
  • compute.networks.list
  • compute.subnetworks.list
  • compute.subnetworks.use

Per creare un ruolo IAM a livello di progetto:

  1. Nella console Google Cloud, accedere a IAM e amministrazione > Ruoli.
  2. Nella pagina Ruoli, selezionare CREA RUOLO.
  3. Nella pagina Crea ruolo, specificare il nome del ruolo. Selezionare AGGIUNGI AUTORIZZAZIONI.
    1. Nella pagina Aggiungi autorizzazioni, aggiungere le autorizzazioni al ruolo, individualmente. Per aggiungere un’autorizzazione, digitare il nome dell’autorizzazione nel campo Filtra tabella. Selezionare l’autorizzazione e quindi selezionare AGGIUNGI.
    2. Selezionare CREA.

Ruolo IAM a livello di subnet. Questo ruolo omette l’aggiunta delle autorizzazioni compute.subnetworks.list e compute.subnetworks.use dopo aver selezionato CREA RUOLO. Per questo livello di accesso IAM, le autorizzazioni compute.firewalls.list e compute.networks.list devono essere applicate al nuovo ruolo.

Per creare un ruolo IAM a livello di subnet:

  1. Nella console Google Cloud, accedere a Rete VPC > VPC condiviso. Viene visualizzata la pagina VPC condiviso, che mostra le subnet delle reti VPC condivise contenute nel progetto host.
  2. Nella pagina VPC condiviso, selezionare la subnet a cui si desidera accedere.
  3. Nell’angolo in alto a destra, selezionare AGGIUNGI MEMBRO per aggiungere un account di servizio.
  4. Nella pagina Aggiungi membri, completare questi passaggi:
    1. Nel campo Nuovi membri, digitare il nome dell’account di servizio e quindi selezionare l’account di servizio nel menu.
    2. Selezionare il campo Seleziona un ruolo e quindi Utente di rete Compute.
    3. Selezionare SALVA.
  5. Nella console Google Cloud, accedere a IAM e amministrazione > Ruoli.
  6. Nella pagina Ruoli, selezionare CREA RUOLO.
  7. Nella pagina Crea ruolo, specificare il nome del ruolo. Selezionare AGGIUNGI AUTORIZZAZIONI.
    1. Nella pagina Aggiungi autorizzazioni, aggiungere le autorizzazioni al ruolo, individualmente. Per aggiungere un’autorizzazione, digitare il nome dell’autorizzazione nel campo Filtra tabella. Selezionare l’autorizzazione e quindi selezionare AGGIUNGI.
    2. Selezionare CREA.

Aggiungere un account di servizio al ruolo IAM del progetto host

Dopo aver creato un ruolo IAM, eseguire i seguenti passaggi per aggiungere un account di servizio per il progetto host:

  1. Nella console Google Cloud, accedere al progetto host e quindi a IAM e amministrazione > IAM.
  2. Nella pagina IAM, selezionare AGGIUNGI per aggiungere un account di servizio.
  3. Nella pagina Aggiungi membri:
    1. Nel campo Nuovi membri, digitare il nome dell’account di servizio e quindi selezionare l’account di servizio nel menu.
    2. Selezionare un campo ruolo, digitare il ruolo IAM creato e quindi selezionare il ruolo nel menu.
    3. Selezionare SALVA.

L’account di servizio è ora configurato per il progetto host.

Aggiungere l’account di servizio Cloud Build al VPC condiviso

Ogni abbonamento Google Cloud ha un account di servizio denominato in base al numero ID del progetto, seguito da cloudbuild.gserviceaccount. Ad esempio: 705794712345@cloudbuild.gserviceaccount.

È possibile determinare il numero ID del progetto per il proprio progetto accedendo a Panoramica Cloud > Dashboard nella console Google Cloud. L’ID del progetto e il numero del progetto vengono visualizzati nella scheda Informazioni sul progetto della Dashboard del progetto:

Eseguire i seguenti passaggi per aggiungere l’account di servizio Cloud Build al VPC condiviso:

  1. Nella console Google Cloud, accedere al progetto host e quindi a IAM e amministrazione > IAM.
  2. Nella pagina Autorizzazioni, selezionare AGGIUNGI per aggiungere un account.
  3. Nella pagina Aggiungi membri, completare questi passaggi:
    1. Nel campo Nuovi membri, digitare il nome dell’account di servizio Cloud Build e quindi selezionare l’account di servizio nel menu.
    2. Selezionare il campo Seleziona un ruolo, digitare Utente di rete Compute e quindi selezionare il ruolo nel menu.
    3. Selezionare SALVA.

Creare regole firewall

Come parte del processo di masterizzazione, MCS copia l’immagine di macchina selezionata e la utilizza per preparare il disco di sistema dell’immagine master per il catalogo. Durante la masterizzazione, MCS collega il disco a una macchina virtuale temporanea, che esegue quindi script di preparazione. Questa VM deve essere eseguita in un ambiente isolato che proibisca tutto il traffico di rete in entrata e in uscita.

Per creare un ambiente isolato, MCS richiede due regole firewall nega tutto (una regola di ingresso e una regola di uscita). Pertanto, creare due regole firewall (Ingresso e Uscita) nel Progetto host come segue:

  1. Nella console Google Cloud, accedere al progetto host e quindi a Rete VPC > Firewall.
  2. Nella pagina Firewall, selezionare CREA REGOLA FIREWALL.
  3. Nella pagina Crea una regola firewall, completare quanto segue:
    • Nome. Digitare un nome per la regola.
    • Rete. Selezionare la rete VPC condivisa a cui si applica la regola firewall in ingresso.
    • Priorità. Minore è il valore, maggiore è la priorità della regola. Si consiglia un valore piccolo (ad esempio, 10).
    • Direzione del traffico. Selezionare Ingresso.
    • Azione in caso di corrispondenza. Selezionare Nega.
    • Destinazioni. Utilizzare l’impostazione predefinita, Tag di destinazione specificati.
    • Tag di destinazione. Digitare citrix-provisioning-quarantine-firewall.
    • Filtro sorgente. Utilizzare l’impostazione predefinita, Intervalli IP.
    • Intervalli IP sorgente. Digitare un intervallo che corrisponda a tutto il traffico. Digitare 0.0.0.0/0.
    • Protocolli e porte. Selezionare Nega tutto.
  4. Selezionare CREA per creare la regola.
  5. Ripetere i passaggi per creare un’altra regola. Per Direzione del traffico, selezionare Uscita.

Utilizzare le chiavi di crittografia gestite dal cliente (CMEK)

Nota:

Il supporto per CMEK in GCP è attualmente in anteprima.

È possibile utilizzare le chiavi di crittografia gestite dal cliente (CMEK) per i cataloghi MCS. Quando si utilizza questa funzionalità, si assegna il ruolo CryptoKey Encrypter/Decrypter del servizio Google Cloud Key Management all’agente di servizio Compute Engine. L’account Citrix DaaS deve disporre delle autorizzazioni corrette nel progetto in cui è archiviata la chiave. Vedere Assegnare le autorizzazioni all’account Citrix DaaS. Fare riferimento a Protezione delle risorse tramite chiavi Cloud KMS per ulteriori informazioni.

L’agente di servizio Compute Engine ha il seguente formato: service-<Numero_progetto>@compute-system.iam.gserviceaccount.com. Questo formato è diverso dall’account di servizio Compute Engine predefinito.

Nota:

Questo account di servizio Compute Engine potrebbe non apparire nella visualizzazione Autorizzazioni IAM della console Google. In tali casi, utilizzare il comando gcloud come descritto in Protezione delle risorse tramite chiavi Cloud KMS.

Assegnare le autorizzazioni all’account Citrix DaaS

Le autorizzazioni Google Cloud KMS possono essere configurate in vari modi. È possibile fornire autorizzazioni KMS a livello di progetto o autorizzazioni KMS a livello di risorsa. Vedere Autorizzazioni e ruoli per ulteriori informazioni.

Autorizzazioni KMS a livello di progetto

Un’opzione è fornire all’account Citrix DaaS autorizzazioni a livello di progetto per sfogliare le risorse Cloud KMS. Per fare ciò, creare un ruolo personalizzato e aggiungere le seguenti autorizzazioni:

  • cloudkms.keyRings.list
  • cloudkms.keyRings.get
  • cloudkms.cryptokeys.list
  • cloudkms.cryptokeys.get

Assegnare questo ruolo personalizzato all’account Citrix DaaS. Ciò consente di sfogliare le chiavi regionali nel progetto pertinente nell’inventario.

Autorizzazioni KMS a livello di risorsa

Per l’altra opzione, le autorizzazioni a livello di risorsa, nella console Google Cloud, accedere alla cryptoKey utilizzata per il provisioning MCS. Aggiungere l’account Citrix DaaS a un key ring o a una chiave utilizzata per il provisioning del catalogo.

Suggerimento:

Con questa opzione, non è possibile sfogliare le chiavi regionali per il progetto nell’inventario perché l’account Citrix DaaS non dispone delle autorizzazioni di elenco a livello di progetto sulle risorse Cloud KMS. Tuttavia, è comunque possibile eseguire il provisioning di un catalogo utilizzando CMEK specificando il cryptoKeyId corretto nelle proprietà personalizzate di ProvScheme. Vedere Creare un catalogo con CMEK utilizzando proprietà personalizzate.

Rotazione delle chiavi gestite dal cliente

Google Cloud non supporta la rotazione delle chiavi su dischi persistenti o immagini esistenti. Una volta eseguito il provisioning di una macchina, questa è legata alla versione della chiave in uso al momento della sua creazione. Tuttavia, è possibile creare una nuova versione della chiave e tale nuova chiave viene utilizzata per le macchine di cui è stato eseguito il provisioning di recente o per le risorse create quando un catalogo viene aggiornato con una nuova immagine master.

Considerazioni importanti sui key ring

I key ring non possono essere rinominati o eliminati. Inoltre, si potrebbero incorrere in costi imprevisti durante la loro configurazione. Quando si elimina o si rimuove un key ring, Google Cloud visualizza un messaggio di errore:

Spiacenti, non è possibile eliminare o rinominare chiavi o key ring. Eravamo preoccupati per le implicazioni di sicurezza derivanti dal consentire a più chiavi o versioni di chiavi nel tempo di avere lo stesso nome di risorsa, quindi abbiamo deciso di rendere i nomi immutabili. (E non è possibile eliminarli, perché non saremmo in grado di eseguire una vera eliminazione: ci sarebbe comunque una traccia che questo nome è stato utilizzato e non può essere riutilizzato).
Siamo consapevoli che questo può rendere le cose disordinate, ma non abbiamo piani immediati per cambiarlo.
Se si desidera evitare di essere fatturati per una chiave o renderla comunque non disponibile, è possibile farlo eliminando tutte le versioni della chiave; né le chiavi né i key ring vengono fatturati, solo le versioni attive della chiave all'interno delle chiavi.
<!--NeedCopy-->

Suggerimento:

Per ulteriori informazioni, vedere Modifica o eliminazione di un key ring dalla console.

Compatibilità con l’accesso uniforme a livello di bucket

Citrix DaaS è compatibile con la policy di controllo dell’accesso uniforme a livello di bucket su Google Cloud. Questa funzionalità aumenta l’uso della policy IAM che concede le autorizzazioni a un account di servizio per consentire la manipolazione delle risorse, inclusi i bucket di archiviazione. Con il controllo dell’accesso uniforme a livello di bucket, Citrix DaaS consente di utilizzare un elenco di controllo degli accessi (ACL) per controllare l’accesso ai bucket di archiviazione o agli oggetti in essi archiviati. Vedere Accesso uniforme a livello di bucket per informazioni generali sull’accesso uniforme a livello di bucket di Google Cloud. Per informazioni sulla configurazione, vedere Richiedere l’accesso uniforme a livello di bucket.

Utilizzare PowerShell

Questa sezione descrive come eseguire le seguenti attività utilizzando PowerShell:

Creare un catalogo con disco della cache di write-back persistente

Per configurare un catalogo con disco della cache di write-back persistente, utilizzare il comando PowerShell New-ProvScheme CustomProperties.

Suggerimento:

Utilizzare il parametro PowerShell New-ProvScheme CustomProperties solo per le connessioni di hosting basate su cloud. Se si desidera eseguire il provisioning di macchine utilizzando un disco della cache di write-back persistente per una soluzione on-premise (ad esempio, XenServer®), PowerShell non è necessario perché il disco persiste automaticamente.

Questo comando supporta una proprietà aggiuntiva, PersistWBC, utilizzata per determinare come il disco della cache di write-back persiste per le macchine di cui è stato eseguito il provisioning MCS. La proprietà PersistWBC viene utilizzata solo quando viene specificato il parametro UseWriteBackCache e quando il parametro WriteBackCacheDiskSize è impostato per indicare che viene creato un disco.

Nota:

Questo comportamento si applica sia ad Azure che a GCP, dove il disco della cache di write-back MCSIO predefinito viene eliminato e ricreato durante i cicli di alimentazione. È possibile scegliere di rendere persistente il disco per evitare l’eliminazione e la ricreazione del disco della cache di write-back MCSIO.

Esempi di proprietà trovate nel parametro CustomProperties prima del supporto di PersistWBC includono:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
</CustomProperties>
<!--NeedCopy-->

Nota:

Questo esempio si applica solo ad Azure. Le proprietà sono diverse nell’ambiente GCP.

Quando si utilizzano queste proprietà, considerare che contengono valori predefiniti se le proprietà vengono omesse dal parametro CustomProperties. La proprietà PersistWBC ha due possibili valori: true o false.

L’impostazione della proprietà PersistWBC su true non elimina il disco della cache di write-back quando l’amministratore di Citrix DaaS spegne la macchina dall’interfaccia di gestione.

L’impostazione della proprietà PersistWBC su false elimina il disco della cache di write-back quando l’amministratore di Citrix DaaS spegne la macchina dall’interfaccia di gestione.

Nota:

Se la proprietà PersistWBC viene omessa, la proprietà assume il valore predefinito false e la cache di write-back viene eliminata quando la macchina viene spenta dall’interfaccia di gestione.

Ad esempio, utilizzando il parametro CustomProperties per impostare PersistWBC su true:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistWBC" Value="true" />
</CustomProperties>
<!--NeedCopy-->

Importante:

La proprietà PersistWBC può essere impostata solo utilizzando il cmdlet PowerShell New-ProvScheme. Il tentativo di modificare le CustomProperties di uno schema di provisioning dopo la creazione non ha alcun impatto sul catalogo di macchine e sulla persistenza del disco della cache di write-back quando una macchina viene spenta.

Ad esempio, impostare New-ProvScheme per utilizzare la cache di write-back impostando la proprietà PersistWBC su true:

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" " Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistWBC`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

Migliorare le prestazioni di avvio con MCSIO

È possibile migliorare le prestazioni di avvio per i dischi gestiti di Azure e GCP quando MCSIO è abilitato. Utilizzare la proprietà personalizzata PowerShell PersistOSDisk nel comando New-ProvScheme per configurare questa funzionalità. Le opzioni associate a New-ProvScheme includono:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="Resource<!--NeedCopy-->
``````<!--NeedCopy-->
````````Groups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistOsDisk" Value="true" />
</CustomProperties>
<!--NeedCopy-->

Per abilitare questa funzionalità, impostare la proprietà personalizzata PersistOSDisk su true. Ad esempio:

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistOsDisk`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

Creare un catalogo con CMEK utilizzando proprietà personalizzate

Quando si crea lo schema di provisioning tramite PowerShell, specificare una proprietà CryptoKeyId in ProvScheme CustomProperties. Ad esempio:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="<yourCryptoKeyId>" />
</CustomProperties>'
<!--NeedCopy-->

Il cryptoKeyId deve essere specificato nel seguente formato:

projectId:location:keyRingName:cryptoKeyName

Ad esempio, se si desidera utilizzare la chiave my-example-key nel key ring my-example-key-ring nella regione us-east1 e nel progetto con ID my-example-project-1, le impostazioni personalizzate di ProvScheme sarebbero simili a:

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:us-east1:my-example-key-ring:my-example-key" />
</CustomProperties>'
<!--NeedCopy-->

Tutti i dischi e le immagini di cui è stato eseguito il provisioning MCS relativi a questo schema di provisioning utilizzano questa chiave di crittografia gestita dal cliente.

Suggerimento:

Se si utilizzano chiavi globali, la posizione delle proprietà del cliente deve indicare global e non il nome della regione, che nell’esempio precedente è us-east1. Ad esempio: <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:global:my-example-key-ring:my-example-key" />.

Creare un catalogo di macchine utilizzando un profilo macchina

Quando si crea un catalogo per eseguire il provisioning di macchine utilizzando Machine Creation Services (MCS), è possibile utilizzare un profilo macchina per acquisire le proprietà hardware da una macchina virtuale e applicarle alle VM di cui è stato eseguito il provisioning di recente nel catalogo. Quando il parametro MachineProfile non viene utilizzato, le proprietà hardware vengono acquisite dalla VM o dallo snapshot dell’immagine master. Alcune proprietà definite esplicitamente, ad esempio StorageType, CatalogZones e CryptoKeyId, vengono ignorate dal profilo macchina.

  • Per creare un catalogo con un profilo macchina, utilizzare il comando New-ProvScheme. Ad esempio, New-ProvScheme –MachineProfile “percorso della VM”. Se non si specifica il parametro MachineProfile, le proprietà hardware vengono acquisite dalla VM dell’immagine master.
  • Per aggiornare un catalogo con un nuovo profilo macchina, utilizzare il comando Set-ProvScheme. Ad esempio, Set-ProvScheme –MachineProfile “percorso della nuova VM”. Questo comando non modifica il profilo macchina delle VM esistenti nel catalogo. Solo le VM appena create aggiunte al catalogo avranno il nuovo profilo macchina.

  • È anche possibile aggiornare l’immagine master, tuttavia, quando si aggiorna l’immagine master, le proprietà hardware non vengono aggiornate. Se si desidera aggiornare le proprietà hardware, è necessario aggiornare il profilo macchina utilizzando il comando Set-ProvScheme. Queste modifiche si applicheranno solo alle nuove macchine nel catalogo. Per aggiornare le proprietà hardware di una macchina esistente, è possibile utilizzare il comando Set-ProvVMUpdateTimeWindow con i parametri -StartsNow e -DurationInMinutes -1.

    Nota:

    • StartsNow indica che l’ora di inizio pianificata è l’ora corrente.
    • DurationInMinutes con un numero negativo (ad esempio, –1) indica nessun limite superiore per la finestra temporale della pianificazione.

Creare un catalogo di macchine con profilo macchina come modello di istanza

È possibile selezionare un modello di istanza GCP come input per il profilo macchina. I modelli di istanza sono risorse leggere in GCP, quindi sono molto convenienti.

Creare un nuovo catalogo di macchine con profilo macchina come modello di istanza

  1. Aprire una finestra PowerShell.
  2. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.

  3. Trovare un modello di istanza nel progetto GCP utilizzando il seguente comando:

    cd XDHyp:\HostingUnits\<NomeUnitaHosting>\instanceTemplates.folder
<!--NeedCopy-->

  4. Creare un nuovo catalogo di macchine con profilo macchina come modello di istanza utilizzando il comando NewProvScheme:

    New-ProvScheme -ProvisioningSchemeName <NomeCatalogo>  -HostingUnitName <NomeUnitaHosting> -IdentityPoolName <nome pool di identità> -MasterImageVM
XDHyp:\HostingUnits\<NomeUnitaHosting>\Base.vm\Base.snapshot -MachineProfile XDHyp:\HostingUnits\<NomeUnitaHosting>\instanceTemplates.folder\mytemplate.template
<!--NeedCopy-->

    Per ulteriori informazioni sul comando New-ProvScheme, vedere https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/New-ProvScheme/.

  5. Completare la creazione del catalogo di macchine utilizzando i comandi PowerShell.

Aggiornare un catalogo di macchine per avere un modello di istanza come profilo macchina

  1. Aprire una finestra PowerShell.
  2. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.

  3. Eseguire il seguente comando:

    Set-ProvScheme -ProvisioningSchemeName  <NomeCatalogo> -MachineProfile XDHyp:\HostingUnits\<NomeUnitaHosting>\instanceTemplates.folder\<NomeModello>.template
<!--NeedCopy-->

    Per informazioni sul comando Set-ProvScheme, vedere https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/Set-ProvScheme/.

Creare un catalogo con VM schermata

È possibile creare un catalogo di macchine MCS con proprietà VM schermate. Una macchina virtuale schermata è rafforzata da un set di controlli di sicurezza che forniscono un’integrità verificabile delle istanze di Compute Engine, utilizzando funzionalità di sicurezza della piattaforma avanzate come l’avvio protetto, un modulo di piattaforma attendibile virtuale, firmware UEFI e monitoraggio dell’integrità.

MCS supporta la creazione del catalogo utilizzando il flusso di lavoro del profilo macchina. Se si utilizza il flusso di lavoro del profilo macchina, è necessario abilitare le proprietà VM schermate di un’istanza VM. È quindi possibile utilizzare questa istanza VM come input del profilo macchina.

Creare un catalogo di macchine MCS con VM schermata

  1. Abilitare le opzioni VM schermate di un’istanza VM nella console Google Cloud. Vedere Guida rapida: Abilitare le opzioni VM schermate.
  2. Creare un catalogo di macchine MCS con il flusso di lavoro del profilo macchina utilizzando l’istanza VM.
    1. Aprire una finestra PowerShell
    2. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.
    3. Creare un pool di identità se non è già stato creato.

    4. Eseguire il comando New-ProvScheme. Ad esempio:

      New-ProvScheme -ProvisioningSchemeName <nome-catalogo>
-HostingUnitName gcp-hostint-unit
-MasterImageVM XDHyp:\HostingUnits\gcp-hostint-unit\catalog-vda.vm
-MachineProfile XDHyp:\HostingUnits\gcp-hostint-unit\catalog-machine.vm
<!--NeedCopy-->
  3. Completare la creazione del catalogo di macchine.

Aggiornare un catalogo di macchine con un nuovo profilo macchina

  1. Eseguire il comando Set-ProvScheme. Ad esempio:

    Set-ProvScheme -ProvisioningSchemeName <nome-catalogo>
-MasterImageVM XDHyp:\HostingUnits\<unità-hosting>\catalog-vda.vm
-MachineProfile "DHyp:\HostingUnits\<unità-hosting>\catalog-machine.vm
<!--NeedCopy-->

Per applicare la modifica apportata in Set-ProvScheme alle VM esistenti, eseguire il comando Set-ProvVMUpdateTimeWindow.

  1. Eseguire il comando Set-ProvVMUpdateTimeWindow. Ad esempio:

    Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <Elenco-Nomi-VM> -StartsNow -DurationInMinutes -1
<!--NeedCopy-->

  2. Riavviare le VM.

Creare VM Windows 11 sul nodo a tenant singolo

È possibile creare VM Windows 11 in GCP. Tuttavia, se si installa Windows 11 sull’immagine master, è necessario abilitare vTPM durante il processo di creazione dell’immagine master. Inoltre, è necessario abilitare vTPM sull’origine del profilo macchina (VM o modello di istanza).

I passaggi chiave per creare VM Windows 11 sul nodo a tenant singolo sono:

  1. Configurare gli ambienti di virtualizzazione di Google Cloud. Per informazioni, vedere Ambienti Google Cloud.
  2. Installare VDA. Vedere Installare VDA.
  3. Creare una connessione agli ambienti Google Cloud. Per informazioni, vedere Connessione agli ambienti Google Cloud.
  4. Creare un’immagine master Windows 11 Bring Your Own License (BYOL) e importare l’immagine in Google Cloud. Vedere Creare un’immagine master Windows 11 BYOL.
  5. Creare l’origine del profilo macchina: Eseguire il provisioning della VM sul nodo a tenant singolo e abilitare il vTPM dell’origine del profilo macchina. Vedere Eseguire il provisioning della VM sul nodo a tenant singolo.
  6. Creare un catalogo di macchine MCS utilizzando l’origine del profilo macchina Windows 11 abilitata con vTPM. L’origine del profilo macchina deve avere lo stesso tipo di istanza descritto nel nodo a tenant singolo. Vedere Creare un catalogo di macchine MCS utilizzando l’origine del profilo macchina Windows 11.

Creare un’immagine master Windows 11 BYOL

Esistono due opzioni per creare un’immagine master Windows 11 BYOL e importare l’immagine master in Google Cloud:

  • Utilizzare gli strumenti di Cloud Build di Google Cloud
  • Creare l’immagine master su qualsiasi altro hypervisor

Utilizzare gli strumenti di Cloud Build di Google Cloud

  1. Caricare i file ISO di Windows 11, GCP SDK, .NET framework e i file del programma di installazione di PowerShell nel bucket di archiviazione GCP.
  2. Fornire la posizione del file nel file .yaml di Cloud Build come parametro.

  3. Eseguire il seguente Cloud Build dalla riga di comando per creare l’immagine finale di Windows 11. GCP avvia e crea l’immagine master nel progetto selezionato utilizzando il flusso di lavoro Daisy in GCP e l’immagine master viene importata in GCP.

    gcloud compute instances import NOME-ISTANZA--source-uri=gs://BUCKET/FILE-IMMAGINE-OVF.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=TIPO-MACCHINA --zone=ZONA
<!--NeedCopy-->

    Nota:

    Sostituire tutto il testo in maiuscolo con i dettagli effettivi della risorsa.

Per le informazioni complete, vedere Creare immagini Windows BYOL personalizzate.

Creare l’immagine master su qualsiasi altro hypervisor

  1. Creare l’immagine master di Windows 11 utilizzando qualsiasi altro hypervisor.
  2. Esportare l’immagine master in formato OVF nella macchina locale.

  3. Caricare i file OVF nel bucket di archiviazione GCP utilizzando la CLI gcloud locale.

    gsutil cp PERCORSO_IMMAGINE_LOCALE_FILE_OVF gs://NOME_BUCKET/
<!--NeedCopy-->

  4. Eseguire il seguente Cloud Build dalla riga di comando per creare l’immagine finale di Windows 11. GCP avvia e crea l’immagine master nel progetto selezionato utilizzando il flusso di lavoro Daisy in GCP e l’immagine master viene importata in GCP.

    gcloud compute instances import NOME-ISTANZA --source-uri=gs://BUCKET/FILE-IMMAGINE-OVF.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=TIPO-MACCHINA --zone=ZONA
<!--NeedCopy-->

    Nota:

    Sostituire tutto il testo in maiuscolo con i dettagli effettivi della risorsa.

Eseguire il provisioning della VM sul nodo a tenant singolo

Utilizzare i nodi a tenant singolo per mantenere le VM fisicamente separate dalle VM in altri progetti o per raggruppare le VM sullo stesso hardware host. Per informazioni sul nodo a tenant singolo, consultare il documento GCP Panoramica sulla tenancy singola.

Per il provisioning di una VM (origine del profilo macchina) sul nodo a tenant singolo, consultare il documento GCP Eseguire il provisioning delle VM sui nodi a tenant singolo.

Nota:

  • Selezionare lo stesso tipo di istanza e la stessa regione del gruppo di nodi.
  • Abilitare vTPM nella sezione VM schermata. Per ulteriori informazioni, vedere Guida rapida: Abilitare le opzioni VM schermate.
  • Disabilitare Bitlocker sulla VM di origine.

Creare un catalogo di macchine MCS utilizzando l’origine del profilo macchina Windows 11

È possibile creare un catalogo di macchine MCS per creare VM Windows 11 utilizzando Studio o i comandi PowerShell.

Nota:

  • Per l’immagine master, selezionare lo snapshot o la VM di Windows 11.
  • Per l’origine del profilo macchina, selezionare la VM di Windows 11 come profilo macchina. L’origine del profilo macchina deve avere lo stesso tipo di istanza descritto nel nodo a tenant singolo.

Per informazioni sull’utilizzo di Studio, vedere Creare un catalogo di macchine utilizzando Studio.

Per informazioni sui comandi PowerShell, vedere Creare un catalogo di macchine utilizzando un profilo macchina.

Dopo aver creato il catalogo e acceso le VM, è possibile visualizzare le VM Windows 11 in esecuzione sul nodo a tenant singolo nella console Google Cloud.

VM e dischi con etichette ereditate

Le VM e i dischi del catalogo di macchine MCS (disco di identità, disco di write-back della cache e disco del sistema operativo) possono ereditare le etichette di un’origine del profilo macchina (istanza VM GCP o modello di istanza). È possibile utilizzare le etichette per distinguere le istanze di proprietà di team diversi (ad esempio, team:ricerca e team:analisi) e utilizzarle ulteriormente per la contabilità dei costi o la definizione del budget. Per ulteriori informazioni sulle etichette, consultare il documento GCP Organizzare le risorse utilizzando le etichette.

È possibile creare un nuovo catalogo, aggiornare un catalogo esistente e aggiornare le VM esistenti per ereditare le etichette utilizzando l’origine del profilo macchina.

Questa funzionalità è applicabile ai cataloghi di macchine MCS persistenti e non persistenti.

È possibile eseguire quanto segue:

Creare un catalogo con etichette ereditate

Per creare un catalogo di macchine MCS in cui VM e disco ereditano le etichette dall’origine del profilo macchina, eseguire quanto segue:

  1. Creare un’origine del profilo macchina (istanza VM o modello di istanza) con etichette. Per informazioni sulla creazione di VM con etichette, consultare il documento GCP Creare risorse con etichette. Un modello di istanza viene creato dalla VM e acquisisce le etichette definite nella VM.
  2. Creare un catalogo MCS utilizzando Studio o i comandi PowerShell.
  3. Se si utilizza Studio, nella pagina Immagine, selezionare Usa un profilo macchina e quindi selezionare la VM o il modello.

  4. Se si utilizzano i comandi PowerShell, eseguire quanto segue:

    1. Aprire la finestra PowerShell.
    2. Eseguire asnp citrix*.
    3. Creare un pool di identità se non è già stato creato.
    4. Creare gli account computer AD richiesti in Active Directory.

    5. Eseguire il comando New-ProvScheme per creare un catalogo. Ad esempio:

      New-ProvScheme con modello come input del profilo macchina (catalogo persistente):

      New-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-MasterImageVM "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\instanceTemplates.folder\nome-modello-istanza.template" `
<!--NeedCopy-->

      New-ProvScheme con modello di istanza come input del profilo macchina (catalogo non persistente):

      New-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-MasterImageVM "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\instanceTemplates.folder\nome-modello-istanza.template" `
-CleanOnBoot
<!--NeedCopy-->

      New-ProvScheme con istanza VM come input del profilo macchina (catalogo persistente):

      New-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-MasterImageVM "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
<!--NeedCopy-->

      New-ProvScheme con istanza VM come input del profilo macchina (catalogo non persistente):

      New-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-HostingUnitUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-IdentityPoolUid "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" `
-MasterImageVM "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
-CleanOnBoot
<!--NeedCopy-->
    6. Registrare lo schema di provisioning come catalogo broker.
    7. Aggiungere VM al catalogo.

Aggiornare un catalogo esistente con etichette ereditate

Per aggiornare un catalogo esistente per avere un nuovo profilo macchina, eseguire il comando Set-ProvScheme. Dopo aver eseguito il comando, tutte le nuove VM aggiunte al catalogo avranno le etichette della nuova origine del profilo macchina. Il catalogo non persistente viene aggiornato al successivo avvio.

Ad esempio:

Set-ProvScheme con modello di istanza come input del profilo macchina:

Set-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\instanceTemplates.folder\nome-modello-istanza.template" `
<!--NeedCopy-->

Set-ProvScheme con istanza VM come input del profilo macchina:

Set-ProvScheme `
-ProvisioningSchemeName "nome-catalogo" `
-MachineProfile "XDHyp:\HostingUnits\nome-unità-hosting\nome-vm.vm" `
<!--NeedCopy-->

Aggiornare le VM esistenti con etichette ereditate

Per aggiornare le VM esistenti con l’origine del profilo macchina aggiornata, eseguire i seguenti comandi:

  1. Set-ProvScheme

  2. Set-ProvVMUpdateTimeWindow. Ad esempio:

    Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <Elenco-Nomi-VM> -StartsNow -DurationInMinutes -1
<!--NeedCopy-->
  3. Riavviare le VM.

Recuperare informazioni per le etichette di VM e disco di avvio

Dopo aver creato le VM, è possibile ottenere le informazioni sull’etichetta della VM e del disco di avvio utilizzando il comando Get-Item con il parametro AdditionalData.

Per recuperare le informazioni sull’etichetta della VM, eseguire il seguente comando:

(Get-Item XDHyp:\HostingUnits\hosting-unit-name\vm_name.vm).AdditionalData.Tags
<!--NeedCopy-->

Per recuperare le informazioni sull’etichetta del disco di avvio, eseguire il seguente comando:

(Get-Item XDHyp:\HostingUnits\hosting-unit-name\vm_name.vm\bootdisk-name.attacheddisk).AdditionalData.Tags
<!--NeedCopy-->

Nota:

Per mantenere la coerenza tra i vari hypervisor, abbiamo utilizzato il termine Tag per visualizzare le etichette GCP.

Rimuovere una VM

È possibile scegliere di rimuovere una VM da un catalogo ma non eliminare la VM da GCP. In questo caso, le etichette Citrix vengono rimosse solo dalla VM. Tutte le altre etichette aggiunte non vengono eliminate dalla VM. È possibile rimuovere una VM da Studio o utilizzare i comandi PowerShell.

Utilizzo di Studio

  1. Selezionare e fare clic con il pulsante destro del mouse sulla VM.
  2. Fare clic su Elimina.
  3. Selezionare Rimuovi le macchine virtuali dal catalogo ma non eliminare le macchine virtuali.

Utilizzo dei comandi PowerShell

Eseguire Remove-ProvVM con il parametro ForgetVM. Per ulteriori informazioni, consultare la documentazione SDK Remove-ProvVM.

Google Cloud Marketplace

È possibile sfogliare e selezionare le immagini offerte da Citrix su Google Cloud Marketplace per creare cataloghi di macchine. Attualmente, MCS supporta solo il flusso di lavoro del profilo macchina per questa funzionalità.

Per cercare il prodotto VM Citrix VDA tramite Google Cloud Marketplace, andare su https://console.cloud.google.com/marketplace/.

È possibile utilizzare un’immagine personalizzata o un’immagine Citrix ready® su Google Cloud Marketplace per aggiornare un’immagine di un catalogo di macchine.

Nota:

Se il profilo macchina non contiene informazioni sul tipo di archiviazione, il valore viene derivato dalle proprietà personalizzate.

Le immagini supportate di Google Cloud Marketplace sono:

  • Windows 2019 Sessione Singola
  • Windows 2019 Multi Sessione
  • Ubuntu

Esempio di utilizzo di un’immagine Citrix ready come origine per la creazione di un catalogo di macchine:

New-ProvScheme -ProvisioningSchemeName GCPCatalog \
-HostingUnitName GcpHu -IdentityPoolName gcpPool -CleanOnBoot \
-MasterImageVM XDHyp:\HostingUnits\GcpHu\images.folder\citrix-daas-win2019-single-vda-v20220819.publicimage \
-MachineProfile XDHyp:\HostingUnits\GcpHu\Base.vm
<!--NeedCopy-->

Dove andare dopo

Ulteriori informazioni

Creare un catalogo Google Cloud Platform
September 16, 2025
Grazie al contributo di: 
C C
September 16, 2025
Grazie al contributo di: 
C C

In questo articolo

Feedback sito | Your privacy choices footer linkScelte di privacy | Privacy e condizioni legali | Preferenze cookie | Impostazioni di consenso | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.