Desktop fileDistribuzione di Windows in un mondo virtuale

Wes Miller

L'elaborazione virtuale è ovunque. L'incontro con questa tecnologia è solo questione di tempo. La virtualizzazione riduce la dipendenza dall'hardware creando essenzialmente un proprio Hardware Abstraction Layer (HAL) e consentendo di spostare uno o più sistemi guest, come i sistemi operativi client Windows Server o Windows, fra i sistemi host.

La virtualizzazione è, ovviamente, diversa dall'emulazione per il fatto che non imita il processore del guest. Rappresenta semplicemente le risorse del sistema host in modo che i sistemi guest possano accedervi. Di conseguenza, i sistemi host sono generici per i guest. In genere è possibile spostare un guest virtuale da un sistema creato da un OEM a uno creato da un altro OEM, indipendentemente dall'hardware dell'host. È però opportuno prestare attenzione ad alcuni aspetti. Se, ad esempio, si sposta un guest dall'hardware con un processore di un produttore di CPU, come AMD, a un altro, come Intel, è possibile che si verifichino dei problemi (in base alla tecnologia di virtualizzazione utilizzata). Ciò accade perché la tecnologia di elaborazione virtuale si limita a passare le informazioni dall'host al guest e viceversa; non emula una CPU specifica per il guest (come, ad esempio, Microsoft® Virtual PC su un vecchio Macintosh basato su PowerPC).

Tuttavia, la virtualizzazione emula i componenti hardware principali per l'host. Nella maggior parte dei casi, l'emulazione è limitata alla rete, ai dispositivi video (in genere un dispositivo molto limitato, senza una GPU avanzata) e all'archiviazione di massa. Questi coprono l'intera gamma di funzioni presentando al guest uno o più tipi di dispositivi emulati tramite software. Leggendo l'articolo si sarà già notato che l'elenco comprende tutti i dispositivi utilizzati da Windows® PE. Nella virtualizzazione questi sono gli stessi tipi di dispositivi necessari perché Windows funzioni. Inoltre, tutte le tecnologie di virtualizzazione devono emulare un BIOS. Potrebbero emulare anche l'EFI (Extensible Firmware Interface), ma il numero ridotto di sistemi operativi basati su EFI oggi ne limita di molto l'uso. Le emulazioni consentono di avviare i guest virtuali. Il BIOS e ciascuno dei dispositivi emulano un dispositivo reale nel software e presentano tale dispositivo ai guest. Sono di conseguenza necessari gli stessi driver (non sempre forniti da Windows) che vengono utilizzati dal dispositivo reale. Questo è un concetto importante da assimilare.

Alcune tecnologie di virtualizzazione consentono l'interfacciamento anche dei dispositivi USB (o USB 2.0), ma non verranno analizzate in questo articolo. A parte i dispositivi USB che richiedono dei driver (stampanti, NIC wireless USB e così via) o un supporto DirectX® (insoliti nella maggior parte delle tecnologie di virtualizzazione), non è necessario molto altro per iniziare a utilizzarli. È importante ricordare che il supporto per dispositivi USB o di altro tipo non emulati dipende, come è ovvio, dalla tecnologia di virtualizzazione utilizzata. Verificare di conoscere tutte le limitazioni del prodotto di virtualizzazione che si intende adottare prima di tentare di utilizzare i nuovi dispositivi.

Esistono due produttori di primo piano di tecnologie di virtualizzazione in ambiente Windows: Microsoft e VMware (vmware.com). Altri produttori si stanno affermando in questo campo con tecnologie promettenti, come Parallels (parallels.com).

Ora che inizia a essere chiaro l'ambito di utilizzo della virtualizzazione, nel resto dell'articolo si illustrerà come prepararla, come evitare i problemi più comuni e come eseguirne la distribuzione su alcuni computer presenti nell'ambiente.

Distribuzione virtuale

La distribuzione di sistemi virtuali non differisce dalla distribuzione di sistemi fisici ma, come si vedrà, esistono alcune buone ragioni per renderla diversa.

Per le prime versioni di Windows NT®, la distribuzione doveva avvenire tramite installazione. Si potevano creare degli script, ma era comunque necessario eseguire l'intero processo. Al termine dell'installazione, la funzione di copia dell'immagine su altri sistemi, sebbene fosse in teoria utile, semplicemente non era supportata.

In seguito, tuttavia, in Microsoft si decise di supportare i sistemi "clonati" o copiati da disco di Windows NT. Oggi tutti i metodi disponibili per la distribuzione fisica dei sistemi sono disponibili anche per la distribuzione virtuale. È possibile utilizzare: Winnt32 (o setup.exe nel caso di Windows Vista® e Windows Server® 2008); Windows PE (1.x o 2.x, a seconda del client da distribuire, come spiegato nei miei articoli precedenti); Servizi di installazione remota (RIS) o Servizi di distribuzione Windows (WDS); Sysprep (Utilità preparazione sistema per la distribuzione introdotta con Windows NT 4.0) e la tecnologia di duplicazione dischi preferita (ImageX, ad esempio).

L'operazione è necessaria solo la prima volta che si distribuisce un sistema operativo specifico. In seguito è sufficiente eseguire una copia. Esiste tuttavia un problema correlato ai metodi di duplicazione basati su disco come quelli appena menzionati.

Utilizzo di Sysprep

La decisione iniziale di Microsoft di non supportare la duplicazione basata su disco dipendeva in larga parte dal dall'identificatore di protezione (SID) di Windows NT. Per fortuna, Sysprep fornisce una soluzione. È però opportuno analizzare prima il problema da risolvere. Come illustrato all'indirizzo support.microsoft.com/kb/314828, il SID consiste in un numero revisione della struttura SID (di solito un identificatore univoco globale o GUID) che identifica un singolo computer basato su Windows. L''ID viene quindi utilizzato come parte principale dell'identificatore per tutti gli account locali. Gli account locali dispongono di un proprio identificatore univoco, denominato identificatore relativo (RID). Il RID è costituito da un ID di account concatenato in coda al SID. La combinazione dei due diventa l'identificatore per gli account locali.

Perché è un problema utilizzare, ad esempio, il SID del gruppo Administrators S-1-5-21-191058668-193157475-1542849698-500? S-1-5 è il descrittore che definisce che definisce questo codice come SID, la S è onnipresente nella rappresentazione testuale di un SID, mentre 1 e 5 rappresentano rispettivamente il numero revisione e il valore dell'identificatore dell'autorità del SID di Windows NT (in questo caso Protezione di Windows). Il resto è il SID vero e proprio, compreso 500 che identifica un SID ben noto, ovvero l'account del gruppo Administrators di Windows. All'account del gruppo Administrators creato per impostazione predefinita (e impossibile da eliminare) su tutte le installazioni di Windows viene attribuito un SID che termina con 500. Agli account degli utenti locali aggiunti a Windows dopo l'installazione viene attribuito un numero a partire da 1000.

PSGetSID, disponibile da Windows Sysinternals (menzionato nel mio articolo su PSTools consultabile all'indirizzo technetmagazine.com/issues/2007/03/DesktopFiles), consente di enumerare un SID per un determinato utente su un sistema o il SID del sistema. L'output di PSGetSID per il SID del sistema virtuale e dell'account utente di esempio, 1003, è visibile nella Figura 1.

Figura 1** L'output di PSGetSID per il SID di un sistema virtuale e per il SID dell'account utente 1003 **(Fare clic sull'immagine per ingrandirla)

Poiché i RID degli account locali sono basati su questo SID, il problema che si verifica quando si duplica un sistema tramite disco o si copia semplicemente un'immagine di computer virtuale è abbastanza chiaro. Se il SID non viene modificato (funzionalità prevalente ma non unica di Sysprep), si ottiene una copia del principale componente che rende unico un sistema Windows. Se il sistema A e il sistema B hanno un SID del gruppo Administrators identico, gli utenti di entrambi i sistemi verrebbero legittimamente identificati come lo stesso utente. Lo stesso accade per tutti gli account locali del sistema B che si autenticano sul sistema A e viceversa. Ancora peggio, i due sistemi presentano lo stesso SID ad Active Directory®. Se quindi si consente l'autenticazione del sistema A per una risorsa di dominio, ma si impedisce tale autenticazione al sistema B, si verifica un conflitto. Quando si impedisce l'autenticazione del sistema B, l'accesso viene impedito anche al sistema A.

Diventa quindi fondamentale rigenerare i SID sui sistemi utilizzando Sysprep, soprattutto in scenari di sistemi virtuali perché le immagini di sistema si possono propagare molto facilmente. Non è inoltre consigliabile utilizzare uno strumento di modifica del SID di terze parti, ma solo Sysprep. Sysprep è progettato, testato e supportato da Microsoft per la preparazione della duplicazione dei sistemi (anche di sistemi virtuali). Nella Figura 2 è riportato un esempio di schermata di Sysprep prima della modifica del SID di un sistema. Quando si prepara il sistema alla duplicazione, verificare che l'opzione "Don't regenerate security identifiers" sia sempre deselezionata.

Figura 2** L'opzione "Don't regenerate security identifiers" deve essere deselezionata quando si prepara la duplicazione **

Oltre ad aggiornare il SID in un nuovo ID, Sysprep modifica gli eventuali archivi dati privati rilevati in modo che riportino il SID e il nome del computer oppure in modo che la crittografia utilizzata funzioni con il nuovo SID. Alcuni esempi sono l'archivio dati Attività pianificate e i valori nella metabase IIS (se IIS è installato).

Sysprep inoltre elimina forzatamente tutte le schede NIC del sistema, con i dati di configurazione di rete per la scheda NIC. Poiché la configurazione di rete resta priva di NIC nel Registro di sistema e la relazione di tale NIC si basa sull'ID hardware della NIC (relazione che, al di fuori di uno spostamento da virtuale a virtuale, viene spesso interrotta), Sysprep elimina questi dati che in genere venivano abbandonati.

Sysprep elimina inoltre dal sistema tutte le informazioni di appartenenza di Active Directory. Di conseguenza, deve necessariamente rimuovere anche il sistema dal dominio. In tal modo si garantisce che al dominio possano essere aggiunti senza problemi i sistemi a cui sono stati appena attribuiti dei nuovi SID. Alcune utilità di modifica del SID consentono di modificare il SID di un computer senza rimuoverlo dal dominio, ma questo procedimento non è né attendibile né sicuro. Se si deve assolutamente eseguire Sysprep su un computer che è membro di un dominio, è preferibile rimuoverlo dal dominio prima di eseguire Sysprep oppure eseguire Sysprep e lasciare che lo strumento gestisca l'attività.

È inoltre utile notare che, quando si virtualizza un controller di dominio (DC), è necessario duplicare i sistemi che sono semplici server autonomi non promossi a controller di dominio e che non fanno parte del dominio. Fatta eccezione per Windows Server 2003 Small Business Server Edition, non è possibile eseguire una duplicazione sicura dei dischi di un controller di dominio. Per creare nuovi controller di dominio in modo sicuro, è necessario creare un'immagine disco di un server pronto ad essere incluso nel dominio e promosso a controller di dominio. Sysprep (tra l'istanza specifica SBS, che è foresta singola/server singolo) non è in grado di modificare in modo sicuro il SID su un controller di dominio.

Infine, oltre a modificare il SID e rimuovere il computer dal dominio, Sysprep modifica il nome del computer.

Può sembrare scoraggiante dire che è necessario eseguire tutte le attività elencate sopra quando si creano delle immagini (o semplicemente si copiano) dei sistemi virtuali. Ma è fondamentale, soprattutto se si utilizzano questi sistemi su una rete con altri sistemi fisici o virtuali, in un dominio o con qualsiasi altra copia di se stessi sulla rete.

Se non si utilizza Sysprep per la duplicazione di sistemi virtuali, è quasi certo che si verificheranno molti problemi (conflitti in Active Directory o altre connessioni di rete), alcuni dei quali imprevisti. Le immagini virtuali, ad esempio, sono particolarmente soggette ad attacchi dal momento che un attacco ben assestato a un'immagine può consentire di accedere concedere a tutte le altre.

Driver e Hardware Abstraction Layer (HAL)

Si è già menzionata la possibilità che i dispositivi virtuali inclusi in un'immagine virtuale non dispongano dei driver di "posta in arrivo" per Windows. Durante la distribuzione (o la distribuzione delle immagini disco con Sysprep), verificare di avere a portata di mano i driver dei dispositivi, poiché il famigerato errore del driver 0x0000007B può verificarsi con grande facilità quando si sposta un'immagine virtuale da un driver del bus di memorizzazione a un altro, esattamente come accade quando si opera con l'hardware fisico. Lo stesso vale per le schede NIC. Molti dei prodotti di virtualizzazione offrono un dispositivo virtuale piuttosto universale, ma potrebbe essere comunque necessario un driver aggiuntivo.

Nemmeno si possono ignorare i potenziali problemi provocati dall'Hardware Abstraction Layer (HAL). Teoricamente, è preferibile creare dei computer virtuali che supportano i multiprocessori ACPI (Advanced Configuration and Power Interface) (vedere intel.com/technology/iapc/acpi), se la tecnologia di virtualizzazione utilizzata lo consente. La conversione tra HAL non è generalmente supportata (per ulteriori informazioni sulle specifiche, vedere support.microsoft.com/kb/309283). Tuttavia, alcune tecnologie di virtualizzazione (e, ciò che conta di più, molte tecnologie di migrazione) promettono di poter spostare in modo sicuro un'installazione di Windows non ACPI in un'installazione ACPI o viceversa. L'affermazione è falsa e, per iniziare, l'installazione di Windows che ne risulta non è supportata da Microsoft quando e se si verificano dei problemi. Si confermano per i sistemi virtualizzati le stesse limitazioni esposte nella pagina Web di supporto appena citata. L'HAL di uno dei computer virtuali di esempio è illustrato nella Figura 3 (in questo caso in esecuzione utilizzando l'HAL monoprocessore ACPI). L'esempio non deve essere confuso con il processore singolo; questo è intercambiabile con il multiprocessore dello stesso tipo.

Figura 3** HAL di un computer virtuale **(Fare clic sull'immagine per ingrandirla)

Modifiche varie

Modificare gli elementi modificabili e accettare ciò che non si può modificare

Quando si intende eseguire la migrazione da fisico a virtuale o viceversa, è necessario ricordare che è possibile modificare alcuni elementi, mentre altri aspetti non sono modificabili. È possibile modificare tutti i seguenti aspetti di un'installazione Windows:

• HAL (ma solo da multiprocessore a monoprocessore o viceversa, purché siano basati sulla stessa configurazione di alimentazione).
• Controller di archiviazione di massa (non è facile, ma la maggior parte delle soluzioni di migrazione da fisico a virtuale tentano di eseguire questa operazione di propria iniziativa). La maggior parte dei produttori fornisce una soluzione di archiviazione IDE e una SCSI. La scelta durante la distribuzione deve essere oculata, poiché il passaggio da uno all'altro non è molto semplice. In generale, quando si sceglie la soluzione SCSI si ottiene un dispositivo più affidabile (questo è il caso con le implementazioni di emulazione di dispositivi SCSI della maggior parte dei produttori).
• Controller di rete (anche se in uno scenario di migrazione da virtuale a virtuale questo sarà probabilmente identico all'interno delle tecnologie proposte da un singolo produttore).

Non è possibile modificare tutti i seguenti aspetti di un'installazione Windows:

• HAL (tranne che nel caso menzionato prima, quando si utilizza la medesima configurazione di alimentazione). Non è affatto detto che una soluzione di migrazione in grado di garantire questo tipo di modifiche possa garantire un'installazione di Windows stabile o affidabile (un'installazione di questo tipo, inoltre, non è supportata da Microsoft).

Oltre a modificare il SID e il nome del computer, è necessario modificare anche alcuni valori specifici per la tecnologia di elaborazione virtuale che si utilizza. In particolare, si deve modificare l'indirizzo MAC (l'ID univoco per i dispositivi di rete). Molte applicazioni virtuali, inoltre, dispongono di un proprio identificatore univoco. Nella maggior parte dei casi l'identificatore viene memorizzato nei file di configurazione del computer di origine, dunque è necessario avere dimestichezza con la manipolazione di queste voci (garantendone la validità). È opportuno sottolineare che molti prodotti di virtualizzazione che supportano il Pre-Boot Execution Environment (PXE) codificano l'UUID del SMBIOS in base al proprio ID univoco, accentuando la necessità di modificare l'ID (o di lasciare che il software di virtualizzazione esegua la modifica, se possibile) quando si partecipa a un dominio. In caso contrario può risultare impossibile gestire sistemi WDS o RIS (quando si evidenziano conflitti tra GUID). Nella maggior parte delle soluzioni di virtualizzazione provate si possono verificare gravi problemi di rete nel caso di indirizzi MAC duplicati; quindi, se non si intende semplicemente spostare un computer virtuale, è molto importante modificare l'indirizzo MAC se il software di virtualizzazione non esegue già questa operazione.

Gli altri componenti da ricordare durante la preparazione della distribuzione di un sistema virtuale sono gli eventuali dischi collegati o istantanee. In base alla soluzione di virtualizzazione che si utilizza, questi potrebbero essere anche definiti dischi differenziali o con un altro nome. Ma se si esegue Sysprep per preparare un sistema e si dispone di istantanee (o di un altro stato ripristinabile) da includere nel sistema virtuale, queste devono essere distrutte affinché l'immagine resti sicura, affidabile e protetta quando viene duplicata. Nel caso di un'istantanea o di un'altra tecnologia di tipo "annulla le modifiche apportate sul disco", il ripristino di un'istantanea può significare il ritorno a una condizione in cui i sistemi che avevano come origine il computer virtuale precedente ora sono in conflitto con un altro sistema (o addirittura con il sistema di origine, se ripristinato). Dunque sulle eventuali relazioni tra dischi differenziali o istantanee deve essere già stato eseguito Sysprep.

Ottimizzazione

La maggior parte delle tecnologie di virtualizzazione prevede l'aggiunta di strumenti per i computer virtuali che consentono di migliorare le prestazioni e l'interazione con il guest dall'host. In genere, tra i miglioramenti delle prestazioni offerti, si apprezzano l'ottimizzazione dell'input da mouse e da tastiera, oltre a funzionalità migliorate di copia e incolla o di altra interazione tra host e guest. Prima della distribuzione, installare la versione più recente di questi strumenti nei sistemi virtuali.

È inoltre necessario verificare che la memoria del client sia configurata in modo ottimale per il sistema operativo guest, ma anche nel contesto degli host su cui sarà distribuito. È inutile e pericoloso distribuire un'immagine di Windows XP impostata in modo da utilizzare 1 GB di RAM su sistemi host che non dispongono di tanta RAM neanche per eseguire il sistema operativo di origine.

È necessario inoltre ricordare le limitazioni a cui sono sottoposte la maggior parte delle tecnologie virtuali odierne. È importante che gli utenti sappiano come interagire con i dispositivi collegati al sistema virtuale oppure quali applicazioni è possibile o meno utilizzare sul sistema operativo guest (la maggior parte non supporta DirectX 9 o 10, ad esempio, o supportano le versioni meno recenti in modo limitato). Gli utenti potrebbero non conoscere le limitazioni e il modo in cui queste si manifestano (alcune applicazioni non gestiscono neanche questo tipo di errori).

Considerazioni sull'host

In generale non sono molti gli aspetti da considerare relativi al computer host quando si esegue una tecnologia di virtualizzazione, indipendentemente dal fatto che sotto si utilizzi un sistema operativo completo o un hypervisor di tipo 1 eseguito direttamente sull'hardware. La maggior parte delle tecnologie di virtualizzazione sono progettate in modo da garantire che il sistema operativo guest non sia coinvolto per nulla (o solo in minima parte) nelle operazioni dell'host. Tuttavia, quando un guest spostato da un host a un altro provoca dei problemi, verificare quali host sono in uso. Informarsi inoltre sulle limitazioni imposte al prodotto di virtualizzazione su piattaforme specifiche. Può essere possibile passare da uno all'altro, ma nel processo si possono perdere o guadagnare determinate funzionalità dell'hypervisor di tipo 2 del sistema operativo (l'applicazione di virtualizzazione).

Altri meccanismi di distribuzione

Collegamenti correlati a Sysprep

I documenti seguenti sono molto utili per apprendere l'utilizzo di Sysprep:

• Progettazione di installazioni basate su immagini con Sysprep
• Utilizzo dello strumento Sysprep per automatizzare la corretta distribuzione di Windows XP
• Utilizzo dell'Utilità preparazione sistema (Sysprep.exe) per effettuare la duplicazione dei dischi
• Utilizzo dell'Utilità preparazione sistema su computer diversi

L'utilizzo di Sysprep o della duplicazione del disco (o semplicemente l'esecuzione di Sysprep seguita dalla copia della macchina virtuale) è una scelta ovvia per la distribuzione di sistemi virtuali, ma ne esistono altre. Infatti, che si utilizzi l'imaging o l'installazione, l'impiego di Windows PE può risultare più semplice con la virtualizzazione che con i computer fisici, poiché si utilizzano file ISO invece di CD reali. Alcune tecnologie di virtualizzazione, tuttavia, non sono in grado di gestire in modo corretto i supporti DVD, quindi è opportuno rivolgersi al produttore per informazioni in merito. È possibile utilizzare winnt32 o setup.exe (nel caso di Windows Vista o Windows Server 2008), ma non si notano particolari vantaggi. Se si utilizzano altre tecnologie di distribuzione Microsoft, come gli Automated Deployment Services, la tecnologia di virtualizzazione utilizzata supporta PXE per l'avvio di una distribuzione basata sulla rete, come se si utilizzasse RIS o WDS.

Migrazione

Infine, a parte l'effettiva migrazione di un intero computer, ricordarsi non dell'Utilità di migrazione stato utente (USMT). USMT consente di spostare facilmente le impostazioni dell'utente da un client fisico a un nuovo sistema virtuale. Se gli utenti vogliono eseguire la migrazione dei propri vecchi dati e impostazioni verso un nuovo computer virtuale, sarà possibile, ad esempio, recuperare i file e le impostazioni da Windows XP, memorizzarli su un UNC e inviarli al nuovo computer virtuale.

Wes Miller vive ad Austin, nel Texas. In precedenza, ha lavorato per Winternals Software ad Austin e in Microsoft come Program Manager e Product Manager di Windows. È possibile contattarlo all'indirizzo technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.