Creare cataloghi di macchine

Importante:

A partire da Citrix Virtual Apps and Desktops™ 7 2006, se la distribuzione corrente utilizza una delle seguenti tecnologie, è possibile aggiornare la distribuzione alla versione corrente solo dopo aver rimosso gli elementi End of Life (EOL) che utilizzano tali tecnologie.

• Personal vDisks (PvDs)
• AppDisks™
• Tipi di host cloud pubblici: Citrix CloudPlatform, Microsoft Azure Classic

Per i dettagli, vedere Rimuovere PVD, AppDisks e host non supportati.

Se si desidera utilizzare connessioni host cloud pubbliche per la propria distribuzione, è necessaria una licenza Hybrid Rights per completare la nuova installazione o l’aggiornamento alla versione corrente.

Quando il programma di installazione rileva una o più tecnologie non supportate o connessioni host senza licenza Hybrid Rights, l’aggiornamento viene messo in pausa o interrotto. Viene visualizzato un messaggio esplicativo. I log del programma di installazione contengono i dettagli. Per ulteriori informazioni, vedere Aggiornare una distribuzione.

Effetto della licenza Hybrid Rights sulle connessioni host

Esistono tre scenari in cui la connessione host agli host cloud pubblici è influenzata in base al diritto di licenza Hybrid Rights:

• Per creare una connessione host agli host cloud pubblici, è necessario disporre di una licenza Hybrid Rights.

• Se si dispone di una licenza Hybrid Rights ma la licenza è scaduta, le connessioni esistenti agli host cloud pubblici vengono contrassegnate come non autorizzate ed entrano in modalità di manutenzione. Quando le connessioni host esistenti sono in modalità di manutenzione, non è possibile eseguire le seguenti operazioni:

  • Aggiungere o modificare connessioni host
  • Creare cataloghi e aggiornare immagini
  • Eseguire azioni di alimentazione

• Quando le connessioni host non autorizzate diventano autorizzate, le connessioni di hosting esistenti vengono riabilitate.

Introduzione

Le raccolte di macchine fisiche o virtuali sono gestite come una singola entità chiamata catalogo di macchine. Le macchine in un catalogo hanno lo stesso tipo di sistema operativo: sistema operativo multi-sessione o sistema operativo a sessione singola. Un catalogo contenente macchine con sistema operativo multi-sessione può contenere macchine Windows o Linux, ma non entrambe.

Citrix Studio guida l’utente nella creazione del primo catalogo di macchine dopo aver creato il sito. Dopo aver creato il primo catalogo, Studio guida l’utente nella creazione del primo gruppo di distribuzione. Successivamente, è possibile modificare il catalogo creato e crearne altri.

Suggerimento:

L’aggiornamento di una distribuzione esistente abilita la funzionalità di ottimizzazione dello storage di Machine Creation Services (MCS) (MCS I/O), non è richiesta alcuna configurazione aggiuntiva. L’aggiornamento del Virtual Delivery Agent (VDA) e del Delivery Controller gestisce l’aggiornamento di MCS I/O.

Panoramica

Quando si crea un catalogo di VM, si specifica come eseguire il provisioning di tali VM. È possibile utilizzare strumenti Citrix come Machine Creation Services™ (MCS) o Citrix Provisioning (precedentemente Provisioning Services). Oppure, è possibile utilizzare i propri strumenti per fornire le macchine.

Considerare:

• MCS supporta un singolo disco di sistema dall’immagine della macchina virtuale. Ignora il resto dei dischi dati collegati a tale immagine.
• Se si utilizza Citrix Provisioning per creare macchine, consultare la documentazione di Citrix Provisioning per le istruzioni.
• Se si utilizza MCS per il provisioning delle VM, si fornisce un’immagine master (o uno snapshot di un’immagine) per creare VM identiche nel catalogo. Prima di creare il catalogo, si utilizzano prima gli strumenti per creare e configurare l’immagine master. Questo processo include l’installazione di un Virtual Delivery Agent (VDA) sull’immagine. Quindi si crea il catalogo di macchine in Studio. Si seleziona quell’immagine (o snapshot), si specifica il numero di VM da creare nel catalogo e si configurano informazioni aggiuntive.
• Se le macchine sono già disponibili, è comunque necessario creare uno o più cataloghi di macchine per tali macchine.
• Se si sta creando un catalogo direttamente utilizzando l’SDK PowerShell, è possibile specificare un modello di hypervisor (VMTemplates), anziché un’immagine o uno snapshot.
• L’utilizzo di un modello per il provisioning di un catalogo è considerato una funzionalità sperimentale. Quando si utilizza questo metodo, la preparazione della macchina virtuale potrebbe fallire. Di conseguenza, il catalogo non può essere pubblicato utilizzando il modello.

Quando si utilizza MCS o Citrix Provisioning™ per creare il primo catalogo, si utilizza la connessione host configurata al momento della creazione del sito. Successivamente (dopo aver creato il primo catalogo e gruppo di distribuzione), è possibile modificare le informazioni su tale connessione o creare altre connessioni.

Dopo aver completato la procedura guidata di creazione del catalogo, vengono eseguiti automaticamente dei test per assicurarsi che sia configurato correttamente. Al termine dei test, è possibile visualizzare un rapporto di test. Eseguire i test in qualsiasi momento da Studio.

Nota:

MCS non supporta Windows 10 IoT Core e Windows 10 IoT Enterprise. Fare riferimento al sito Microsoft per maggiori informazioni.

Per dettagli tecnici sugli strumenti di Citrix Provisioning, vedere Citrix Virtual Apps and Desktops Image Management.

Controllo licenza RDS

Citrix Studio attualmente non esegue il controllo delle licenze Microsoft RDS valide durante la creazione di un catalogo di macchine che contiene macchine con sistema operativo Windows multi-sessione. Per visualizzare lo stato della licenza Microsoft RDS per una macchina con sistema operativo Windows multi-sessione, andare a Citrix Director. Visualizzare lo stato della licenza Microsoft RDS nel pannello Dettagli macchina. Questo pannello si trova nella pagina Dettagli macchina e Dettagli utente. Per maggiori informazioni, vedere Stato della licenza Microsoft RDS.

Registrazione VDA

Un VDA deve essere registrato con un Delivery Controller™ quando si avviano sessioni mediate. I VDA non registrati possono comportare un sottoutilizzo delle risorse altrimenti disponibili. Esistono varie ragioni per cui un VDA potrebbe non essere registrato, molte delle quali un amministratore può risolvere. Studio fornisce informazioni sulla risoluzione dei problemi nella procedura guidata di creazione del catalogo e dopo aver aggiunto macchine da un catalogo a un gruppo di distribuzione.

Dopo aver aggiunto macchine esistenti utilizzando la procedura guidata, l’elenco dei nomi degli account computer indica se ogni macchina è idonea per l’aggiunta al catalogo. Passare il mouse sull’icona accanto a ciascuna macchina per visualizzare un messaggio informativo su quella macchina.

Se il messaggio identifica una macchina problematica, rimuovere quella macchina o aggiungerla. Ad esempio, se un messaggio indica che le informazioni potrebbero non essere ottenute su una macchina, aggiungere comunque la macchina.

Per maggiori informazioni, vedere:

• CTX136668 per la guida alla risoluzione dei problemi di registrazione VDA
• Versioni VDA e livelli funzionali
• Metodi di registrazione VDA

Riepilogo creazione catalogo MCS

Ecco una breve panoramica delle azioni MCS predefinite dopo aver fornito le informazioni nella procedura guidata di creazione del catalogo.

• Se è stata selezionata un’immagine master (anziché uno snapshot), MCS crea uno snapshot.
• MCS crea una copia completa dello snapshot e la posiziona su ogni posizione di storage definita nella connessione host.
• MCS aggiunge le macchine ad Active Directory, il che crea identità univoche.
• MCS crea il numero di VM specificato nella procedura guidata, con due dischi definiti per ogni VM. Oltre ai due dischi per VM, un master viene anche memorizzato nella stessa posizione di storage. Se sono definite più posizioni di storage, ognuna ottiene i seguenti tipi di disco:
  • La copia completa dello snapshot che è di sola lettura e condivisa tra le VM appena create.
  • Un disco di identità univoco da 16 MB che conferisce a ogni VM un’identità univoca. Ogni VM ottiene un disco di identità.
  • Un disco di differenza univoco per memorizzare le scritture effettuate sulla VM. Questo disco è con provisioning leggero (se supportato dallo storage host) e aumenta fino alla dimensione massima dell’immagine master, se necessario. Ogni VM ottiene un disco di differenza. Il disco di differenza contiene le modifiche apportate durante le sessioni. È permanente per i desktop dedicati. Per i desktop in pool, viene eliminato e ne viene creato uno nuovo dopo ogni riavvio tramite il controller di distribuzione.

In alternativa, quando si creano VM per fornire desktop statici, è possibile specificare (nella pagina Macchine della procedura guidata di creazione del catalogo) cloni VM thick (copia completa). I cloni completi non richiedono la conservazione dell’immagine master su ogni datastore. Ogni VM ha il proprio file.

Considerazioni sullo storage MCS

Ci sono molti fattori da considerare quando si decide sulle soluzioni di storage, configurazioni e capacità per MCS. Le seguenti informazioni forniscono considerazioni appropriate per la capacità di storage:

Considerazioni sulla capacità:

• Dischi

  I dischi Delta o Differencing (Diff) consumano la maggior quantità di spazio nella maggior parte delle distribuzioni MCS per ogni VM. Ogni VM creata da MCS riceve almeno 2 dischi al momento della creazione.

  • Disk0 = Disco Diff: contiene il sistema operativo quando copiato dall’immagine base master.
  • Disk1 = Disco di identità: 16 MB - contiene i dati di Active Directory per ogni VM.

  Man mano che il prodotto si evolve, potrebbe essere necessario aggiungere altri dischi per soddisfare determinati casi d’uso e consumo di funzionalità. Ad esempio:

  • Ottimizzazione dello storage MCS crea un disco di tipo cache di scrittura per ogni VM. Negli ambienti di virtualizzazione XenServer, VMware e SCVMM, MCS posiziona il disco di cache di scrittura (WBC) nella stessa posizione di storage del disco del sistema operativo se si configura l’elenco di storage del sistema operativo disponibile allo stesso modo dell’elenco di storage temporaneo disponibile durante la creazione di una connessione host.
  • MCS ha aggiunto la possibilità di utilizzare cloni completi anziché lo scenario del disco Delta descritto nella sezione precedente.

  Anche le funzionalità dell’hypervisor potrebbero entrare in gioco. Ad esempio:

  • Citrix Hypervisor IntelliCache crea un disco di lettura sullo storage locale per ogni Citrix Hypervisor. Questa opzione consente di risparmiare IOPS rispetto all’immagine master che potrebbe essere conservata nella posizione di storage condivisa.

• Overhead dell’hypervisor

  Diversi hypervisor utilizzano file specifici che creano overhead per le VM. Gli hypervisor utilizzano anche lo storage per la gestione e le operazioni di logging generali. Calcolare lo spazio per includere l’overhead per:

  • File di log
  • File specifici dell’hypervisor. Ad esempio:
    • VMware aggiunge altri file alla cartella VM storage. Vedere VMware Best Practices.
    • Calcolare i requisiti totali di dimensione della macchina virtuale. Considerare una macchina virtuale contenente 20 GB per il disco virtuale, 16 GB per il file di swap e 100 MB per i file di log che consumano un totale di 36,1 GB.
  • Snapshot per XenServer; Snapshot per VMware.

• Overhead di processo

  La creazione di un catalogo, l’aggiunta di una macchina e l’aggiornamento di un catalogo hanno implicazioni di storage uniche. Ad esempio:

  • La creazione iniziale del catalogo richiede che una copia del disco base venga copiata in ogni posizione di storage.
    • Richiede anche la creazione temporanea di una VM di preparazione.
  • L’aggiunta di una macchina a un catalogo non richiede la copia del disco base in ogni posizione di storage. La creazione del catalogo varia in base alle funzionalità selezionate.
  • L’aggiornamento del catalogo per creare un disco base aggiuntivo in ogni posizione di storage. Gli aggiornamenti del catalogo subiscono anche un picco di storage temporaneo in cui ogni VM nel catalogo ha 2 dischi Diff per un certo periodo di tempo.

Altre considerazioni:

• Dimensionamento della RAM: Influisce sulla dimensione di alcuni file e dischi dell’hypervisor, inclusi i dischi di ottimizzazione I/O, la cache di scrittura e i file snapshot.
• Provisioning thin/thick: Lo storage NFS è preferito grazie alle sue capacità di provisioning thin.

Ottimizzazione dello storage di Machine Creation Services (MCS)

Con la funzionalità di ottimizzazione dello storage di Machine Creation Services (MCS), denominata MCS I/O:

• Il contenitore della cache di scrittura è basato su file, la stessa funzionalità presente in Citrix Provisioning. Ad esempio, il nome del file della cache di scrittura di Citrix Provisioning è D:\vdiskdif.vhdx e il nome del file della cache di scrittura di MCS I/O è D:\mcsdif.vhdx.
• Si ottengono miglioramenti diagnostici includendo il supporto per un file di dump di arresto anomalo di Windows scritto sul disco della cache di scrittura.
• MCS I/O mantiene la tecnologia cache in RAM con overflow su disco rigido per fornire la soluzione di cache di scrittura multi-tier più ottimale. Questa funzionalità consente a un amministratore di bilanciare tra il costo in ogni tier, RAM e disco, e le prestazioni per soddisfare le aspettative del carico di lavoro desiderato.

L’aggiornamento del metodo della cache di scrittura da basato su disco a basato su file richiede le seguenti modifiche:

1. MCS I/O non supporta più la cache solo RAM. Specificare una dimensione del disco in Citrix Studio durante la creazione del catalogo di macchine.
2. Il disco della cache di scrittura della VM viene creato e formattato automaticamente all’avvio di una VM per la prima volta. Una volta che la VM è attiva, il file della cache di scrittura mcsdif.vhdx viene scritto nel volume formattato MCSWCDisk.
3. Il file di paging viene reindirizzato a questo volume formattato, MCSWCDisk. Di conseguenza, questa dimensione del disco considera la quantità totale di spazio su disco. Include la differenza tra la dimensione del disco e il carico di lavoro generato più la dimensione del file di paging. Questo è tipicamente associato alla dimensione della RAM della VM.

Abilitazione degli aggiornamenti di ottimizzazione dello storage MCS

Per abilitare la funzionalità di ottimizzazione dello storage MCS I/O, aggiornare il Delivery Controller e il VDA all’ultima versione di Citrix Virtual Apps and Desktops.

Nota:

Se si aggiorna una distribuzione esistente che ha MCS I/O abilitato, non è richiesta alcuna configurazione aggiuntiva. L’aggiornamento del VDA e del Delivery Controller gestisce l’aggiornamento di MCS I/O.

Quando si abilita l’aggiornamento dell’ottimizzazione dello storage MCS, considerare quanto segue:

• Quando si crea un catalogo di macchine, l’amministratore può configurare la RAM e la dimensione del disco.

  

• L’aggiornamento di un catalogo di macchine esistente a un nuovo snapshot VM contenente un VDA configurato per la versione 1903 comporta il seguente comportamento: il nuovo snapshot continua a utilizzare l’impostazione MCS I/O del catalogo esistente per la RAM e la dimensione del disco. Il disco raw esistente viene formattato.

Importante:

L’ottimizzazione dello storage MCS è cambiata con Citrix Virtual Apps and Desktops versione 1903. Questa versione supporta la tecnologia di cache di scrittura basata su file, fornendo migliori prestazioni e stabilità. La nuova funzionalità fornita da MCS I/O potrebbe richiedere un requisito di storage della cache di scrittura più elevato rispetto alle precedenti versioni di Citrix Virtual Apps and Desktops. Citrix raccomanda di rivalutare la dimensione del disco per assicurarsi che abbia spazio su disco sufficiente per il flusso di lavoro allocato e la dimensione aggiuntiva del file di paging. La dimensione del file di paging è tipicamente correlata alla quantità di RAM di sistema. Se la dimensione del disco del catalogo esistente è insufficiente, creare un catalogo di macchine e allocare un disco di cache di scrittura più grande.

Utilizzo di PowerShell per creare un catalogo con disco di cache di scrittura persistente

Per configurare un catalogo con disco di cache di scrittura persistente, utilizzare il parametro PowerShell New-ProvScheme CustomProperties. Questo parametro supporta una proprietà aggiuntiva, PersistWBC, utilizzata per determinare come il disco della cache di scrittura persiste per le macchine con provisioning MCS. La proprietà PersistWBC viene utilizzata solo quando il parametro UseWriteBackCache è specificato e quando il parametro WriteBackCacheDiskSize è impostato per indicare che viene creato un disco.

Esempi di proprietà trovate nel parametro CustomProperties prima di supportare 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-->

Quando si utilizzano queste proprietà, considerare che contengono valori predefiniti se le proprietà sono 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 scrittura quando l’amministratore di Citrix Virtual Apps and Desktops spegne la macchina utilizzando Citrix Studio.

L’impostazione della proprietà PersistWBC su false elimina il disco della cache di scrittura quando l’amministratore di Citrix Virtual Apps and Desktops spegne la macchina utilizzando Citrix Studio.

Nota:

Se la proprietà PersistWBC viene omessa, la proprietà assume il valore predefinito false e la cache di scrittura viene eliminata quando la macchina viene spenta utilizzando Citrix Studio.

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 scrittura quando una macchina viene spenta.

Ad esempio, impostare New-ProvScheme per utilizzare la cache di scrittura 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-->

Preparare un’immagine master

Per informazioni sulla creazione di host di connessione, vedere Connessioni e risorse.

L’immagine master contiene il sistema operativo, le applicazioni non virtualizzate, il VDA e altro software.

Buono a sapersi:

• Un’immagine master può anche essere conosciuta come immagine clone, immagine golden, VM base o immagine base. I fornitori di host utilizzano termini diversi.
• Quando si utilizza Citrix Provisioning, è possibile utilizzare un’immagine master o un computer fisico come dispositivo di destinazione master. Citrix Provisioning utilizza una terminologia diversa da MCS per riferirsi alle immagini. Vedere la documentazione di Citrix Provisioning per i dettagli.
• Assicurarsi che l’host abbia abbastanza processori, memoria e storage per ospitare il numero di macchine create.
• Configurare la quantità corretta di spazio su disco rigido necessaria per desktop e applicazioni. Tale valore non può essere modificato in seguito o nel catalogo di macchine.
• I cataloghi di macchine Remote PC Access non utilizzano immagini master.
• Considerazioni sull’attivazione di Microsoft KMS quando si utilizza MCS: se la distribuzione include VDA 7.x con un host XenServer 6.1 o 6.2, vSphere o Microsoft System Center Virtual Machine Manager, non è necessario riarmare manualmente Microsoft Windows o Microsoft Office.

Installare e configurare il seguente software sull’immagine master:

• Strumenti di integrazione per l’hypervisor (come Citrix VM Tools, Servizi di integrazione Hyper-V o VMware Tools). Se si omette questo passaggio, le applicazioni e i desktop potrebbero non funzionare correttamente.
• Un VDA. Citrix raccomanda di installare la versione più recente per consentire l’accesso alle funzionalità più recenti. La mancata installazione di un VDA sull’immagine master causa il fallimento della creazione del catalogo.
• Strumenti di terze parti, se necessario, come software antivirus o agenti di distribuzione software elettronica. Configurare i servizi con impostazioni appropriate per gli utenti e il tipo di macchina (ad esempio, funzionalità di aggiornamento).
• Applicazioni di terze parti che non si stanno virtualizzando. Citrix raccomanda di virtualizzare le applicazioni. La virtualizzazione riduce i costi eliminando la necessità di aggiornare l’immagine master dopo l’aggiunta o la riconfigurazione di un’applicazione. Inoltre, un minor numero di applicazioni installate riduce la dimensione dei dischi rigidi dell’immagine master, il che consente di risparmiare sui costi di storage.
• Client App-V con le impostazioni consigliate, se si prevede di pubblicare applicazioni App-V. Il client App-V è disponibile da Microsoft.
• Quando si utilizza MCS, se si localizza Microsoft Windows, installare le impostazioni locali e i language pack. Durante il provisioning, quando viene creato uno snapshot, le VM con provisioning utilizzano le impostazioni locali e i language pack installati.

Importante:

Se si utilizza Citrix Provisioning o MCS, non eseguire Sysprep sulle immagini master.

Per preparare un’immagine master:

1. Utilizzando lo strumento di gestione dell’hypervisor, creare un’immagine master e quindi installare il sistema operativo, più tutti i service pack e gli aggiornamenti. Specificare il numero di vCPU. È anche possibile specificare il valore vCPU se si crea il catalogo di macchine utilizzando PowerShell. Non è possibile specificare il numero di vCPU quando si crea un catalogo utilizzando Studio. Configurare la quantità di spazio su disco rigido necessaria per desktop e applicazioni. Tale valore non può essere modificato in seguito o nel catalogo.
2. Assicurarsi che il disco rigido sia collegato alla posizione del dispositivo 0. La maggior parte dei modelli di immagine master standard configura questa posizione per impostazione predefinita, ma alcuni modelli personalizzati potrebbero non farlo.
3. Installare e configurare il software elencato sopra sull’immagine master.
4. Quando si utilizza Citrix Provisioning, creare un file VHD per il disco virtuale dal dispositivo di destinazione master prima di unire il dispositivo di destinazione master a un dominio. Vedere la documentazione di Citrix Provisioning per i dettagli.
5. Se non si utilizza MCS, unire l’immagine master al dominio di cui fanno parte le applicazioni e i desktop. Assicurarsi che l’immagine master sia disponibile sull’host in cui vengono create le macchine. Se si utilizza MCS, non è necessario unire l’immagine master a un dominio. Le macchine con provisioning vengono unite al dominio specificato nella procedura guidata di creazione del catalogo.
6. Citrix raccomanda di creare e nominare uno snapshot dell’immagine master. Se si specifica un’immagine master anziché uno snapshot durante la creazione di un catalogo, Studio crea uno snapshot. Non è possibile nominarlo.

Creare un catalogo di macchine utilizzando Studio

Prima di avviare la procedura guidata di creazione del catalogo, rivedere questa sezione.

Se si utilizza un’immagine master, assicurarsi di aver installato un VDA sull’immagine prima di creare il catalogo.

Da Studio:

• Se si è già creato un sito ma non si è ancora creato un catalogo di macchine, Studio guida l’utente al punto di partenza corretto per creare un catalogo.
• Se si è già creato un catalogo e si desidera crearne un altro, selezionare Cataloghi di macchine nel riquadro di navigazione di Studio. Quindi selezionare Crea catalogo di macchine nel riquadro Azioni.

La procedura guidata guida l’utente attraverso i seguenti elementi. Le pagine della procedura guidata visualizzate differiscono a seconda delle selezioni effettuate.

Sistema operativo

Ogni catalogo contiene macchine di un solo tipo. Selezionare uno.

• Sistema operativo multi-sessione: Un catalogo di sistema operativo multi-sessione fornisce desktop condivisi ospitati. Le macchine possono eseguire versioni supportate dei sistemi operativi Windows o Linux, ma il catalogo non può contenere entrambi. (Vedere la documentazione di Linux VDA per i dettagli su quel sistema operativo.)
• Sistema operativo a sessione singola: Un catalogo di sistema operativo a sessione singola fornisce desktop VDI che è possibile assegnare a vari utenti diversi.
• Accesso remoto al PC: Un catalogo di accesso remoto al PC fornisce agli utenti l’accesso remoto ai loro computer desktop fisici dell’ufficio. L’accesso remoto al PC non richiede una VPN per fornire sicurezza.

Gestione macchine

Questa pagina non viene visualizzata quando si creano cataloghi di accesso remoto al PC.

La pagina Gestione macchine indica come vengono gestite le macchine e quale strumento si utilizza per distribuire le macchine.

Scegliere se le macchine nel catalogo sono gestite dall’alimentazione tramite Studio.

• Le macchine sono gestite dall’alimentazione tramite Studio, ad esempio VM o PC blade. Questa opzione è disponibile solo se è già stata configurata una connessione a un host.
• Le macchine non sono gestite dall’alimentazione tramite Studio, ad esempio macchine fisiche.

Se si è indicato che le macchine sono gestite dall’alimentazione tramite Studio, scegliere quale strumento utilizzare per creare le VM.

• Citrix Machine Creation Services (MCS): Utilizza un’immagine master per creare e gestire macchine virtuali. MCS non è disponibile per le macchine fisiche.

• Citrix Provisioning: (Precedentemente Provisioning Services.) Gestisce i dispositivi di destinazione come una raccolta di dispositivi. Un disco virtuale di Citrix Provisioning creato da un dispositivo di destinazione master fornisce desktop e applicazioni.

  Nota:

  Questa opzione non è più supportata. Per importare un dispositivo di destinazione di Citrix Provisioning in un catalogo di Citrix Virtual Apps and Desktops, utilizzare la Procedura guidata di esportazione dispositivi di Citrix Provisioning.

• Altro: Uno strumento che gestisce le macchine già presenti nel data center. Citrix raccomanda di utilizzare Microsoft System Center Configuration Manager o un’altra applicazione di terze parti per garantire che le macchine nel catalogo siano coerenti.

Tipi di desktop (esperienza desktop)

Questa pagina viene visualizzata solo quando si crea un catalogo contenente macchine con sistema operativo a sessione singola.

La pagina Esperienza desktop determina cosa accade ogni volta che un utente effettua l’accesso. Selezionare uno di:

• Gli utenti si connettono a un nuovo desktop (casuale) ogni volta che effettuano l’accesso.
• Gli utenti si connettono allo stesso desktop (statico) ogni volta che effettuano l’accesso.

Se si sceglie la seconda opzione e si utilizza MCS per il provisioning delle macchine, è possibile configurare come vengono gestite le modifiche dell’utente al desktop:

• Salvare le modifiche dell’utente al desktop sul disco locale.
• Scartare le modifiche dell’utente e cancellare il desktop virtuale quando l’utente si disconnette. Selezionare questa opzione se si utilizza il livello di personalizzazione dell’utente.

Immagine master

Questa pagina viene visualizzata solo quando si utilizza MCS per creare VM.

Nella pagina Immagine master, selezionare la connessione all’host, quindi selezionare lo snapshot o la VM creata in precedenza. Se si sta creando il primo catalogo, l’unica connessione disponibile è quella configurata al momento della creazione del sito.

Ricordare:

• Quando si utilizza MCS o Citrix Provisioning, non eseguire Sysprep sulle immagini master.
• Se si specifica un’immagine master anziché uno snapshot, Studio crea uno snapshot, ma non è possibile nominarlo.

Per abilitare l’uso delle funzionalità più recenti del prodotto, assicurarsi che l’immagine master abbia installata la versione VDA più recente. Non modificare la selezione predefinita del VDA minimo. Tuttavia, se è necessario utilizzare una versione VDA precedente, vedere Versioni VDA e livelli funzionali.

Viene visualizzato un messaggio di errore se si seleziona uno snapshot o una VM non compatibile con la tecnologia di gestione delle macchine selezionata in precedenza nella procedura guidata.

Raccolta di dispositivi

Questa pagina viene visualizzata solo quando si utilizza Citrix Provisioning per creare VM.

La pagina Raccolta di dispositivi visualizza le raccolte di dispositivi e i dispositivi che non sono stati ancora aggiunti ai cataloghi.

Selezionare le raccolte di dispositivi da utilizzare.

Macchine

Questa pagina non viene visualizzata quando si creano cataloghi di accesso remoto al PC.

Il titolo di questa pagina dipende da ciò che è stato selezionato nella pagina Gestione macchine: Macchine, Macchine virtuali o VM e utenti.

Quando si utilizza MCS:

• Specificare quante macchine virtuali creare.
• Scegliere la quantità di memoria (in MB) che ogni VM deve avere.
• Ogni VM creata ha un disco rigido. La sua dimensione è impostata nell’immagine master. Non è possibile modificare la dimensione del disco rigido nel catalogo.
• Se la distribuzione contiene più di una zona, è possibile selezionare una zona per il catalogo.
• Se si stanno creando VM desktop statiche, selezionare una modalità di copia della macchina virtuale. Vedere Modalità di copia della macchina virtuale.
• Se si stanno creando VM desktop casuali che non utilizzano vDisk, è possibile configurare una cache da utilizzare per i dati temporanei su ogni macchina. Vedere Configurare la cache per i dati temporanei.

Quando si utilizza Citrix Provisioning:

La pagina Dispositivi elenca le macchine nella raccolta di dispositivi selezionata nella pagina precedente della procedura guidata. Non è possibile aggiungere o rimuovere macchine in questa pagina.

Quando si utilizzano altri strumenti:

Aggiungere (o importare un elenco di) nomi di account macchina di Active Directory. È possibile modificare il nome dell’account Active Directory per una VM dopo averla aggiunta/importata. Se sono state specificate macchine statiche nella pagina Esperienza desktop, è possibile specificare facoltativamente il nome utente di Active Directory per ogni VM aggiunta.

Dopo aver aggiunto o importato nomi, è possibile utilizzare il pulsante Rimuovi per eliminare i nomi dall’elenco, mentre si è ancora in questa pagina.

Quando si utilizza Citrix Provisioning o altri strumenti (ma non MCS):

Un’icona e un tooltip per ogni macchina aggiunta (o importata, o da una raccolta di dispositivi Citrix Provisioning) aiutano a identificare le macchine che potrebbero non essere idonee per l’aggiunta al catalogo o non essere in grado di registrarsi con un Delivery Controller. Per i dettagli, vedere Versioni VDA e livelli funzionali.

Modalità di copia della macchina virtuale

La modalità di copia specificata nella pagina Macchine determina se MCS crea cloni thin (copia veloce) o thick (copia completa) dall’immagine master. (Predefinito = cloni thin)

• Utilizzare cloni a copia veloce per un uso più efficiente dello storage e una creazione più rapida delle macchine.
• Utilizzare cloni a copia completa per un migliore recupero dei dati e supporto alla migrazione, con IOPS potenzialmente ridotti dopo la creazione delle macchine.

Versioni VDA e livelli funzionali

Il livello funzionale di un catalogo controlla quali funzionalità del prodotto sono disponibili per le macchine nel catalogo. L’utilizzo di funzionalità introdotte in nuove versioni del prodotto richiede un nuovo VDA. L’impostazione di un livello funzionale rende tutte le funzionalità introdotte in quella versione (e successive, se il livello funzionale non cambia) disponibili per le macchine nel catalogo. Tuttavia, le macchine in quel catalogo con una versione VDA precedente non possono registrarsi.

Un menu nella parte inferiore della pagina Macchine (o Dispositivi) consente di selezionare il livello VDA minimo. Questo imposta il livello funzionale minimo del catalogo. Per impostazione predefinita, viene selezionato il livello funzionale più recente per le distribuzioni on-premise. Se si segue la raccomandazione di Citrix di installare e aggiornare sempre i VDA e i componenti principali all’ultima versione, non è necessario modificare questa selezione. Tuttavia, se è necessario continuare a utilizzare versioni VDA precedenti, selezionare il valore corretto.

Una release di Citrix Virtual Apps and Desktops potrebbe non includere una nuova versione VDA, oppure il nuovo VDA non influisce sul livello funzionale. In tali casi, il livello funzionale potrebbe indicare una versione VDA precedente rispetto ai componenti installati o aggiornati. Ad esempio, sebbene la versione 7.17 contenga un VDA 7.17, il livello funzionale predefinito (“7.9 o successivo”) rimane il più recente. Pertanto, dopo aver installato o aggiornato i componenti 7.9–7.16 alla 7.17, non è necessario modificare il livello funzionale predefinito. L’articolo Novità di ogni release indica eventuali modifiche al livello funzionale predefinito.

Il livello funzionale selezionato influisce sull’elenco delle macchine sopra di esso. Nell’elenco, un tooltip accanto a ogni voce indica se il VDA della macchina è compatibile con il catalogo a quel livello funzionale.

Vengono visualizzati messaggi sulla pagina se il VDA su ogni macchina non soddisfa o supera il livello funzionale minimo selezionato. È possibile continuare con la procedura guidata. È probabile che tali macchine non siano in grado di registrarsi con un Controller in seguito. In alternativa, è possibile:

• Rimuovere le macchine contenenti VDA più vecchi dall’elenco, aggiornare i loro VDA e quindi aggiungerle nuovamente al catalogo.
• Scegliere un livello funzionale inferiore che impedisce l’accesso alle funzionalità più recenti del prodotto.

Viene visualizzato un messaggio anche se una macchina non è stata aggiunta al catalogo perché è del tipo di macchina sbagliato. Gli esempi includono il tentativo di aggiungere un server a un catalogo di sistema operativo a sessione singola o l’aggiunta di una macchina con sistema operativo a sessione singola originariamente creata per l’allocazione casuale a un catalogo di macchine statiche.

Importante:

Alla release 1811, è stato aggiunto un livello funzionale extra: 1811 (o più recente). Tale livello è destinato all’uso con future funzionalità di Citrix Virtual Apps and Desktops. La selezione 7.9 (o più recente) rimane l’impostazione predefinita. Tale impostazione predefinita è valida per tutte le distribuzioni ora.

Se si seleziona 1811 (o più recente), qualsiasi versione VDA precedente in quel catalogo non sarà in grado di registrarsi con un Controller. Tuttavia, se il catalogo contiene solo VDA alla versione 1811 o versioni supportate successive, sono tutti idonei per la registrazione. Ciò include i cataloghi contenenti VDA configurati per release successive di Citrix Virtual Apps and Desktops, incluse la versione 1903 e altre release 19XX precedenti alla release corrente.

Configurare la cache per i dati temporanei

La memorizzazione nella cache dei dati temporanei localmente sulla VM è facoltativa. È possibile abilitare l’uso della cache dei dati temporanei sulla macchina quando si utilizza MCS per gestire macchine in pool (non dedicate) in un catalogo. Se il catalogo utilizza una connessione che specifica lo storage per i dati temporanei, è possibile abilitare e configurare le informazioni sulla cache dei dati temporanei durante la creazione del catalogo.

Importante:

Questa funzionalità richiede un driver MCS I/O corrente. L’installazione di questo driver è un’opzione quando si installa o si aggiorna un VDA. Per impostazione predefinita, tale driver non è installato.

Si specifica se i dati temporanei utilizzano storage condiviso o locale quando si crea la connessione utilizzata dal catalogo. Per maggiori informazioni, vedere Connessioni e risorse. Per configurare una cache per i dati temporanei su ogni macchina, è possibile utilizzare le seguenti due opzioni: Memoria allocata alla cache (MB) e Dimensione cache disco (GB). Per impostazione predefinita, le due opzioni sono deselezionate. Per abilitare l’opzione Memoria allocata alla cache (MB), selezionare la casella di controllo Dimensione cache disco (GB). Se la casella di controllo Dimensione cache disco non è selezionata, l’opzione Memoria allocata alla cache è disattivata. A seconda del tipo di connessione, i valori predefiniti per queste opzioni potrebbero differire. In generale, i valori predefiniti sono sufficienti per la maggior parte dei casi. Tuttavia, tenere conto dello spazio necessario per:

• File di dati temporanei creati da Windows stesso, incluso il file di paging di Windows.
• Dati del profilo utente.
• Dati ShareFile sincronizzati con le sessioni degli utenti.
• Dati che potrebbero essere creati o copiati da un utente di sessione o da qualsiasi applicazione che gli utenti potrebbero installare all’interno della sessione.

Per configurare una cache per i dati temporanei su ogni macchina, tenere presente i seguenti tre scenari:

• Se non si selezionano le caselle di controllo Dimensione cache disco e Memoria allocata alla cache, i dati temporanei non vengono memorizzati nella cache. Vengono scritti direttamente sul disco di differenza (situato nello storage del sistema operativo) per ogni VM. (Questa è l’azione di provisioning nella versione 7.8 e precedenti.)
• Se si seleziona la casella di controllo Dimensione cache disco e non si seleziona la casella di controllo Memoria allocata alla cache, i dati temporanei vengono scritti direttamente sul disco della cache, utilizzando una quantità minima di cache di memoria.
• Se si selezionano le caselle di controllo Dimensione cache disco e Memoria allocata alla cache, i dati temporanei vengono inizialmente scritti nella cache di memoria. Quando la cache di memoria raggiunge il limite configurato (il valore Memoria allocata alla cache), i dati più vecchi vengono spostati sul disco della cache dei dati temporanei.

Importante:

• Se la cache del disco esaurisce lo spazio, la sessione dell’utente diventa inutilizzabile.
• Questa funzionalità non è disponibile quando si utilizza una connessione host Nutanix.
• Non è possibile modificare i valori della cache in un catalogo di macchine dopo la creazione della macchina.

Nota:

• La cache di memoria fa parte della quantità totale di memoria su ogni macchina. Pertanto, se si abilita l’opzione Memoria allocata alla cache, considerare di aumentare la quantità totale di memoria su ogni macchina.
• La modifica della Dimensione cache disco dal suo valore predefinito può influire sulle prestazioni. La dimensione deve corrispondere ai requisiti dell’utente e al carico posto sulla macchina.

NIC

Questa pagina non viene visualizzata quando si creano cataloghi di accesso remoto al PC.

Nella pagina Schede di interfaccia di rete, se si prevede di utilizzare più NIC, associare una rete virtuale a ciascuna scheda. Ad esempio, è possibile assegnare una scheda per accedere a una rete sicura specifica e un’altra scheda per accedere a una rete più comunemente utilizzata. È anche possibile aggiungere o rimuovere NIC da questa pagina.

Account macchina

Questa pagina viene visualizzata solo quando si creano cataloghi di accesso remoto al PC.

Nella pagina Account macchina, specificare gli account macchina di Active Directory o le unità organizzative (OU) da aggiungere che corrispondono a utenti o gruppi di utenti. Non utilizzare una barra (/) in un nome OU.

È possibile scegliere una connessione di gestione dell’alimentazione configurata in precedenza o scegliere di non utilizzare la gestione dell’alimentazione. Se si desidera utilizzare la gestione dell’alimentazione ma non è stata ancora configurata una connessione adatta, è possibile creare tale connessione in seguito e quindi modificare il catalogo di macchine per aggiornare le impostazioni di gestione dell’alimentazione.

Account computer

Questa pagina viene visualizzata solo quando si utilizza MCS per creare VM.

Ogni macchina nel catalogo deve avere un account computer di Active Directory corrispondente. Nella pagina Account computer, indicare se creare account o utilizzare account esistenti e la posizione per tali account.

• Se si creano account, è necessario disporre dell’autorizzazione per creare account computer nell’OU in cui risiedono le macchine.

  Specificare lo schema di denominazione dell’account per la macchina, utilizzando i segni di cancelletto per indicare dove appaiono numeri o lettere sequenziali. Non utilizzare una barra (/) in un nome OU. Un nome non può iniziare con un numero. Ad esempio, uno schema di denominazione di PC-Sales-## (con 0-9 selezionato) produce account computer denominati PC-Sales-01, PC-Sales-02, PC-Sales-03 e così via.

• Se si utilizzano account esistenti, sfogliare gli account o fare clic su Importa e specificare un file .csv contenente i nomi degli account. Il contenuto del file importato deve utilizzare il formato:

[ADComputerAccount]
ADcomputeraccountname.domain
...
<!--NeedCopy-->

Assicurarsi che ci siano abbastanza account per tutte le macchine che si stanno aggiungendo. Studio gestisce questi account, quindi consentire a Studio di reimpostare le password per tutti gli account o specificare la password dell’account, che deve essere la stessa per tutti gli account.

Per i cataloghi contenenti macchine fisiche o macchine esistenti, selezionare o importare account esistenti. Assegnare ogni macchina sia a un account computer di Active Directory che a un account utente.

Per le macchine create con Citrix Provisioning, gli account computer per i dispositivi di destinazione sono gestiti in modo diverso; vedere la documentazione di Citrix Provisioning.

Riepilogo, nome e descrizione

Nella pagina Riepilogo, rivedere le impostazioni specificate. Immettere un nome e una descrizione per il catalogo. Queste informazioni vengono visualizzate in Studio.

Al termine, fare clic su Fine per avviare la creazione del catalogo.

Risoluzione dei problemi

Importante:

Dopo aver creato il catalogo di macchine utilizzando Citrix Studio, non è più possibile utilizzare il comando PowerShell Get-ProvTask per recuperare le attività associate alla creazione del catalogo di macchine. Questa restrizione è il risultato dell’eliminazione di tali attività da parte di Studio dopo la creazione del catalogo di macchine, indipendentemente dal fatto che il catalogo sia stato creato con successo.

Citrix raccomanda di raccogliere i log per aiutare il team di supporto a fornire soluzioni. Quando si utilizza Citrix Provisioning, utilizzare la seguente procedura per generare i file di log:

1. Sull’immagine master, creare la seguente chiave di registro con il valore 1 (come valore DWORD (32 bit)): HKLM\Software\Citrix\MachineIdentityServiceAgent\LOGGING.

2. Spegnere l’immagine master e creare uno snapshot.

3. Sul Delivery Controller, eseguire il seguente comando PowerShell: Set-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown -Value $True.

4. Creare un catalogo basato su quello snapshot.
5. Quando la VM di preparazione viene creata sull’hypervisor, accedere ed estrarre i seguenti file dalla radice di C:\: Image-prep.log e PvsVmAgentLog.txt.
6. Spegnere la macchina, a quel punto segnalerà l’errore.
7. Eseguire il seguente comando PowerShell per riabilitare lo spegnimento automatico delle macchine di preparazione dell’immagine: Remove-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown.

Dove andare dopo

Se questo è il primo catalogo creato, Studio guida l’utente a creare un gruppo di distribuzione.