Archive

Archive for November, 2010

La gestione della memoria in VMware ESX 4.1 – parte 3

28 Nov 2010 1 comment

Nella prima e nella seconda parte di questi articoli, ho analizzato i concetti di base di gestione della memoria e le tecniche “consolidate” di memory reclamation utilizzate da ESX 4.1: il trasparent page sharing, il ballooning e lo swapping.

In questa terza ed ultima parte analizzerò la tecnica della compressione della memoria, nuova arrivata in ESX 4.1. Illustrerò poi  quando entrano in funzione i vari meccanismi e infine indicherò dei riferimenti per ulteriori approfondimenti.

La compressione della memoria

L’idea alla base della compressione della memoria è semplice: se le pagine da swappare possono essere compresse e messe in una cache nella memoria principale, il prossimo accesso alla pagina causerà soltanto una decompressione che può essere un ordine di grandezza più veloce di un accesso al disco. Con la compressione della memoria solo un ridotto numero di pagine non comprimibili ha bisogno di essere swappato se la cache di compressione non è piena, riducendo così il numero di caricamenti in memoria futuri. Così facendo è possibile che le performance delle applicazioni migliorino quando l’host è in ristrettezze di memoria.

In ESX4.1 la compressione della memoria avviene solo per le pagine che dovrebbero essere swappate: se la memoria non è overallocata il meccanismo di compressione della memoria non entra in funzione.

Come funziona

Come appena detto, la compressione della memoria entra in gioco solo quando ESX ha bisogno di recuperare delle pagine tramite swap. Assumiamo che ESX abbia individuato due pagine da 4KB di una vm da recuperare tramite swap. Con la compressione della memoria, ogni pagina candidata viene compressa e memorizzata usando 2 KB di spazio in una zona di memoria dedicata che ogni VM ha (detta compression cache). Dato che non ci sono I/O su disco, la compressione delle pagine è più veloce dello swap. Se il rapporto di compressione fosse minore del 50%, le pagine verrebbero swappate normalmente, in questo modo ogni compressione eseguita con successo recupera 2KB di physical memory.

Quando un accesso successivo nella VM guest memory genera un miss, viene per prima verificata la presenza nella compression cache: se la pagina viene trovata qui, viene decompressa e riportata nella guest memory, eliminandola dalla compression cache. Se non viene trovata nella compression cache, la richiesta va allo swap.

Riassumendo: il meccanismo di compressione della memoria entra in funzione solo quando l’hypervisor avrebbe bisogno di swappare. Basandosi sul fatto che la compressione e l’accesso in ram sono più veloci dell’accesso al disco, l’hypervisor prova a comprimere le pagine e salvarle in una zona dedicata. Se il rapporto di compressione delle pagine supera il 50%, vengono salvate nella zona dedicata, altrimenti vengono swappate.

La compression cache

Lo spazio per la  compression cache (la zona di memoria dedicata che ogni VM ha per il meccanismo di compressione della memoria) viene considerata nell’uso della guest memory delle VM: ESX non alloca ulteriore host physical memory per memorizzare le pagine compresse.

La compression cache è trasparente per il sistema operativo guest, la sua dimensione parte a zero e cresce via via che la memoria della VM viene swappata.

Quando la compression cache è piena, una pagina compressa (scelta tramite un politica basata sull’age-ing) viene decompressa e swappata per fare posto alla nuova pagina.

Se le pagine appartenenti alla compression cache devono essere swappate per colpa di una pesante overallocazione, la dimensione della compression cache viene ridotta  e le pagine “di troppo” vengono decompresse e swappate.

ESX setta in modo conservativo la dimensione massima della ompression cache al 10% della dimensione configurata della VM. La dimensione massima della compression cache è importante per mantenere delle buone performance della VM: se troppo piccola ci sarebbero molte sostituzioni di pagine compresse con conseguente decompressione e swap, se troppo grande può sprecare memoria della VM e creare inutilmente pressione nel caso le pagine compresse non siano più toccate in seguito.

Quando partono i meccanismi di memory reclamation?

Finora ho illustrato le tecniche di memory reclamation utilizzate da ESX 4.1 indicando l’ordine in cui vengono applicate, ossia: transparent page sharing, ballooning, compressione della memoria e swapping. Ho inoltre detto come ESX le usa via via che la memoria libera diminuisce. Ma quando effettivamente ESX decide di utilizzare le varie tecniche?

ESX definisce quattro stati per l’host memory libera: high, soft, hard e low corrispondenti a quattro soglie di memoria libera: 6%, 4%, 2%, 1%.

Di default ESX abilita sempre il trasparent page sharing, in quanto opera in modo opportunistico liberando memoria con poco overhead.

La decisione di abilitare il ballooning o lo swapping (che a sua volta attiva la compressione della memoria) dipende invece in larga parte dallo stato attuale della host memory libera.

In stato high, l’uso aggregato della guest memory delle VM è minore della dimensione della host memory: in questa situazione l’hypervisor non usa ballooning o swapping, indipendentemente dal fatto che la host memory sia overallocata. (A meno di memory limit impostati sulle VM).

In stato soft, l’hypervisor comincia ad utilizzare il ballooning: in particolare il ballooning inizia prima che sia raggiunta la soglia soft per far sì che il driver di ballooning abbia il tempo di allocare e bloccare la memoria e l’hypervisor possa quindi recuperarla anche prima di raggiungere la soglia soft.

Se nemmemo il ballooning è sufficiente e la memoria libera va in stato hard, l’hypervisor comincia ad usare lo swapping e la compressione della memoria. Tramite questi meccanismi l’hypervisor dovrebbe riuscire a recuperare rapidamente la memoria e riportarsi in stato soft.

Nei rari casi in cui si arriva allo stato low, l’hypervisor continua ad usare lo swapping e la compressione della memoria ma in più blocca l’esecuzione di tutte le VM che consumano più memoria del loro target di allocazione.

In alcune situazione la memoria viene recuperata indipendentemente dallo stato, ad esempio nel caso di VM che stanno superando il memory limit imposto. In questi casi viene utilizzato il ballooning e, se necessario, swapping e compressione fino a ridurre l’uso entro il limite imposto.

 

Con questo si conclude questa terza e ultima parte della miniserie dedicata alle tecniche di gestione della memoria di ESX 4.1.

Per chi volesse approfondire ulteriormente l’argomento, ecco alcuni link utili:

[tweetmeme only_single=”false”]
Advertisements

La gestione della memoria in VMware ESX 4.1–parte 2

16 Nov 2010 1 comment

Nella prima parte di questa serie di articoli, ho cominciato a descrivere come viene gestita la memoria in VMware ESX 4.1, soffermandomi sui concetti di base.

In questa seconda parte illustrerò le tecniche “classiche” implementate in ESX 4.1 per recuperare memoria dalle vm (memory reclamation), nella terza parte mi soffermerò sulla memory compression presente per la prima volta in ESX4.1.

Le tecniche per il recupero della memoria in ESX4.1

ESX usa, nell’ordine, quattro tecniche per recuperare memoria dalle VM:

  • Transparent page sharing (TPS, condivisione trasparente delle pagine di memoria): recupero della memoria tramite la rimozione delle pagine di memoria ridondanti che hanno contenuto identico;
  • Ballooning: recupero della memoria tramite un aumento indotto artificialmente dell’uso della memoria interno al sistema operativo guest
  • Memory compression (compressione della memoria): recupero della memoria tramite compressione delle pagine che dovrebbero essere swappate;
  • Hypervisor swapping (swap a livello di hypervisor): swap della memoria delle VM fatto direttamente dall’hypervisor.

Perché delle tecniche di recupero della memoria?

Se ripensiamo alla equazione che indica l’uso della memoria dell’host da parte di una VM:

uso dell’host memory <= dimensione della guest physical memory + overhead

se l’hypervisor non potesse recuperare della memoria fisica dell’host (host physical memory) quando una vm la dealloca, dovrebbe riservare abbastanza host physical memory da poter allocare tutta la guest physical memory di tutte le VM (più gli overhead) per impedire che una qualunque VM esaurisca la memoria fisica. Di fatto questo impedirebbe la possibilità di fare overallocazione della memoria.

Il concetto di overallocazione della memoria è semplice: la memoria dell’host è overallocata quando la somma delle guest physical memory delle VM in esecuzione è maggiore della host physical memory.

ESX supporta da sempre l’overallocazione della memoria, questo per via di due importanti benefici che ne derivano:

  • Maggior utilizzo della memoria: grazie all’overallocazione della memoria si ottiene che la memoria dell’host sia utilizzata il più possibile dalla active guest memory. Spesso ci sono VM meno cariche rispetto alle altre, nelle quali la memoria è inutilizzata per lunghi periodi. Grazie all’overallocazione della memoria e alle tecniche di recupero, l’hypervisor può recuperare questa memoria inattiva e darla ad altre VM a cui serve.
  • Maggior fattore di consolidamento: con l’overallocazione della memoria ogni VM ha un uso minore della host memory, rendendo quindi possibile avere più VM sull host mantenendo comunque buone prestazioni.

Per poter però supportare in modo efficiente l’overallocazione della memoria, l’hypervisor deve avere delle tecniche efficienti di recupero della memoria. Passiamole ora in rassegna una ad una.

Transparent page sharing (TPS)

La tecnica del transparent page sharing si basa sulla considerazione che quando ci sono in esecuzione più VM, è probabile che alcune di esse abbiano identiche porzioni di memoria: ad esempio più VM possono avere lo stesso sistema operativo o avere le stesse applicazioni o contenere gli stessi dati utente. Questa considerazione apre l’opportunità di condividere le parti di memoria in comune, sia tra VM che all’interno della stessa VM, recuperando le copie ridondanti e conservando una sola copia condivisa nella host physical memory. Così facendo si riduce il consumo totale della host physical memory da parte delle VM aumentando il livello di overallocazione della memoria.

ESX identifica le pagine di memoria ridondanti in base al loro contenuto: pagine con contenuto identico vengono condivise indipendentemente da come, dove e quando il contenuto è stato generato. Per identificarle, ESX controlla  periodicamente  il contenuto della guest physical memory alla ricerca di possibilità di sharing. Per maggior efficienza, ESX non confronta byte per byte le pagine, ma usa degli hash.

Vediamo l’algoritmo nel dettaglio:

  • basandosi su un una cadenza di scansione, ESX esamina in modo casuale le pagine della guest physical memory;
  • individuata una pagina candidata ad essere condivisa, viene generato un hash basato sul suo contenuto;
  • l’hash viene usato come chiave per cercare una corrispondenza nella tabella globale degli hash (tale tabella contiene l’elenco delle corrispondenze tra hash e pagine fisiche condivise);
  • se l’hash corrisponde a uno degli hash della tabella, viene fatto un confronto completo del contenuto (per evitare false corrispondenze);
  • se anche il confronto completo da’ esito positivo, il mapping tra guest physical e host physical viene modificato, mappando la pagina della guest physical sulla pagina condivisa della host physical e recuperando la pagina, ora ridondante, dalla host memory.

La rimappatura della pagina è completamente invisibile alla VM e inaccessibile al sistema operativo guest.

Nella figura successiva riassumo l’algoritmo:

image

Nel momento in cui avviene una scrittura su una pagina condivisa, viene usata la tecnica del copy-on-write:

  • un tentativo di scrittura su una pagina condivisa genera un page fault minore;
  • il gestore dei page fault dell’hypervisor intercetta il page fault e crea in modo trasparente una nuova copia privata della pagina;
  • l’hypervisor mappa la pagina della guest physical in questione sulla nuova copia privata;
  • la VM può (finalmente) scrivere sulla pagina, che ora diventa una “normale” pagina di memoria in physical guest memory.

Il meccanismo di Transparent Page Sharing avviene in modo trasparente e continuativo anche in situazione di memoria non overallocata.

Un comportamento leggermente differente si ha nel caso il sistema abbia il supporto hardware alla virtualizzazione della memoria (come l’EPT di Intel o l’RVI di AMD): in questo caso ESX abilita automaticamente l’uso di pagine “larghe” (pagine da 2 MB al posto delle pagine normali da 4 KB) in host physical memory come “supporto” per le pagine di memoria di guest physical, questo viene fatto per avere performance migliori. Le pagine “larghe” però non vengono condivise. Nonostante questo ESX genera comunque gli hash per le pagine da 4 KB interne alle pagine da 2MB: ESX, durante l’host swap, non swappa pagine larghe, ma le spezza in pagine normali; l’hash pregenerato di queste pagine viene usato per condividerle prima di swapparle.

Riassumendo: ESX cerca costantemente la possibilità di condividere pagine identiche tra più VM, nel caso ne trovi sostituisce tutte le pagine con una unica, fa puntare tutte a questa e libera la memoria occupata dalle copie; non appena una VM tenta di scrivere su una pagina condivisa, viene creata una copia di questa pagina per la VM in questione.

Ballooning

Il ballooning è una tecnica completamente differente rispetto al transparent page sharing. Tramite il ballooning si rende il sistema operativo guest “consapevole” dello stato di ristrettezze di memoria dell’host: il sistema operativo guest non sa di essere virtualizzato e non e’ a conoscenza dello stato delle altre VM sullo stesso host, quindi non libererebbe memoria quando lo stato complessivo della memoria libera dell’host diventa troppo basso senza un meccanismo come il ballooning.

In ESX, tramite i VMware Tools, viene installato uno pseudo-device driver detto driver di balloon. Questo driver non ha interfacce di comunicazione esterne verso il sistema operativo guest ma comunica con l’hypervisor tramite un canale privato.

Vediamo come funziona il ballooning:

  • il balloon driver contatta a intervalli regolari l’hypervisor per ottenere la dimensione del  balloon;
  • se l’hypervisor ha bisogno di memoria, setta una dimensione per il driver di balloon, facendolo “gonfiare” allocando memoria guest physical all’interno della VM.
  • il driver di balloon alloca la memoria richiesta “bloccandola” (settandola in modo che non venga swappata su disco) tramite i meccanismi del sistema operativo guest;
  • una volta allocata comunica all’hypervisor quali pagine ha allocato cosi’ l’hypervisor possa recuperarle;
  • quando l’hypervisor decide di “sgonfiare” il driver di balloon, settando una dimensione minore, il balloon driver dealloca le pagine che si era riservato.

Tipicamente l’hypervisor gonfia il driver di balloon quando ha problemi di memoria: gonfiando il balloon, una VM consuma meno host physical memory ma piu’ guest physical memory. In pratica l’hypervisor diminuisce la sua pressione di memoria a scapito della pressione di memoria della VM. Il sistema operativo guest, in risposta a questo aumento di richiesta di memoria, attiva i suoi meccanismi e decide come liberare della memoria, eventualmente paginandola su disco.

Il ballooning ha alcuni problemi:

  • necessita l’installazione del balloon driver (contenuto nei VMware Tools, che comunque è buona prassi installare sempre);
  • il sistema operativo guest deve avere abbastanza spazio su disco per il suo swap file;
  • il ballooning può non liberare memoria abbastanza velocemente  da soddisfare le richieste;
  • è possibile che il limite massimo di memoria liberabile dal balloon sia limitato da limiti del sistema operativo guest.

Riassumendo: il ballooning recupera memoria “gonfiando” e “sgonfiando” un “palloncino di memoria” all’interno del sistema operativo guest, così che sia quest’ultimo a dover recuperare la sua memoria. Detto in altro modo: dato che l’hypervisor non può sapere che memoria è in uso o meno da parte della VM, fa si che sia chi ne è a conoscenza (il sistema operativo guest) ad occuparsi di liberarla.

Hypervisor swapping

Quando il ballooning e il transparent page sharing non sono sufficienti a recuperare la memoria, ESX utilizza direttamente lo swap. Alla partenza delle VM, l’hypervisor crea un file di swap per ognuna di esse. In seguito, se necessario, l’hypervisor può swappare la memoria guest physical nel file di swap, recuperando cosi’ della memoria host physical per le altre VM.

Questa tecnica, a differenza del transparent page sharing e del ballooning, è un modo garantito per recuperare memoria in un certo lasso di tempo, ma viene usato come ultima risorsa in quanto le sue performance soffrono di alcune limitazioni:

  • Problemi di selezione della pagine: in alcune situazioni lo swapping può penalizzare pesantemente le prestazione della vm: l’hypervisor non ha conoscenza di quali pagine siano da swappare e quali no (a livello di sistema operativo guest) e può quindi inficiare le politiche di gestione della memoria del sistema operativo guest;
  • Problema di doppia paginazione: è possibile che sia il sistema operativo guest che l’hypervisor siano in scarsità di memoria e quindi è possibile che entrambi swappino delle pagine con i loro rispettivi meccanismi, di fatto creando una situazione in cui una pagina precedentemente swappata dall’hypervisor, venga riportata in memoria  dallo swap dell’hypervisor per essere immediatamente swappata dal sistema operativo guest nel suo file di swap;
  • Alta latenza di swap-in: quando una pagina viene riportata in memoria dallo swap dell’hypervisor, la VM resta bloccata fino al completo caricamento dal disco. Questo introduce latenze, anche di decine di millisecondi, che possono degradare pesantemente le performance della VM.

Per mitigare l’impatto dell’interazione del meccanismo di swapping con i meccanismi di gestione della memoria del sistema operativo guest, ESX sceglie in modo casuale le pagine di memoria guest physical da swappare.

Riassumendo: l’uso dello swap da parte dell’hypervisor è “l’ultima spiaggia” in caso di necessità di recupero di memoria, è il meccanismo che penalizza di più le performance delle VM sia perché’ il disco è più lento della memoria, sia perché può interagire in modo negativo con i meccanismi di gestione della memoria dei sistemi operativi guest delle VM.

 

Con questo concludo la seconda parte di questa miniserie dedicata alle tecniche di gestione  della memoria di ESX 4.1. Nella terza parte illustrerò il nuovo meccanismo di compressione della memoria presente a partire da ESX 4.1

[tweetmeme only_single=”false”]

First round of patches for vSphere 4.1

16 Nov 2010 Leave a comment

Today has been released the first round of patches for vSphere 4.1.

As usual  there are a bunch of patch for ESX that fixes security problems in the ESX console.

There are also some critical patches that I think is useful to review:

 

Categories: vmware, vsphere Tags:

thanks vmguru!

Just a short post to publicly thanks Arjan van’t Hoff from vmguru blog and his giveaway: I’m the lucky winner of the Original VMware World Lab Staff Shirt and I’m really happy about that: it’s like Santa Clause came here a couple of month earlier!

 Thank you Arjan and keep blogging!

Categories: Uncategorized

La gestione della memoria in VMware ESX 4.1 – parte 1

8 Nov 2010 1 comment

Note to english speaking readers: in this post I explain some memory management concepts of ESX 4.1. I think that there are a lot of good post and white paper about this topic in english, but I think that for non english speaking people it’s not simple follow these sources. This is the main reason about this post and the reason because of it is only in italian.

Con l’uscita di ESX 4.1 sono state introdotte varie novità (di cui ormai tutti sono a conoscenza) a livello di gestione delle risorse fondamentali: CPU, memoria, disco e networking.

Insieme a queste novità, VMware ha pubblicato una serie di white paper che non solo illustrano le nuove funzionalità, ma anche spiegano come il vmkernel gestisce le risorse.

Dato che questi white paper non sono sempre di agevole lettura, ho deciso di iniziare una serie di post in italiano in cui illustrare i punti fondamentali toccati nei documenti originali, a cui rimando per approfondimenti: in particolare, nei documenti originali vengono riportati nel dettaglio i test relativi alle performance, mentre in questa serie di post verranno solo citati.

Nota: in questo post toccherò inevitabilmente concetti di sistemi operativi, senza aver la pretesa di essere esaustivo. In coda al post indicherò alcune risorse e alcuni testi su cui approfondire i vari argomenti.

Parto quindi con la prima risorsa: la memoria.

Nei casi reali, la memoria è la prima risorsa che diventa scarsa: chiunque abbia un ambiente virtualizzato, anche piccolo, avrà notato come, a parte applicazioni particolari, la cpu non è mai un collo di bottiglia, mentre la memoria viene consumata molto più in fretta e si arriva velocemente a saturare l’host.

Bisogna inoltre ricordarsi che, data la presenza dell’hypervisor, i normali meccanismi di gestione della memoria dei sistemi operativi guest si sommano ai meccanismi di gestione della memoria dell’hypervisor, per cui diventa più complesso avere una visione globale di quello che succede.

E’ quindi importante conoscere come ESX gestisce la memoria così da poter prendere decisioni corrette nel momento in cui si presentano problemi di performance.

ESX calcola un target di allocazione di memoria per ogni vm basandosi sul carico corrente del sistema e sui setting di share, reservation e limit impostati. Questo target viene poi utilizzato come guida per l’allocazione dinamica della memoria di ogni vm, eventualmente invocando vari meccanismi di basso livello per reclamare memoria da altre vm in caso di overallocazione della memoria dell’host.

E’ possibile monitorare facilmente l’uso della memoria dell’host e della vm tramite due statistiche: Consumed Memory e Active Memory che monitorano rispettivamente quanta memoria dell’host è allocata alla vm e quanta memoria della vm è attualmente in uso da parte del sistema operativo e delle applicazioni.

Un po’ di terminologia

Ritengo utile elencare e spiegare la terminologia utilizzata in questo ambito, terminologia che si ritrova anche nei vari documenti ufficiali di VMware. Nel seguito utilizzerò ovunque possibile la terminologia inglese per uniformità con il resto della documentazione reperibile in rete.

  • Host physical memory (memoria fisica dell’host): con questo termine ci si riferisce alla memoria presente nell’host fisico e che l’hypervisor vede come disponibile per il sistema.
  • Guest physical memory (memoria fisica del guest): con questo termine ci si riferisce alla memoria visibile al sistema operativo guest in esecuzione nella vm. Generalmente corrisponde alla memoria configurata sulla vm.
  • Guest virtual memory (memoria virtuale del guest): con questo termine ci si riferisce allo spazio di indirizzamento presentato dal sistema operativo guest alle sue applicazioni. E’ esattamente il concetto di memoria virtuale dei sistemi operativi.

L’hypervisor fornisce un meccanismo per mappare la guest physical memory sulla host physical memory.

Esistono poi due livelli di paginazione, uno a livello di sistema operativo guest e uno a livello di hypervisor:

  • guest level paging (paginazione a livello di sistema operativo guest): è il trasferimento di memoria (per essere precisi, di pagine di memoria) tra la guest physical memory e lo swap del sistema operativo guest. E’ esattamente il normale meccanismo di paging dei sistemi operativi ed è pilotato dal sistema operativo guest.
  • hypervisor swapping: è il trasferimento di memoria tra la guest physical memory e lo swap dell’host. E’ pilotato dall’hypervisor.

I concetti base della memoria virtuale

La tecnica della memoria virtuale è comunemente utilizzata nei sistemi operativi ed è supportata in hardware dalla quasi totalità delle moderne cpu. Tale tecnica crea uno spazio di indirizzamento virtuale per le applicazioni e demanda al sistema operativo e all’hardware la traduzione degli indirizzi dallo spazio di indirizzamento virtuale allo spazio di indirizzamento fisico. In questo modo le applicazioni non si devono occupare della memoria fisica effettivamente presente sul sistema e il sistema operativo può supportare funzionalità di protezione dei processi, file mapping e così via in modo trasparente per le applicazioni.

Quando l’hypervisor esegue una vm, crea uno spazio di indirizzamento contiguo per la vm che ha le stesse caratteristiche dello spazio di indirizzamento contiguo presentato dal sistema operativo guest alle sue applicazioni. Quindi, dal punto di vista delle applicazioni in esecuzione nella vm, l’hypervisor aggiunge un livello in più di traduzione degli indirizzi, creando di fatto i tre livelli di memoria citati in precedenza: guest virtual memory, guest physical memory e host physical memory.

image

La traduzione degli indirizzi tra guest physical memory e host physical memory è gestita dall’hypervisor: l’hypervisor intercetta tutte le istruzioni della vm che manipolano il translation lookaside buffer (TLB) hardware e il mapping tra indirizzo virtuale (guest)  e indirizzo fisico (guest). Nel TLB viene inserito l’effettivo mapping tra guest virtual memory e host physical memory, mentre le altre mappature sono mantenute dall’hypervisor tramite due strutture dati chiamate pmap e Shadow Tables : questo approccio elimina l’overhead della virtualizzazione durante il normale accesso alla memoria della vm, in quanto trova nel TLB direttamente l’indirizzo della host physical memory.

Mantenere allineate le mappature tra guest virtual memory e guest physical memory e tra guest physical memory e host physical memory introduce però dell’overhead. Per eliminare questo overhead, nelle nuove generazioni di cpu Intel e AMD è stato introdotto un supporto hardware dedicato, tramite l’uso di due layer di tabelle di pagine direttamente in hardware, una per la traduzione di indirizzi tra guest virtual e guest physical e l’altra per la traduzione tra guest physical e host physical.

I concetti base della gestione della memoria in ESX

Per capire come ESX gestisce la memoria è necessario sapere come i vari componenti (applicazione, sistema operativo guest, virtual machine e hypervisor) gestiscono la memoria ai loro livelli.

  • Le applicazioni usano le interfacce fornite dal sistema operativo per allocare e deallocare esplicitamente la memoria virtuale quando partono.
  • Il sistema operativo presuppone di possedere tutta la memoria del sistema:  l’hardware non espone interfacce verso il sistema operativo per permettergli di allocare o liberare esplicitamente la memoria fisica. Il sistema operativo quindi definisce i concetti di memoria fisica allocata o libera e ogni sistema operativo può avere una sua differente implementazione di questa astrazione. Una implementazione comune e’ mantenere una lista di pagine di memoria libere e una di pagine di memoria allocate.
  • Una virtual machine combina i metodi di gestione della memoria delle applicazioni e dei sistemi operativi: come un’applicazione non ha memoria preallocata quando parte, come un sistema operativo non puo’ allocare in modo esplicito della memoria fisica.
  • L’hypervisor definisce i concetti di memoria fisica allocata o libera, intercetta gli accessi alla memoria della virtual machine e alloca la memoria fisica per la vm al suo primo accesso alla memoria.
  • La vm dealloca la memoria come un sistema operativo, per cui solo il sistema operativo guest sa che la memoria liberata è libera, ma la pagina di memoria dell’host fisico non viene toccata.

L’hypervisor può quindi allocare facilmente memoria fisica per una vm catturando i page fault che vengono generati al primo accesso a della memoria mai usata prima da parte della vm. Ci sono invece molte difficoltà nel sapere quando liberare la memoria in quanto è il sistema operativo guest che sa quale memoria è libera e la lista delle pagine libere non è facilmente rintracciabile e monitorabile dall’hypervisor.

Anche se l’hypervisor non può recuperare della host memory quando il sistema operativo libera della guest memory, questo non implica che l’host memory venga usata completamente da una vm che allochi e liberi della memoria. L’hypervisor alloca memoria alla vm solo quando questa tocca della memoria fisica che non ha mai usato in precedenza: per il principio di localita’ la vm molto probabilmente allocherà e libererà sempre le stesse locazioni di guest physical memory e quindi, una volta allocata della host memory al primo utilizzo verrà riutilizzata la stessa. Quindi, anche in caso la vm usi tutta la guest physical memory, questa sarà allocata in altrettanta host physical memory.

Tenendo conto dell’overhead di memoria necessario all’hypervisor per mantenere le sue strutture dati legate alla vm, vale sempre per ogni vm la relazione:

uso dell’host memory <= dimensione della guest physical memory + overhead

Con questo concludo la prima parte di questo articolo, nella prossima parte indagherò le tecniche usate da ESX, e in particolare da ESX 4.1, per recuperare memoria dalle vm.

A VMware “Student Archive”

5 Nov 2010 2 comments

A couple of days ago I’ve read a post on Jason Boche blog about a documentation and utility library which contains a whole lot of VMware resources maintained by William Griffith.

The contents of the library is really well indexed throughout various folders and it’s easy to find what you need.

You can read all the details in the original post: http://www.boche.net/blog/index.php/2010/11/02/vmware-student-archive/

As I’ve seen that the original copy and the mirror by Jason are experiencing some trouble due the bandwidth requested (the library is about 300MB), I’ve uploaded the archive on rapidshare.

So you can also use this link: http://rapidshare.com/files/428830885/2010.11.04_VMware.Student_Archive.zip

I know that rapidshare is not the most handy way, but I’ve not found another free service without bandwidth or max size issues.

Categories: vmware