Una delle principali seccature per gli amministratori di sistema è l'intensa attività di test e abilitazione che occorre eseguire quando si introduce una nuova versione di un sistema operativo di base. I vantaggi offerti dal nuovo software potrebbero essere di scarsa importanza per la maggior parte delle applicazioni, ma potrebbero essere indispensabili per una determinata applicazione o per una nuova configurazione hardware.

La virtualizzazione fornisce una soluzione a questo grande problema. Lo stack esistente può continuare a essere eseguito così com'è, ossia come sistema guest all'interno di una macchina virtuale, mentre l'hypervisor più recente supporta senza difficoltà il nuovo hardware, garantendo significativi vantaggi in termini di affidabilità e di prestazioni. Le poche applicazioni che richiedono la nuova versione del sistema operativo possono essere eseguite su un'altra macchina virtuale con l'ultima versione.

Ne consegue che gli upgrade vengono eseguiti solo quando gli amministratori di sistema li richiedono. In questo modo non saranno mai più obbligati a eseguire un upgrade software costoso e non pianificato.

• Guarda il video: Avoiding Rushed Upgrades

Sebbene sia possibile bloccare totalmente l'accesso a un sistema utilizzato unicamente per un'applicazione, oggigiorno molti sistemi presentano un accesso condiviso ed è importante garantire la riservatezza dei dati.

La virtualizzazione consente di collocare ciascuna applicazione e ciascun set di dati su macchine virtuali distinte. Questo approccio fornisce molti dei vantaggi che si ottengono quando si blocca l'accesso ai singoli sistemi fisici, ma senza incrementare il numero dei componenti hardware. Dal momento che la virtualizzazione isola ogni singolo sistema guest, i singoli sistemi guest sono molto meno esposti alla condivisione indesiderata. Ogni attacco condotto con successo interesserà unicamente il sistema guest violato. Grazie anche all'azione di SELinux e alla gestione delle identità Red Hat, è possibile raggiungere un elevato livello di isolamento degli utenti e dei dati senza utilizzare server distinti per ciascun utente.

Lo sviluppo software richiede un lungo ciclo e le attività di scrittura del codice, debug e test vengono ripetute molte volte. In passato, le attività di debug e di test spesso richiedevano l'uso di più sistemi diversi: non è stato semplice realizzare grandi reti e set di dati necessari per le attività di test. Anche in questo caso, la virtualizzazione fornisce numerose soluzioni.

È possibile assegnare a ciascuno degli sviluppatori una macchina virtuale che potrà essere avviata e arrestata senza interferire con le macchine degli altri sviluppatori. In tal modo, gli sviluppatori non hanno più bisogno di macchine fisiche individuali. Questo approccio consente una più efficace attività di debug del codice, compreso il codice del kernel.

Dal momento che le macchine virtuali possono essere avviate, arrestate e modificate in maniera rapida e semplice, è possibile automatizzare un numero notevole di test di regressione. Gli script possono fornire differenti versioni di applicazioni e di sistemi operativi, eseguire su di essi set di dati noti, tenere traccia dei risultati e notificarli. Se un sistema si blocca, lo script è in grado di rilevare che il problema riguarda unicamente quel particolare sistema guest, e non la base DOM 0.

Quando occorre utilizzare gruppi voluminosi di sistemi, è possibile attivare più sistemi guest in rete che simulino una rete fisica di grandi dimensioni con un numero piccolo di server fisici. In tal modo, è possibile condurre test di scalabilità, raramente eseguiti oggigiorno. Di fatto, durante le ore non lavorative, è possibile utilizzare anche i cicli extra delle macchine di produzione inutilizzate per condurre attività di test in modo sicuro grazie alle funzionalità di protezione e firewall di ciascun sistema guest.

La migrazione live consente la migrazione di sistemi guest paravirtualizzati su Red Hat Enterprise Linux Versione 5 da un server fisico a un altro server fisico presente nella rete. Quando il sistema guest riceve (da un programma o da un amministratore di sistema che utilizza gli strumenti di gestione Red Hat enterprise Linux standard) il comando di spostare l'hypervisor del sistema "di origine", utilizza l'hypervisor del sistema "di destinazione" per preparare la quantità di memoria sufficiente a contenere il sistema guest che effettua la migrazione. La memoria viene quindi copiata in rete fino a quando non resta la sola memoria attiva. Dal momento che il sistema guest della macchina "di origine" è ancora in esecuzione e sta fornendo servizi ai sistemi guest, per memoria attiva si intende appunto la memoria ancora in uso. Successivamente, l'hypervisor della macchina "di origine" sospende temporaneamente il sistema guest e copia la restante memoria attiva. Dopo di che, l'hypervisor della macchina "di destinazione" mette il sistema guest in esecuzione. Poiché tutte le connessioni di rete e I/O vengono mantenute nella memoria copiata, tutte queste connessioni sono persistenti e quindi, con solo una breve pausa (< 200 ms), il processo continua a fornire servizi ai clienti. Per la persistenza del socket di rete, è necessario che i sistemi si trovino sulla stessa subnet, mentre per la persistenza dei file aperti i sistemi devono avere uno storage comune. Non occorre necessariamente un lock manager; iSCSI, GNDB o un qualsiasi SAN andranno benissimo.

Sono molti i motivi per i quali si esegue una migrazione live.

1. Un sistema guest registra un utilizzo così inteso che si decide di migrarlo su una nuova macchina oppure di migrare gli altri sistemi guest che si trovano sulla stessa macchina per offrire al sistema guest occupato più risorse.
2. Un sistema comincia a ricevere avvisi di errori software in memoria, messaggi che segnalano un aumento della temperatura o altre indicazioni di un errore imminente. I sistemi guest possono essere migrati prima dell'arresto in modo da disimpegnare il server per la manutenzione.
3. Per preparare un imponente flusso di batch, come avviene spesso in alcuni sistemi ERP o nelle elaborazioni finanziarie, è possibile migrare i sistemi guest da un server per aumentarne la capacità. Analogamente, è possibile consolidare i sistemi guest in un numero esiguo di macchine in modo da portare offline la capacità in eccesso per risparmiare energia.

• Guarda il video: Fixing Servers Conveniently

Un buon motivo per creare un numero elevato di sistemi guest ed eseguire poche funzioni per ciascun sistema guest è quello di ridurre al minimo l'effetto domino di un errore. Spesso, se un processo su un sistema SMP di grandi dimensioni si arresta in modo anomalo, è probabile che ogni singolo hub presente su quel sistema si arresti in modo anomalo o si blocchi. Con la virtualizzazione Red Hat, è possibile inserire ciascuna funzione in un proprio sistema guest. In questo modo, un eventuale guasto o problema alla sicurezza non si propaga sugli altri sistemi, ma si limita al solo sistema host su cui si verifica. Attraverso un uso intelligente della migrazione e un software cluster HA (High Availibility), è facile avere istanze di backup pronte per essere eseguite su altre macchine in caso di problemi con un sistema guest o un carico di lavoro.