Documentazione dei prodotti
Citrix DaaS™
Visualizza PDF

Creare cataloghi utilizzando immagini preparate in Amazon WorkSpaces Core Managed Instances

August 20, 2026
Grazie al contributo di: 
C C

Creare immagini preparate e utilizzare le immagini preparate per creare un catalogo di macchine MCS utilizzando:

  • Studio
  • PowerShell

Passaggi chiave

  1. Creare la definizione dell’immagine e la versione iniziale dell’immagine.
  2. Creare versioni dell’immagine dalla versione iniziale dell’immagine.
  3. Utilizzare la versione dell’immagine come immagine preparata per creare un catalogo.

Creare una definizione dell’immagine e la versione iniziale dell’immagine utilizzando Studio

Per creare una definizione dell’immagine e la versione iniziale dell’immagine, procedere come segue:

  1. Da Studio, andare al nodo Immagini e fare clic su Crea definizione immagine. Fare clic su Avanti nella pagina Introduzione.
  2. Nella pagina Definizione immagine, specificare il tipo di sistema operativo e il tipo di sessione per la definizione dell’immagine.

  3. Nella pagina Immagine, selezionare Risorse (sono elencate solo le risorse applicabili per la connessione impostata), un’immagine master da utilizzare come modello per la creazione della versione dell’immagine e un profilo macchina da cui acquisire le proprietà hardware. Selezionare un profilo macchina per acquisire le proprietà hardware da un’istanza VM o da una versione del modello di avvio.

    Nota:

    • Prima di selezionare un’immagine, verificare che l’immagine master abbia VDA 2311 o versione successiva installata e che il driver MCSIO sia installato sul VDA.
    • È supportato solo il servizio di metadati dell’istanza (IMDS) V2 e non IMDS V1. Per informazioni, vedere Come funziona il servizio di metadati dell’istanza versione 2.
  4. Nella pagina Specifiche macchina, selezionare una dimensione della macchina. La dimensione della macchina del profilo macchina (selezionata nella pagina Immagine) è selezionata per impostazione predefinita.
  5. Nella pagina NIC, selezionare o aggiungere NIC per l’immagine di preparazione. Per ogni NIC, selezionare una sottorete VPC associata.
  6. Nella pagina Descrizione versione, immettere una descrizione per la versione iniziale dell’immagine creata.
  7. Nella pagina Riepilogo, verificare i dettagli della definizione dell’immagine e della versione iniziale dell’immagine creata. Immettere un nome e una descrizione per la definizione dell’immagine. Fare clic su Fine.

Creare versioni di immagini utilizzando Studio

Le versioni delle immagini consentono la gestione di diverse iterazioni o aggiornamenti di una particolare immagine. Questa funzionalità consente di mantenere più versioni di un’immagine per scopi diversi.

Per creare versioni di immagini dalla versione iniziale dell’immagine, procedere come segue:

Nota:

L’unità di hosting di tutte le versioni dell’immagine deve essere la stessa.

  1. Andare al nodo Immagini, selezionare una versione dell’immagine o una definizione dell’immagine e fare clic su Crea versione immagine.
  2. Nella pagina Definizione immagine, è possibile modificare l’unità di hosting e riselezionare l’immagine master e il profilo macchina per quella versione dell’immagine.
  3. Se si desidera che la configurazione della versione dell’immagine sia diversa dalla versione iniziale dell’immagine configurata, configurare le impostazioni nelle pagine Specifiche macchina e NIC della finestra di dialogo Crea versione immagine.
  4. Aggiungere una descrizione per la versione dell’immagine. Fare clic su Fine.

Nota:

Se la creazione della versione dell’immagine fallisce per qualsiasi motivo, la scheda Risoluzione dei problemi in basso fornisce un’opzione Riprova.

Creare una specifica della versione dell’immagine preparata utilizzando PowerShell

I comandi PowerShell dettagliati per creare una specifica della versione dell’immagine preparata sono i seguenti:

  1. Controllare i nomi delle definizioni di immagine disponibili utilizzando Test-ProvImageDefinitionNameAvailable command. Ad esempio,

    Test-ProvImageDefinitionNameAvailable -ImageDefinitionName <string[]>
<!--NeedCopy-->

  2. Creare una definizione di immagine utilizzando il comando New-ProvImageDefinition. Ad esempio,

    New-ProvImageDefinition -ImageDefinitionName image1 -OsType Windows -VdaSessionSupport MultiSession
<!--NeedCopy-->

  3. Creare una nuova configurazione per la definizione dell’immagine nella connessione di hosting specificata utilizzando il comando Add-ProvImageDefinitionConnection.

    Add-ProvImageDefinitionConnection -ImageDefinitionName image1 -HypervisorConnectionName test-conn
<!--NeedCopy-->

  4. Creare una versione dell’immagine utilizzando il comando New-ProvImageVersion. Ad esempio,

    New-ProvImageVersion -ImageDefinitionName image1 -Description "version 1"
<!--NeedCopy-->

  5. Aggiungere una specifica della versione dell’immagine master alla versione dell’immagine utilizzando il comando Add-ProvImageVersionSpec. Ad esempio,

    Add-ProvImageVersionSpec -ImageDefinitionName  image1  -ImageVersionNumber  1 -HostingUnitName wsc -MasterImagePath "XDHyp:\HostingUnits\wsc\win10-2411-ami (ami-00123456789abcdef).template”"
<!--NeedCopy-->

    Nota:

    È possibile aggiungere una sola specifica della versione dell’immagine master a una versione dell’immagine per un’unità di hosting.

  6. Creare una specifica della versione dell’immagine preparata dalla specifica della versione dell’immagine master utilizzando il comando New-ProvImageVersionSpec. Il parametro SourceImageVersionSpecUid è derivato dal comando Add-ProvImageVersionSpec. Ad esempio,

    New-ProvImageVersionSpec
-SourceImageVersionSpecUid  00000000-0000-0000-0000-00000000000
-MachineProfile 'XDHyp:\HostingUnits\wsc\w2022-2411 (lt-00123456789abcdef).launchtemplate\lt-00123456789abcdef (1).launchtemplateversion' -RunAsynchronously
<!--NeedCopy-->

Esempio del set completo di comandi PowerShell per creare la definizione dell’immagine, la versione dell’immagine e la specifica della versione dell’immagine preparata:

New-ProvImageDefinition -ImageDefinitionName image1 -OsType Windows -VdaSessionSupport MultiSession


Add-ProvImageDefinitionConnection -ImageDefinitionName image1 -HypervisorConnectionName wsc -CustomProperties $CustomProperties

$imageVersion = New-ProvImageVersion -ImageDefinitionName image1 -Description "version 1"

$SourceImageVersionSpec = Add-ProvImageVersionSpec -ImageVersionUid $imageVersion.ImageVersionUid `
    -HostingUnitUid $hostingunit.HostingUnitUid `
    -MasterImagePath "XDHyp:\HostingUnits\wsc\win10-2411-ami (ami-00123456789abcdef).template”

New-ProvImageVersionSpec -MachineProfile 'XDHyp:\HostingUnits\wsc\w2022-2411 (lt-00123456789abcdef).launchtemplate\lt-00123456789abcdef (1).launchtemplateversion' -SourceImageVersionSpecUid $SourceImageVersionSpec.ImageVersionSpecUid
Add-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid 00000000-0000-0000-0000-00000000000-HostingUnitName wsc
$PreparedImageVersionSpec = Get-ProvImageVersionSpec -ImageVersionUid $imageVersion.ImageVersionUid | Where SourceImageVersionSpecUid-eq $SourceImageVersionSpec.ImageVersionSpecUid
<!--NeedCopy-->

Nota:

  • Tutte le specifiche della versione dell’immagine in una definizione di immagine devono appartenere alla stessa unità di hosting.
  • Una versione dell’immagine può avere una sola specifica della versione dell’immagine master e una sola specifica della versione dell’immagine preparata.
  • Tutte le specifiche della versione dell’immagine devono avere un profilo macchina.

Condividere immagini preparate tra zone di disponibilità e regioni

Ora è possibile condividere una singola immagine preparata tra diverse zone di disponibilità, legate a diverse unità di hosting, all’interno della stessa regione AWS o in regioni diverse per le istanze gestite di Amazon WorkSpaces Core. Ciò consente di utilizzare un’unica immagine preparata per creare e aggiornare cataloghi di macchine MCS in varie zone di disponibilità e regioni. Quando si condivide tra diverse zone di disponibilità in regioni diverse, la versione dell’immagine preparata verrà copiata dalla regione originale alle regioni di destinazione.

È possibile mantenere una singola immagine preparata e utilizzarla per creare e aggiornare cataloghi di macchine tra più zone di disponibilità e regioni legate a diverse unità di hosting. Ciò riduce significativamente il sovraccarico di gestione delle immagini, garantisce la coerenza tra le distribuzioni e semplifica il processo di provisioning. È inoltre possibile aggiornare senza problemi i cataloghi di macchine esistenti con immagini preparate da una zona di disponibilità o regione diversa.

Casi d’uso

  • Gestione centralizzata delle immagini: Si crea un’immagine preparata in una zona di disponibilità (ad esempio, us-east-1a). È quindi possibile condividere questa immagine con altre zone di disponibilità come us-east-1b all’interno della stessa regione AWS us-east-1 o us-west-1a in una us-west-1 region diversa. Ciò consente a una singola immagine di servire più unità di hosting e semplifica la manutenzione.
  • Creazione e aggiornamento efficienti dei cataloghi: È possibile utilizzare un’immagine preparata creata in AZ 1 (ad esempio, us-east-1a) per creare nuovi cataloghi in AZ 1. Dopo aver condiviso questa immagine con AZ 2 (ad esempio, us-east-1b), è quindi possibile utilizzare l’immagine condivisa in AZ 2 per creare e aggiornare cataloghi in AZ 2.
  • Distribuzioni tra unità di hosting e connessioni di hosting: Se l’ambiente dispone di più unità di hosting nella stessa o in diverse regioni AWS, è possibile condividere in modo efficiente le immagini preparate tra queste unità di hosting.

Limitazioni

  • Condivisione all’interno dello stesso account AWS: Non è possibile condividere tra diversi account AWS nell’implementazione attuale.

Considerazioni importanti

  • Ordine di eliminazione: Per eliminare una specifica della versione dell’immagine preparata originale, è necessario eliminare prima tutte le specifiche della versione dell’immagine condivisa. In alternativa, è necessario eliminare contemporaneamente le specifiche originali e condivise.
  • Dipendenza dalla versione dell’immagine: Quando si rimuove una versione dell’immagine, è necessario rimuovere prima tutte le configurazioni di condivisione che dipendono da quella specifica versione dell’immagine. I cataloghi creati dall’immagine originale (non condivisa) possono rimanere intatti.
  • Retrocompatibilità del catalogo: È possibile aggiornare i cataloghi di macchine esistenti distribuiti prima dell’introduzione di questa funzionalità. Utilizzare immagini preparate create in una zona di disponibilità o regione diversa da quella in cui è stato originariamente distribuito il catalogo.
  • Eliminazione completa: Quando si elimina un’immagine preparata, non è più possibile utilizzarla in nessuna zona di disponibilità in cui è stata condivisa o originariamente creata. Inoltre, una versione dell’immagine preparata non può essere eliminata finché non vengono eliminati prima tutti i cataloghi collegati alla versione dell’immagine preparata.

Prerequisiti

Prima di configurare o utilizzare questa funzionalità, assicurarsi di soddisfare le seguenti condizioni:

  • L’ambiente deve essere un ambiente Amazon WorkSpaces Core Managed Instances.
  • È necessario configurare più unità di hosting (ognuna può essere collegata a diverse zone di disponibilità) e connessioni host (ognuna può essere collegata a una regione diversa) nello stesso account AWS.

Configurare utilizzando l’interfaccia utente di Studio

È possibile condividere immagini preparate tra zone di disponibilità collegate a diverse unità di hosting utilizzando l’interfaccia utente di Studio.

Per condividere un’immagine preparata

  1. Passare al nodo Immagini di Studio e selezionare la versione dell’immagine preparata che si desidera condividere con altre zone di disponibilità.
  2. Selezionare Gestisci condivisione immagine nella barra di navigazione superiore per gestire la condivisione dell’immagine per la versione dell’immagine selezionata.
  3. Nella pagina Gestisci condivisione immagine, selezionare una o più risorse con cui si desidera condividere la versione dell’immagine. Le risorse possono trovarsi in zone di disponibilità diverse da quelle della versione originale dell’immagine.
  4. Fare clic su Salva per condividere la versione dell’immagine nelle risorse tra le altre zone di disponibilità. La versione dell’immagine viene aggiornata in modo da essere condivisa tra le diverse risorse selezionate. Una volta completato, utilizzare la versione dell’immagine per creare cataloghi nelle zone di disponibilità in cui la versione dell’immagine è condivisa.

Per rimuovere la condivisione di un’immagine preparata

  1. Nel nodo Immagini di Studio, selezionare la versione dell’immagine preparata che si desidera rimuovere dalla condivisione.
  2. Selezionare Gestisci condivisione immagine nella barra di navigazione superiore per gestire la condivisione dell’immagine per la versione dell’immagine selezionata.

  3. Deselezionare le caselle di controllo da una o più risorse (zone di disponibilità) con cui si desidera interrompere la condivisione della versione dell’immagine.

    Nota:

    Le risorse non devono più avere cataloghi associati e creati dalla versione dell’immagine condivisa. Eventuali cataloghi creati dalla versione dell’immagine condivisa da rimuovere devono essere eliminati per primi.

  4. Fare clic su Salva per rimuovere la condivisione delle risorse tra le zone di disponibilità eliminate. La versione dell’immagine viene aggiornata in modo che non sia più condivisa in tali zone di disponibilità.

Configurare tramite PowerShell

In alternativa, è possibile condividere immagini preparate tra zone di disponibilità collegate a diverse unità di hosting utilizzando i comandi PowerShell.

Per condividere un’immagine preparata

  1. Assicurarsi di disporre del ImageVersionSpecUid dell’immagine preparata che si desidera condividere. È possibile recuperarlo utilizzando Get-ProvImageVersionSpec o comandi Get- simili in PowerShell.
  2. Determinare il HostingUnitName della zona di disponibilità (può essere la stessa regione o una diversa) in cui si desidera rendere disponibile l’immagine preparata. Questo è il nome dell’unità di hosting configurata per quella specifica AZ.

  3. Eseguire il comando Add-ProvImageVersionSpecHostingUnit: Utilizzare il seguente comando PowerShell. Sostituire <ImageVersionSpecUid> con l’Uid dell’immagine e <targetHostingUnitName> con il nome dell’unità di hosting nella zona di disponibilità di destinazione con cui si desidera condividere la specifica della versione dell’immagine:

    Add-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>
<!--NeedCopy-->
  4. Dopo l’esecuzione riuscita, è possibile visualizzare lo stato dell’immagine nell’interfaccia utente di Studio che indica che è stata condivisa con l’unità di hosting specificata.

Per rimuovere la condivisione di un’immagine preparata

  1. Assicurarsi di disporre del ImageVersionSpecUid dell’immagine preparata da cui si desidera rimuovere la condivisione.
  2. Determinare il HostingUnitName della zona di disponibilità da cui si desidera rimuovere l’immagine condivisa.

  3. Eseguire il comando Remove-ProvImageVersionSpecHostingUnit: Utilizzare il seguente comando PowerShell. Sostituire <ImageVersionSpecUid> con l’Uid dell’immagine e <targetHostingUnitName> con il nome dell’unità di hosting nella zona di disponibilità di destinazione da cui si desidera rimuovere la condivisione della specifica della versione dell’immagine:

    Remove-ProvImageVersionSpecHostingUnit -ImageVersionSpecUid <ImageVersionSpecUid> -HostingUnitName <targetHostingUnitName>
<!--NeedCopy-->

Impostazione di rete durante la preparazione dell’immagine

Durante la preparazione dell’immagine, viene creata una macchina virtuale (VM) di preparazione basata sulla VM originale. Questa VM di preparazione viene disconnessa dalla rete. Per disconnettere la rete dalla VM di preparazione, viene creato un gruppo di sicurezza di rete per negare tutto il traffico in entrata e in uscita. Questo gruppo di sicurezza di rete persiste e viene riutilizzato. Il nome del gruppo di sicurezza di rete è Citrix.XenDesktop.IsolationGroup-GUID, dove GUID è generato casualmente.

Un catalogo di macchine basato su profilo macchina

È possibile utilizzare un profilo macchina per acquisire le proprietà hardware da un’istanza EC2 (VM) o da una versione del modello di avvio e applicarle alle macchine sottoposte a provisioning. Le proprietà acquisite possono includere, ad esempio, tipo di tenancy, tipo di istanza, gruppi di sicurezza, mappature di rete, proprietà del volume EBS, ottimizzazione EBS, opzioni CPU, capacità di ibernazione e altre configurazioni AWS supportate.

È possibile utilizzare un’istanza AWS EC2 (VM) o una versione del modello di avvio AWS come input del profilo macchina.

Nota:

Tenancy AWS

AWS offre le seguenti opzioni di tenancy: tenancy condivisa (il tipo predefinito) e tenancy dedicata. La tenancy condivisa significa che più istanze Amazon WorkSpaces Core di clienti diversi potrebbero risiedere sullo stesso hardware fisico. La tenancy dedicata significa che le istanze Amazon WorkSpaces Core vengono eseguite solo su hardware con altre istanze che sono state distribuite.

Nota:

Sono supportate solo le istanze dedicate (gli host dedicati non sono attualmente supportati). Altri clienti non utilizzano lo stesso hardware.

Il tipo di tenancy viene acquisito dal profilo macchina

Quando si utilizza MCS per creare un catalogo per il provisioning di macchine in AWS, il tipo di tenancy viene acquisito dal profilo macchina.

  • Hardware condiviso: questa impostazione è adatta per la maggior parte delle distribuzioni. Più clienti condividono parti di hardware anche se non interagiscono tra loro. L’utilizzo di hardware condiviso è l’opzione meno costosa per l’esecuzione delle istanze Amazon EC2.
  • Istanza dedicata: questa impostazione è più adatta per distribuzioni con requisiti specifici di sicurezza o conformità. Con un’istanza dedicata, si godono comunque i vantaggi di avere un host separato dagli altri clienti AWS, ma non si paga per l’intero host. Non è necessario preoccuparsi della capacità dell’host, ma viene addebitata una tariffa più alta per le istanze. Inoltre, le istanze dedicate forniscono un supporto limitato per Bring Your Own License (BYOL).

Fatturazione flessibile

Amazon WorkSpaces Core Managed Instances supporta due modalità di fatturazione:

Modalità di fatturazione Descrizione
Mensile Fatturazione fissa, mensile a tariffa forfettaria. Ideale per desktop persistenti e carichi di lavoro prevedibili.
Oraria Fatturazione a consumo. Questa è la configurazione predefinita di AWS se non viene specificata esplicitamente alcuna modalità di fatturazione.

Queste opzioni offrono flessibilità per la gestione dei costi di calcolo in base alla persistenza e ai modelli di utilizzo del carico di lavoro.

Questa funzionalità richiede l’uso del servizio di fatturazione di Amazon WorkSpaces. Per impostazione predefinita, MCS utilizza questo servizio per il provisioning e la gestione delle istanze, consentendo di beneficiare di prezzi forfettari più competitivi per i carichi di lavoro persistenti.

Prerequisiti e considerazioni

  • Configurazione dell’account AWS: l’account AWS deve essere configurato per utilizzare il servizio di fatturazione di WorkSpaces. Sebbene gli account AWS siano passati per impostazione predefinita, alcuni clienti potrebbero richiedere ad AWS di rimanere sul servizio di fatturazione EC2 legacy per l’utilizzo di WorkSpaces Core Managed Instances.

    Nota:

    Se l’account utilizza il servizio di fatturazione EC2 legacy, l’opzione di fatturazione Mensile non è disponibile.

  • Connessione host: la fatturazione flessibile è applicabile solo alle connessioni host di Amazon WorkSpaces Core. Non è supportata per le connessioni host AWS EC2 standard.
  • Istanze spot: Le istanze spot non sono supportate con il servizio di fatturazione WorkSpaces.
  • Fatturazione mista: Un account AWS deve utilizzare la fatturazione WorkSpaces o la fatturazione EC2 per le istanze gestite core. Una combinazione di entrambi all’interno di un singolo account non è supportata.
  • Compatibilità: Solo tipi di istanza specifici, tipi di piattaforma (OS) e tipi di tenancy sono compatibili con determinate modalità di fatturazione. MCS esegue un controllo preliminare per garantire che le selezioni (Service Offering, Machine Profile e Prepared Image) corrispondano alla modalità di fatturazione scelta.

Vedere Creare un catalogo di macchine con una modalità di fatturazione specifica.

Un’immagine preparata e un profilo macchina sono necessari per la creazione di cataloghi di istanze gestite di Amazon WorkSpaces Core. È possibile utilizzare un’istanza VM AWS o una versione del modello di avvio AWS come input del profilo macchina.

Nota:

Attualmente, è supportata la creazione di cataloghi di VM sia persistenti che non persistenti (la proprietà CleanOnBoot è True o False).

Prima di creare un catalogo di istanze gestite di Amazon WorkSpaces Core, è necessario completare la creazione di:

  1. Una connessione alle istanze gestite di Amazon WorkSpaces Core. Vedere Connessione alle istanze gestite di Amazon WorkSpaces Core
  2. Un’immagine preparata.

È possibile creare un catalogo utilizzando:

Creare un catalogo utilizzando Studio

Creare un catalogo macchine dal nodo Immagini

Utilizzare l’opzione Crea catalogo nel nodo Immagini per creare un catalogo utilizzando la versione dell’immagine.

In alternativa, è possibile selezionare la versione durante la creazione di un catalogo nel nodo Cataloghi macchine, collegandosi all’opzione immagine preparata nel flusso di lavoro di creazione del catalogo. Vedere Creare un catalogo macchine dal nodo Cataloghi macchine.

Per creare un catalogo macchine MCS dal nodo Immagini, procedere come segue:

  1. Selezionare una versione dell’immagine e fare clic su Crea catalogo. Fare clic su Avanti nella pagina Introduzione.
  2. Nelle pagine Gestione macchine e Immagine, le impostazioni sono preselezionate in base alla versione dell’immagine selezionata. Nella pagina Immagine, inserire una nota per l’immagine preparata selezionata.
  3. Completare le impostazioni nelle pagine seguenti.
  4. Nella pagina Riepilogo, controllare i dettagli del catalogo macchine. Immettere un nome e una descrizione per il catalogo macchine. Fare clic su Fine.
  5. Andare al nodo Cataloghi macchine per visualizzare il catalogo macchine creato.

Creare un catalogo macchine dal nodo Cataloghi macchine

Per creare un catalogo macchine MCS dal nodo Cataloghi macchine, procedere come segue:

  1. Fare clic su Cataloghi macchine nel riquadro di navigazione a sinistra.
  2. Fare clic su Crea catalogo macchine. Viene visualizzata la pagina Configurazione catalogo macchine.
  3. Nella pagina Tipo di macchina, selezionare un tipo di macchina per il catalogo, ad esempio, SO multi-sessione.

  4. Nella pagina Gestione macchine, selezionare le seguenti impostazioni:

    1. Selezionare Macchine con gestione dell’alimentazione (ad esempio, macchine virtuali o PC blade).
    2. Selezionare Tecnologia di provisioning Citrix. Quindi, selezionare Citrix Machine Creation Services™.
    3. Nel campo Risorse, selezionare le risorse (Zona di disponibilità o Zona locale) configurate durante la creazione della connessione host e fare clic su Avanti.
  5. Nella pagina Esperienza desktop, selezionare il desktop casuale o statico che si desidera che gli utenti abbiano al momento dell’accesso. Se è selezionato un desktop statico, specificare ulteriormente se si desidera salvare le modifiche apportate dall’utente sul disco locale (persistente o non persistente).

  6. Nella pagina Immagine, fare clic su Seleziona un’immagine per selezionare un’immagine preparata per il catalogo di macchine. Selezionare la versione preparata creata. Fare clic sul nome della versione dell’immagine. Per visualizzare maggiori dettagli sulla versione dell’immagine selezionata, fare clic sul numero di versione, che è sottolineato. Fare clic su Fine.

    Viene visualizzato il profilo macchina associato all’immagine preparata e le sue proprietà hardware (ad esempio, tipo di istanza, tipo di tenancy, mappature di rete, gruppi di sicurezza, proprietà del volume) vengono utilizzate per creare macchine nei cataloghi. Per modificare l’origine del profilo macchina in un’altra VM o versione del modello di avvio, fare clic sul pulsante di modifica.

  7. Nella pagina Macchine virtuali:

    1. Immettere il numero di VM per il catalogo.
    2. Viene visualizzata la specifica macchina predefinita, basata sul profilo macchina. Per modificarla, selezionare l’icona di modifica e selezionare una specifica macchina.
  8. Nella pagina NIC, selezionare le NIC (o ENI) per le VM.

  9. Nella pagina Identità macchina, configurare il tipo di identità macchina per le macchine nel catalogo:

    1. Per configurare macchine aggiunte a un dominio (Active Directory locale o Microsoft Entra ibrido), selezionare il dominio e creare nuovi account AD per le VM da creare in questo catalogo di macchine. Le VM sottoposte a provisioning vengono aggiunte al dominio selezionato. Per eseguire il provisioning di macchine non aggiunte a un dominio, selezionare l’opzione di non aggiunta a un dominio.
    2. Specificare lo schema di denominazione degli account per i nuovi account da creare per le VM.
  10. Nella pagina Credenziali di dominio, fare clic su Immetti credenziali per fornire le credenziali per il dominio selezionato. Immettere nome utente e password a livello di amministratore quando richiesto. È inoltre possibile utilizzare un account di servizio se si dispone di credenziali di dominio già salvate in precedenza seguendo la nostra documentazione del prodotto.
  11. Scorrere le pagine rimanenti fino alla pagina Riepilogo. Immettere un nome per il catalogo di macchine e selezionare Fine per creare il catalogo di macchine.

Limitazioni sulla creazione di un catalogo di macchine in una zona locale AWS

  • Alcune zone locali supportano solo determinate configurazioni hardware (ad esempio, la zona locale di Perth non supporta i volumi GP3, ma solo i GP2).
  • Poiché solo gp2 è universalmente supportato in tutte le zone locali, e non tutte supportano gp3, la creazione del disco ID per impostazione predefinita utilizza il tipo di volume gp2.
  • È necessario selezionare un profilo macchina con specifiche hardware supportate nella zona locale desiderata.
  • Le snapshot delle AMI delle immagini preparate e le snapshot dei dischi ID vengono per impostazione predefinita posizionate nella regione, anziché nella zona locale (a causa delle limitazioni di AWS relative alla visibilità del supporto delle snapshot EBS nelle zone locali).
  • Solo le zone locali che supportano i servizi EC2 ed EBS completi sono zone supportate.

Creare un catalogo utilizzando PowerShell

Creare un catalogo utilizzando una specifica di versione dell’immagine preparata e un profilo macchina

  • Creare un catalogo di macchine non persistenti MCS dalla specifica di versione dell’immagine preparata utilizzando il comando New-ProvScheme. Ad esempio,

     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $true] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
 <!--NeedCopy-->

  • Creare un catalogo di macchine persistenti MCS dalla specifica di versione dell’immagine preparata utilizzando il comando New-ProvScheme. Ad esempio,

     New-ProvScheme -ProvisioningSchemeName <string> -ImageVersionSpecUid <Guid> -HostingUnitUid <Guid> -IdentityPoolUid <Guid> [-CleanOnBoot $false] [-MachineProfile <string>] [-ProvisioningSchemeType “MCS”]
 <!--NeedCopy-->

Esempio del set completo di comandi PowerShell per creare un catalogo:

$Catalog = New-BrokerCatalog  -AllocationType "Random"  -IsRemotePC $False  -MinimumFunctionalLevel "L7_20" -Name "wsccatalog" -PersistUserChanges "Discard" -ProvisioningType "MCS" -Scope @() -SessionSupport "MultiSession"

$IdentityPool = New-AcctIdentityPool  -AllowUnicode  -Domain "domainname" -IdentityPoolName "wsccatalog" -IdentityType "ActiveDirectory"  -NamingScheme "aws##" -NamingSchemeType "Numeric" -Scope @()

$PreparedImageVersionSpec = Get-ProvImageVersionSpec -ImageDefinitionName image1 -ImageVersionNumber 1 -Filter "PreparationType -eq 'Mcs'"

$Task = New-ProvScheme -ProvisioningSchemeName wsccatalog -ImageVersionSpecUid $PreparedImageVersionSpec.ImageVersionSpecUid -HostingUnitName wsc -IdentityPoolName wsccatalog -CleanOnBoot -Scope @() -SecurityGroup @() -MachineProfile 'XdHyp:\HostingUnits\cvad-test-scalestress\us-east-1a.availabilityzone\machine-profile-instance i (i-0xxxxxxxx).vm' -RunAsynchronously

Get-ProvTask -TaskId $Task.TaskId
$ProvScheme = Get-ProvScheme -ProvisioningSchemeName wsccatalog

Set-BrokerCatalog -Name $Catalog.Name -ProvisioningSchemeId $ProvScheme.ProvisioningSchemeUid
<!--NeedCopy-->

Aggiornare il profilo macchina

Per aggiornare il profilo macchina su un catalogo inizialmente fornito con un profilo macchina, procedere come segue. È inoltre possibile modificare il tipo di tenancy e la capacità di ibernazione dell’origine del profilo macchina durante la modifica di un catalogo di macchine MCS.

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

    Set-ProvScheme `
-ProvisioningSchemeUid "<ID" `
-MachineProfile "XDHyp:\HostingUnits\abc\us-east-1a.availabilityzone\citrix-cvad-machineprofile-instance (i-0xxxxxxxx).vm"
<!--NeedCopy-->

Creare un catalogo di macchine con una modalità di fatturazione specifica

È possibile specificare la modalità di fatturazione solo tramite PowerShell durante la creazione di un catalogo di macchine.

Per specificare la modalità di fatturazione tramite PowerShell, utilizzare il parametro CustomProperties nel comando New-ProvScheme.

$custprop = "BillingMode,Monthly"

New-ProvScheme -ProvisioningSchemeName "MyCatalog" `
-ImageVersionSpecUid $ImageVersionSpecUid `
-HostingUnitName "wsc-unit" `
-IdentityPoolName "MyIdentityPool" `
-MachineProfile "XdHyp:\HostingUnits\wsc-unit\machine-profile lt-123.launchtemplate\lt-123 (1).launchtemplateversion" `
-CustomProperties $custprop `
-CleanOnBoot
<!--NeedCopy-->

Nota:

Se la proprietà BillingMode viene omessa, il catalogo assume come impostazione predefinita Hourly.

Modificare la modalità di fatturazione di un catalogo esistente

È possibile convertire un catalogo esistente da Monthly a Hourly o viceversa. Questa modifica può essere applicata sia alle VM nuove che a quelle esistenti nel catalogo.

Considerazioni importanti per gli aggiornamenti

  • Finestra di servizio: le VM esistenti devono essere sottoposte a una finestra di servizio o a un ciclo di alimentazione per applicare la modifica della fatturazione.
  • Convalida: MCS convalida che i tipi di istanza e le piattaforme esistenti siano compatibili con la nuova modalità di fatturazione prima di applicare la modifica.

Aggiornare tramite PowerShell

  • Per aggiornare la modalità di fatturazione solo delle nuove VM aggiunte a un catalogo, aggiornare la proprietà personalizzata della modalità di fatturazione dello schema di provisioning:

     $custprop = "BillingMode,Hourly"

 Set-ProvScheme -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop
 <!--NeedCopy-->

  • Per aggiornare la modalità di fatturazione delle VM nuove ed esistenti in un catalogo, creare una nuova versione dello schema di provisioning con la proprietà personalizzata aggiornata e applicare la nuova versione a tutte le VM:

     $custprop = "BillingMode,Hourly"

 New-ProvSchemeVersion -ProvisioningSchemeName "MyCatalog" -CustomProperties $custprop

 New-ProvSchemeHardwareUpdate -ProvisioningSchemeVersion 2 `
 -StartsNow -AllVMs `
 -MaxDurationInMinutes 100 `
 -ProvisioningSchemeName "MyCatalog"
 <!--NeedCopy-->

Monitorare le informazioni di fatturazione

È possibile verificare la modalità di fatturazione per i cataloghi e le singole macchine virtuali.

Eseguire i seguenti comandi PowerShell per verificare l’idoneità alla fatturazione dell’account:

  • Restituisce BillingMode come parte di CustomProperties

     Get-ProvScheme –ProvisioningSchemeName “"MyCatalog" "  | Select  ProvisioningSchemeName,  CustomProperties
 <!--NeedCopy-->

  • Restituisce BillingMode come parte di VMInfo

     Get-ProvVMDetails –ProvisioningSchemeName “"MyCatalog" "  | Select-Object  -ExpandProperty VMInfo
 <!--NeedCopy-->

Risoluzione dei problemi e convalida

MCS include controlli preliminari per prevenire configurazioni incompatibili. Durante la creazione o la modifica del catalogo, potrebbero verificarsi i seguenti errori:

  • NoInstanceConfigFoundForBillingMode: Si verifica se l’offerta di servizi selezionata (tipo di istanza), la tenancy e il tipo di piattaforma non sono supportati per la modalità di fatturazione scelta.

  • Spot Instance Not Supported: Se si tenta di utilizzare istanze Spot con una connessione host WorkSpaces, la convalida non riesce.
  • EC2 billing restriction: Se l’account AWS utilizza il modello di fatturazione EC2 legacy, il tentativo di impostare una modalità di fatturazione mensile comporta un errore di convalida.

Creare un catalogo con la versione del modello di avvio utilizzando PowerShell

È possibile creare un catalogo di macchine MCS con una versione del modello di avvio come input del profilo macchina. È inoltre possibile aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio e da una versione del modello di avvio a una VM.

Nella console AWS EC2, è possibile fornire le informazioni di configurazione dell’istanza di un modello di avvio insieme al numero di versione. Quando si specifica la versione del modello di avvio come input del profilo macchina durante la creazione o l’aggiornamento di un catalogo di macchine, le proprietà di quella versione del modello di avvio vengono copiate nelle VM VDA con provisioning.

Le seguenti proprietà possono essere fornite utilizzando l’input del profilo macchina o esplicitamente come parametri nei comandi New-ProvScheme o Set-ProvScheme. Se vengono fornite nei comandi New-ProvScheme o Set-ProvScheme, hanno la precedenza sui valori del profilo macchina di queste proprietà.

  • Offerta di servizi
  • Reti

Nota:

Se l’offerta di servizi non è fornita nel modello di avvio del profilo macchina o come parametro nel comando New-ProvScheme, si riceve un errore appropriato.

Per creare un catalogo utilizzando la versione del modello di avvio come input del profilo macchina:

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

  3. Ottenere l’elenco delle versioni del modello di avvio di un modello di avvio. Ad esempio:

    XDHyp:\HostingUnits\test\test-mp-sard (lt-01xxxxx).launchtemplate> ls | Select FullPath
<!--NeedCopy-->

  4. Creare un pool di identità se non è stato creato. Ad esempio:

    New-AcctIdentityPool `
-IdentityPoolName "abc11" `
-NamingScheme "abc1-##" `
-NamingSchemeType Numeric `
-Domain "citrix-xxxxxx.local" `
-ZoneUid "xxxxxxxx" `
<!--NeedCopy-->

  5. Creare uno schema di provisioning con una versione del modello di avvio come input del profilo macchina. Ad esempio:

    New-ProvScheme `
-ProvisioningSchemeName "MPLT1" `
-HostingUnitUid "c7f71f6a-3f45-4xxx-xxxx-xxxxxxxxxx" `
-IdentityPoolUid "bf3a6ba2-1f80-4xxx-xxxx-xxxxxxxxx" `
-ImageVersionSpecUid ‘24dfb047-e867-527g-896c-25664xxxxx1t’ `
-CleanOnBoot `
-MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-01xxxxx).launchtemplate\lt-01xxxxx (1).launchtemplateversion"
<!--NeedCopy-->

  6. Registrare uno schema di provisioning come catalogo broker. Ad esempio:

    New-BrokerCatalog -Name "MPLT1" `
-AllocationType Random `
-Description "Machine profile catalog" `
-ProvisioningSchemeId fe7df345-244e-4xxxx-xxxxxxxxx `
-ProvisioningType Mcs `
-SessionSupport MultiSession `
-PersistUserChanges Discard
<!--NeedCopy-->
  7. Completare la creazione del catalogo.

Aggiornare l’origine del profilo macchina

È anche possibile aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio e da una versione del modello di avvio a una VM. Ad esempio:

  • Per aggiornare l’input di un catalogo di profili macchina da una VM a una versione del modello di avvio:

     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
 -MachineProfile "XDHyp:\HostingUnits\xxxx-ue1a\machineprofiletest (lt-0bxxxxxxxxxxxx).launchtemplate\lt-0bxxxxxxxxxxxx (1).launchtemplateversion"
 <!--NeedCopy-->

  • Per aggiornare l’input di un catalogo di profili macchina da una versione del modello di avvio a una VM:

     Set-ProvScheme -ProvisioningSchemeName "CloudServiceOfferingTest" `
 -MachineProfile "XDHyp:\HostingUnits\sard-ue1a\us-east-1a.availabilityzone\apollo-non-persistent-vda-win2022-2 (i-08xxxxxxxxx).vm"
 <!--NeedCopy-->

Catalogo abilitato per MCSIO

L’ottimizzazione dell’archiviazione MCS (MCSIO) migliora le prestazioni I/O delle macchine virtuali memorizzando nella cache le operazioni di scrittura su disco tramite un meccanismo a due livelli:

  • in memoria, oppure
  • su un disco dedicato ad alta velocità (overflow su disco quando la memoria è piena).

Per le istanze gestite di Amazon WorkSpaces Core, l’abilitazione di MCSIO collega un disco di cache di scrittura (WBC) a ogni VM sottoposta a provisioning, oltre ai dischi standard del sistema operativo e dell’identità.

Abilitare e configurare MCSIO utilizzando:

  • Studio
  • PowerShell

Utilizzare Studio per abilitare MCSIO

Prerequisiti

Prima di configurare MCSIO in Studio, assicurarsi di quanto segue:

  • Il driver MCSIO è installato sull’immagine master (AMI). Durante l’installazione o l’aggiornamento del VDA, selezionare l’opzione per installare il driver MCSIO. Per impostazione predefinita, il driver non è installato.
  • Una versione dell’immagine preparata viene creata da un’immagine master che include il driver MCSIO.
  • Il catalogo di macchine utilizza un’esperienza desktop non persistente (CleanOnBoot). MCSIO si applica ai cataloghi VDI non persistenti.

Creare un catalogo di macchine abilitato per MCSIO utilizzando Studio

Completare i passaggi precedenti per la creazione del catalogo (Tipo di macchina, Gestione macchine, Esperienza desktop, Immagine, Macchine virtuali, NIC, Identità macchina, Credenziali di dominio) come descritto in Creare un catalogo. Quando si raggiunge la pagina Impostazioni disco, eseguire quanto segue:

  1. Nella pagina Impostazioni disco, selezionare la casella di controllo Abilita e configura la cache di scrittura per prestazioni I/O ottimali.

  2. Configurare le impostazioni del disco della cache di scrittura:

    • Dimensioni della cache del disco (GB): Immettere le dimensioni in gigabyte del disco utilizzato per la memorizzazione nella cache. Il valore deve essere di almeno 1 GB e non deve superare le dimensioni del disco del sistema operativo.
    • Lettera dell’unità disco: Selezionare Assegnazione automatica per consentire al sistema di assegnare una lettera di unità, oppure specificare una lettera di unità manualmente.
    • Memoria allocata alla cache (MB): Immettere la quantità di memoria in megabyte da allocare per la memorizzazione nella cache. Il valore deve essere maggiore di zero e inferiore alla memoria totale della macchina.

    Nota:

    La cache write-back richiede che il driver MCSIO sia installato sull’immagine master.

  3. In Selezionare il tipo di archiviazione per il disco della cache write-back, selezionare un tipo di volume EBS SSD:

    Tipo di archiviazione:

    • SSD per uso generico (gp2)
    • SSD per uso generico (gp3)
    • SSD IOPS con provisioning (io1)
    • SSD IOPS con provisioning (io2)

    Nota:

    La memorizzazione nella cache write-back supporta solo i tipi di volume EBS SSD. I tipi di volume HDD e l’archiviazione locale dell’istanza (archiviazione effimera) non sono supportati.

  4. In Selezionare il tipo di persistenza per il disco della cache write-back, selezionare una delle seguenti opzioni:

    • Usa disco cache write-back non persistente: Il disco cache viene creato all’accensione della macchina ed eliminato allo spegnimento. Questa è l’impostazione predefinita.
    • Usa disco cache di write-back persistente: Il disco cache viene mantenuto tra i cicli di alimentazione.

  5. Sotto Disco di sistema, selezionare facoltativamente Mantieni disco di sistema durante i cicli di alimentazione per mantenere il disco del sistema operativo quando la macchina si spegne. Quando abilitato, le macchine saltano la ricreazione del disco radice dal modello ad ogni avvio, il che riduce il tempo di avvio.

    Nota:

    Per prestazioni di avvio ottimali, abilitare sia Usa disco cache di write-back persistente che Mantieni disco di sistema durante i cicli di alimentazione. Con entrambe le opzioni abilitate, le macchine riutilizzano il disco cache e il disco del sistema operativo esistenti all’avvio anziché inizializzarne di nuovi.

  6. Fare clic su Avanti per procedere con le restanti pagine della procedura guidata.

  7. Nella pagina Riepilogo, verificare le impostazioni relative a MCSIO prima di terminare. Il riepilogo visualizza i seguenti campi della cache di write-back:

    • Abilita cache disco temporanea
    • Dimensione cache di memoria (MB)
    • Dimensione cache disco (GB)
    • Persistente con disco cache di write-back
    • Tipo di disco cache di write-back
    • Lettera dell’unità del disco cache di write-back
    • Mantieni disco di sistema
  8. Immettere un nome e una descrizione facoltativa per il catalogo macchine, quindi fare clic su Fine.

Aggiornare le impostazioni MCSIO su un catalogo esistente utilizzando Studio

È possibile aggiornare le impostazioni della cache di write-back su un catalogo esistente da Modifica catalogo macchine.

Nota:

Le modifiche apportate nella pagina Impostazioni disco si applicano solo alle nuove macchine che verranno aggiunte al catalogo in seguito. Le macchine esistenti rimangono invariate.

  1. Da Cataloghi macchine, selezionare il catalogo da aggiornare e fare clic su Modifica catalogo macchine.

  2. Passare alla pagina Impostazioni disco. Aggiornare una delle seguenti impostazioni:

    • Dimensione cache disco (GB): Modificare la dimensione del disco della cache di write-back.
    • Memoria allocata alla cache (MB): Modificare la memoria allocata per la memorizzazione nella cache.
    • Tipo di archiviazione: Modificare il tipo di volume EBS per il disco della cache di write-back.
    • Tipo di persistenza: Alternare tra disco della cache di write-back persistente e non persistente.
    • Mantieni disco di sistema durante i cicli di alimentazione: Abilitare o disabilitare la conservazione del disco del sistema operativo.
  3. Fare clic su Applica per salvare senza chiudere, oppure su Salva per salvare e chiudere.

Layout del disco EBS per macchine abilitate per MCSIO

Quando MCSIO è abilitato, ogni VM Amazon WorkSpaces Core di cui è stato eseguito il provisioning ha tre volumi EBS allegati. È possibile verificare il layout del disco dalla AWS Management Console nella sezione Elastic Block Store dei dettagli dell’istanza EC2.

Disco Indice dispositivo Descrizione
Disco OS /dev/sda1 Volume root clonato dall’immagine preparata. Se l’opzione Mantieni disco di sistema durante i cicli di alimentazione è abilitata, questo disco persiste quando la macchina si spegne.
Disco di identità Disco xvdf Memorizza le informazioni sull’identità della macchina per la VM sottoposta a provisioning. Persiste sempre.
Disco della cache write-back Disco xvdg Disco cache ad alta velocità per le operazioni di scrittura MCSIO. Persiste tra i cicli di alimentazione solo se è selezionata l’opzione Usa disco cache write-back persistente.

Riferimento al comportamento della cache write-back e del disco del sistema operativo

La tabella seguente riassume il comportamento della cache write-back e del disco del sistema operativo in base alle impostazioni di persistenza selezionate.

Persistenza WBC Conservazione disco OS Allo spegnimento Prestazioni di avvio Costi di archiviazione quando la VM è spenta
Non persistente (predefinito) Disabilitato (predefinito) Sia il disco WBC che il disco del sistema operativo vengono eliminati. Nuovi dischi vengono creati al successivo avvio. Standard Nessun costo per il disco del sistema operativo o il disco WBC.
Non persistente (predefinito) Abilitato Il disco WBC viene eliminato. Il disco del sistema operativo viene mantenuto. Più veloce — salta l’inizializzazione del disco del sistema operativo Costi del disco del sistema operativo, nessun costo del disco WBC.
Persistente Disabilitato (predefinito) Il disco WBC viene mantenuto. Il disco del sistema operativo viene eliminato e ricreato dal modello al successivo avvio. Più veloce — salta l’inizializzazione di WBC Costi del disco WBC, nessun costo del disco del sistema operativo.
Persistente Abilitato Sia il disco WBC che il disco del sistema operativo vengono mantenuti. Il più veloce — nessuna inizializzazione del disco richiesta Costi del disco del sistema operativo e del disco WBC.

Nota:

L’abilitazione della conservazione del disco del sistema operativo su un catalogo non persistente significa che il disco del sistema operativo non viene reimpostato al riavvio. Ciò comporta tempi di avvio più rapidi a scapito dei costi di archiviazione del disco del sistema operativo. Tutte le scritture, tuttavia, vanno ancora solo alla cache di memoria Write-back o al disco della cache Write-back. Le modifiche dell’utente non vengono accumulate sul disco del sistema operativo anche quando si abilita la conservazione del disco del sistema operativo. Valutare in base ai requisiti dell’ambiente.

Utilizzare PowerShell per abilitare MCSIO

Creare un catalogo abilitato per MCSIO utilizzando PowerShell

I quattro parametri aggiunti al comando PowerShell New-ProvScheme sono:

  • UseWriteBackCache: Attiva la memorizzazione nella cache (cache write-back) per lo schema di provisioning specificato
  • WriteBackCacheDiskSize: Specifica la dimensione in GB del disco temporaneo utilizzato per la memorizzazione nella cache
  • WriteBackCacheMemorySize: Specifica la quantità di memoria in MB da utilizzare per la memorizzazione nella cache. Questo è un parametro facoltativo.

Nota:

  • Il valore di WriteBackCacheDiskSize deve essere maggiore di zero perché è richiesto almeno 1 GB di spazio di archiviazione su disco cache. La dimensione del disco cache non deve essere maggiore della dimensione del disco del sistema operativo.
  • Il valore di WriteBackCacheMemorySize deve essere diverso da zero e inferiore alla dimensione della memoria del catalogo macchine.

Le proprietà personalizzate che influiscono su MCSIO sono:

  • WBCDiskStorageType: Definisce il tipo di volume, che viene utilizzato per il disco temporaneo nelle istanze gestite di Amazon WorkSpaces Core. Questo parametro accetta un argomento stringa nel formato volume-type[:iops][:throughput]. Di seguito sono riportati i tipi di volume:

    • gp2: Non utilizzare i parametri iops e throughput per questo tipo di volume
    • gp3: Utilizzare i parametri iops e throughput per questo tipo di volume
    • io1: Utilizzare solo il parametro iops per questo tipo di volume
    • io2: Utilizzare solo il parametro iops per questo tipo di volume

    Il tipo di volume predefinito è gp2.

  • PersistWBC: Controlla se mantenere o eliminare il disco cache ogni volta che le istanze gestite di Amazon WorkSpaces Core vengono spente. Se impostato su true, il disco cache viene mantenuto. Se impostato su false (impostazione predefinita), il disco cache viene creato e mantenuto solo mentre l’istanza AMI è accesa.
  • PersistOSDisk: Controlla se mantenere o eliminare il disco del sistema operativo ogni volta che le istanze gestite di Amazon WorkSpaces Core vengono spente. Se impostato su true, il disco del sistema operativo viene mantenuto. Se impostato su false (impostazione predefinita), il disco del sistema operativo viene creato e mantenuto solo mentre l’istanza AMI è accesa.

Eseguire i seguenti passaggi nella finestra di PowerShell per creare un catalogo non persistente abilitato per MCSIO:

  1. Aprire la finestra di PowerShell.
  2. Eseguire asnp citrix* per caricare i moduli PowerShell specifici di Citrix.
  3. Crea un catalogo broker e un pool di identità.

  4. Crea lo schema di provisioning. Ad esempio:

    $HostingUnitUid = '0xxxx1d9-bbfc-xxxf-bxxb-exxxxxe008b2'
$MasterImageVM = 'XDHyp:\HostingUnits\ctx-test\aws-apollo-non-persistent-multi-mcsio-vda-win2022 (ami-0bf1810488acbxxxb).template'
$NetworkMap = @{ 'NetworkPath' = 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\10.0.128.0`/17 (vpc-0fa6e41d72507fxxx).network' }
$SecurityGroup = $( 'XDHyp:\HostingUnits\ctx-test\us-east-1a.availabilityzone\private.securitygroup' )
$ServiceOffering = 'XDHyp:\HostingUnits\ctx-test\T3 Medium Instance.serviceoffering'
$CustomProperties = 'WBCDiskStorageType,gp3:6000:250;PersistWBC,false'

$provScheme = New-ProvScheme -ProvisioningSchemeName $CatalogName -HostingUnitUid $HostingUnitUid `
-IdentityPoolUid $acctPool.IdentityPoolUid -CleanOnBoot `
- MasterImageVM $MasterImageVM `
-NetworkMap $NetworkMap `
-ServiceOffering $ServiceOffering `
-SecurityGroup $SecurityGroup `
-CustomProperties $CustomProperties `
-UseWriteBackCache -WriteBackCacheDiskSize 16 -WriteBackCacheMemorySize 256
<!--NeedCopy-->
  5. Aggiungi VM al catalogo.

Migliorare le prestazioni di avvio con MCSIO

È possibile migliorare le prestazioni di avvio delle VM se si abilita MCSIO e si impostano le proprietà personalizzate PersistWBC e PersistOSDisk come true. Con tale impostazione, le VM possono avviarsi più velocemente perché non devono inizializzare un nuovo disco cache o ricreare un disco radice dal loro modello.

Crittografare i dischi del sistema operativo e ID

È possibile creare un catalogo di VM con chiavi AWS KMS (chiave gestita dal cliente e chiave gestita da AWS) che possono essere utilizzate per crittografare il disco del sistema operativo e il disco di identità (ID).

  • Le chiavi gestite da AWS vengono ruotate automaticamente ogni anno.
  • Le chiavi gestite dal cliente sono opzionali per la rotazione automatica e possono essere gestite manualmente.

Per ulteriori informazioni sulle chiavi KMS, consultare i seguenti documenti AWS:

Per la crittografia dei dischi del sistema operativo e ID, configurare una delle seguenti opzioni:

  • Utilizzare un’immagine preparata crittografata (ad esempio, un’AMI creata da un’istanza o uno snapshot che contiene un volume radice EBS crittografato con chiave KMS)
  • Utilizzare un’origine del profilo macchina (VM o modello di avvio) che contenga un volume radice EBS crittografato.

Limitazioni

Considerare le seguenti limitazioni:

  • Attualmente, MCS supporta un solo disco su AMI di immagine preparata.

  • Non è possibile crittografare direttamente volumi o snapshot EBS esistenti non crittografati, né modificare la chiave KMS di un volume crittografato esistente. Per farlo, è necessario:

    1. Creare un nuovo snapshot di quel volume.
    2. Creare un nuovo volume da quello snapshot
    3. Crittografare il nuovo volume.

Consultare i seguenti documenti AWS:

Creare un catalogo con crittografia del disco

È possibile creare un catalogo macchine MCS con crittografia del disco utilizzando:

  • Immagine preparata (creata utilizzando la gestione delle immagini da un’immagine master con disco crittografato)
  • Profilo macchina

Le considerazioni durante l’utilizzo dell’input del profilo macchina sono:

  • La chiave KMS dell’input del profilo macchina ha la precedenza sulla chiave KMS dell’immagine preparata.
  • Se non viene fornito alcun input del profilo macchina, la chiave KMS dell’AMI dell’immagine preparata viene utilizzata per crittografare i dischi delle VM del catalogo.
  • Se il profilo macchina presenta mappature dei dispositivi a blocchi, i dispositivi a blocchi presenti nel modello di immagine preparata (AMI) e nel profilo macchina devono corrispondere. Ad esempio, se l’AMI ha un dispositivo definito su /dev/sda1, anche il profilo macchina deve avere un dispositivo definito su /dev/sda1.
  • Se non è presente alcuna chiave nell’origine del profilo macchina e l’immagine preparata non è crittografata, i dischi delle VM del catalogo non vengono crittografati.
  • Quando l’immagine preparata è crittografata, una VM di origine del profilo macchina o un modello di avvio deve avere un volume radice crittografato per essere considerato un input valido.

Modificare un catalogo esistente

È possibile modificare un catalogo esistente utilizzando il comando PowerShell Set-ProvScheme per avere:

  • Un input del profilo macchina con un volume contenente una nuova chiave KMS.
  • Un’immagine preparata creata dall’immagine master con AMI crittografata utilizzando la gestione delle immagini.

Considerazioni importanti:

  • I volumi delle nuove VM aggiunte al catalogo vengono crittografati con la nuova chiave KMS.
  • Per aggiornare le impostazioni di crittografia quando esiste un profilo macchina, eseguire Set-ProvScheme con un nuovo profilo macchina.
  • Non è possibile modificare un catalogo esistente da volumi crittografati a volumi non crittografati. Non è possibile eseguire un aggiornamento dell’immagine da un’AMI di immagine preparata crittografata a un’AMI di immagine preparata non crittografata.

Abilitare NitroTPM e l’avvio protetto UEFI per le istanze VM

Quando si crea un catalogo, è ora possibile selezionare un’immagine preparata (AMI) con NitroTPM e/o avvio protetto UEFI abilitati. Di conseguenza, anche le VM sottoposte a provisioning nel catalogo sono abilitate con NitroTPM e/o avvio protetto UEFI. Questa implementazione garantisce che le VM siano protette e affidabili. Per ulteriori informazioni su NitroTPM e UEFI Secure Boot, consultare la documentazione di Amazon.

Limitazioni

  • È possibile utilizzare sia NitroTPM che Secure Boot attualmente in tutte le regioni AWS (incluse le regioni AWS GovCloud (US)), ad eccezione della Cina.
  • Non è possibile abilitare NitroTPM e l’avvio protetto UEFI sui cataloghi esistenti. Se si desidera un catalogo con NitroTPM e l’avvio protetto UEFI abilitati, creare un nuovo catalogo.

Passaggi chiave

  1. Configurare l’ambiente AWS.
  2. Creare una connessione ad AWS.
  3. Creare un’immagine master (AMI) abilitata con NitroTPM e/o avvio protetto UEFI.
  4. Creare un’immagine preparata dall’immagine master. Vedere Creare un’immagine preparata per le istanze gestite di Amazon WorkSpaces Core.
  5. Creare un catalogo di macchine selezionando l’immagine preparata con NitroTPM e l’avvio protetto UEFI abilitati nel menu di creazione del catalogo di Citrix Studio o durante la creazione di uno schema di provisioning utilizzando i comandi PowerShell.

Le VM aggiunte al catalogo creato hanno NitoTPM e l’avvio protetto UEFI abilitati.

Creare un’AMI che supporti NitroTPM e l’avvio protetto UEFI

  1. È possibile creare un’AMI da una VM che ha NitroTPM e/o l’avvio protetto UEFI abilitati.

    1. Creare l’istanza utilizzando le immagini del marketplace AWS. Ad esempio, cercare TPM-Windows_Server-2022-English-Full-Base on the aws-marketplace.
    2. Scaricare VDA a sessione singola o multipla.
    3. Creare un’AMI da quella VM.

  2. Usa il comando register-image:

    --boot-mode (string)
--tpm-support (string)
<!--NeedCopy-->

    Per maggiori informazioni, vedere register-image.

Consultare i seguenti documenti AWS:

È possibile aprire una finestra PowerShell dall’host del Delivery Controller™ per verificare se un elemento specifico:

  • offerta di servizi supporta NitroTPM o l’avvio protetto UEFI

     (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.BootMode
 (Get-Item -Path “XDHyp:\HostingUnits\aws\T3 Medium Instance.serviceoffering”).AdditionalData.NitroTpmSupportVersions
 <!--NeedCopy-->

  • modello supporta NitroTPM o l’avvio protetto UEFI

     (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.BootMode

 (Get-HypInventoryItem -LiteralPath “XDHyp:\HostingUnits\aws” -ResourceType “template -Id “ID”).AdditionalData.TpmSupport
 <!--NeedCopy-->

Aggiornare l’offerta di servizi del catalogo esistente

È possibile modificare l’offerta di servizi di un catalogo esistente utilizzando Set-ProvScheme. La modifica si applica alle VM appena aggiunte. Tuttavia, si verificano errori nei seguenti scenari:

Modalità di avvio delle AMI L’AMI supporta Nitro TPM? L’offerta di servizi supporta NitroTPM e l’avvio protetto UEFI?
UEFI No No
BIOS legacy Sì No
UEFI Sì No
UEFI preferito Sì No

Copia tag sulle VM

È possibile copiare i tag sulle NIC e sui dischi (disco identità, disco cache di write-back e disco del sistema operativo) specificati nel profilo macchina nelle VM appena create in un catalogo macchine MCS. È possibile specificare questi tag in una qualsiasi delle origini del profilo macchina (istanza VM AWS o versione del modello di avvio AWS). Questa funzionalità è applicabile ai cataloghi macchine e alle VM persistenti e non persistenti.

Nota:

  • Nella console AWS EC2, non è possibile visualizzare i valori di Tag Network Interfaces in Launch Template Version Resource Tags. Tuttavia, è possibile eseguire il comando PowerShell aws ec2 describe-launch-template-versions --launch-template-id lt-0bb652503d45dcbcd --versions 12 per visualizzare le specifiche dei tag.
  • Se un’origine del profilo macchina (VM o versione del modello di avvio) ha due interfacce di rete (eni-1 ed eni-2), ed eni-1 ha il tag t1 ed eni-2 ha il tag t2, allora la VM ottiene entrambi i tag delle due interfacce di rete.

Filtrare le istanze VM usando PowerShell

Un’istanza VM AWS che si utilizza come VM del profilo macchina deve essere compatibile affinché il catalogo macchine possa essere creato e funzionare correttamente. Per elencare le istanze VM AWS che possono essere utilizzate come VM di input del profilo macchina, è possibile utilizzare il comando Get-HypInventoryItem. Il comando può impaginare e filtrare l’inventario delle VM disponibili su un’unità di hosting.

Impaginazione:

Get-HypInventoryItem supporta due modalità di impaginazione:

  • La modalità di impaginazione utilizza i parametri -MaxRecords e -Skip per restituire set di elementi:
    • -MaxRecords: Il valore predefinito è 1. Questo controlla quanti elementi restituire.
    • -Skip: Il valore predefinito è 0. Questo controlla quanti elementi saltare dall’inizio assoluto (o dalla fine assoluta) dell’elenco nell’hypervisor.
  • La modalità di scorrimento utilizza i parametri -MaxRecords, -ForwardDirection e -ContinuationToken per consentire lo scorrimento dei record:
    • -ForwardDirection: Il valore predefinito è True. Questo viene utilizzato insieme a -MaxRecords per restituire il set successivo di record corrispondenti o il set precedente di record corrispondenti.
    • -ContinuationToken: Restituisce gli elementi immediatamente dopo (o prima se ForwardDirection è false) ma non include l’elemento specificato in ContinuationToken.

Esempi di impaginazione:

  • Per restituire un singolo record del modello di macchina con il nome più basso. Il campo AdditionalData ha TotalItemsCount e TotalFilteredItemsCount:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template
 <!--NeedCopy-->

  • Per restituire 10 record del modello di macchina con il nome più basso:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 10 | select Name
 <!--NeedCopy-->

  • Per restituire un array di record che terminano con il nome più alto:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ForwardDirection $False -MaxRecords 10 | select Name
 <!--NeedCopy-->

  • Per restituire un array di record che iniziano dal modello di macchina associato al ContinuationToken specificato:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -ContinuationToken "ami-07xxxxxxxxxx" -MaxRecords 10
 <!--NeedCopy-->

Filtro:

I seguenti parametri opzionali aggiuntivi sono supportati per il filtro. È possibile combinare questi parametri con le opzioni di impaginazione.

  • -ContainsName "my_name": Se la stringa data corrisponde a parte di un nome AMI, l’AMI è inclusa nel risultato Get. Ad esempio:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -ContainName ‘apollo’ | select Name
 <!--NeedCopy-->

  • -Tags '{ "Key0": "Value0", "Key1": "Value1", "Key2": "Value2" }': Se un’AMI ha almeno uno di questi tag, è inclusa nel risultato Get. Ad esempio:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -MaxRecords 100 -Tags '{"opex owner": "Not tagged"}' | select Name
 <!--NeedCopy-->

    Nota:

    Sono supportati due valori di tag. Il valore di tag Non taggato corrisponde agli elementi che non hanno il tag specificato nel loro elenco di tag. Il valore di tag Tutti i valori corrisponde agli elementi che hanno il tag indipendentemente dal valore del tag. Altrimenti, la corrispondenza avviene solo se l’elemento ha il tag e il valore è uguale a quello specificato nel filtro.

  • -Id "ami-0a2d913927e0352f3": Se l’AMI corrisponde all’ID specificato, è inclusa nel risultato Get. Ad esempio:

     Get-HypInventoryItem -LiteralPath "XDHyp:\HostingUnits\ctx-test" -ResourceType template -Id ami-xxxxxxxxxxxxx
 <!--NeedCopy-->

Filtro sul parametro AdditionalData:

Il parametro di filtro AdditionalData elenca i modelli o le VM in base alla loro capacità, all’offerta di servizi o a qualsiasi proprietà presente in AdditionalData. Ad esempio:

(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200).AdditionalData
<!--NeedCopy-->

È anche possibile aggiungere un parametro -Warn per indicare le VM incompatibili. Le VM sono incluse con un campo AdditionalData denominato Warning. Ad esempio:

(Get-HypInventoryItem -ResourceType "launchtemplateversion" -LiteralPath "XDHyp:\HostingUnits\aws" -MaxRecords 200 -Template "ami-015xxxxxxxxx" -Warn $true).AdditionalData
<!--NeedCopy-->

Dove andare dopo

Ulteriori informazioni

Creare cataloghi utilizzando immagini preparate in Amazon WorkSpaces Core Managed Instances
August 20, 2026
Grazie al contributo di: 
C C
August 20, 2026
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.