Architettura Oracle VM

Questo documento riporta i principali aspetti dell'architettura di Oracle VM (OVM): l'ambiente di virtualizzazione basato su Xen fornito dalla Oracle Corporation.

La visione di questo documento e' consigliata ad un pubblico competente o agli utenti accompagnati dai propri sistemisti...
Un documento introduttivo su OVM e' disponibile su questo link.

La versione utilizzata nella descrizione e' la 3.2 [NdE rilasciata 1Q 2013], ma i concetti generali valgono per tutte le release di OVM.

Questo documento e' organizzato nei seguenti capitoli: Architettura, OVM Manager, OVM Server, Repository, Paravirtualizzazione e virtualizzazione HW, Networking, VM, CLI, Alta affidabilita', Hardware Partitioning, Monitoraggio, Sicurezza, Enterprise Manager, Varie ed eventuali, ...

Architettura

L'architettura di OVM e' basata su Xen a cui sono stati aggiunti Agent installati su ogni Dom0 degli Hypervisor ed un Manager su un sistema Linux dedicato.
Una configurazione tipica di OVM comprende un Oracle VM Manager e diversi Oracle VM Server:

Gli OVM Server sono organizzati in Server Pool e fanno uso di risorse comuni come lo storage repository ed il networking configurati graficamente dalla console. Sempre da console vengono definite e gestite le VM (Virtual Machine). Le risorse, i servizi e le VM possono essere scambiati solo tra server appartenenti allo stesso pool.

Dalla versione 3.2 e' disponibile un Agent su Solaris per piattaforma SPARC.

La figura seguente riporta i componenti principali dell'architettura:

OVM - Architettura

OVM Manager

L'Oracle VM Manager e' il server che ospita il software per la gestione di tutta la Farm.

Oracle VM Manager e' installato su un sistema Linux (eg. Oracle Linux, Red Hat) e puo' essere ospitato su una macchina fisica o virtuale.

La configurazione di partenza e' quella di un "normale" sistema operativo Linux su cui viene installato il software OVM (basta montare il CD con il SW, lanciare il comando createOracle.sh ed infine eseguire il "solito" runInstaller.sh). E' consigliato definire FS separati con 6GB per /u01 ed un /tmp di ampie dimensioni. Il software viene installato nella directory /u01/app/oracle/ovm-manager-3.

Con l'installazione Simple il repository, contenente tutte le informazioni sulla Farm gestiata da OVM, e' mantenuto sullo schema OVS di una base dati MySQL 5.5 attiva sulla porta 49500. Con un'installazione Custom e' possibile indicare il tipo di base dati (Oracle o MySQL) ed i riferimenti dell'istanza esterna da utilizzare.
La base dati e' composta da oltre cento tabelle (eg. Mgr_Serve) perfettamente... illeggibili! Infatti tutti i dati sono in formato longblob.

Sull'OVM Manager viene installato un server WebLogic (/u01/app/oracle/ovm-manager-3/machine1/base_adf_domain). WebLogic ospita le applicazioni di gestione: la console in ascolto sulla porta 7002 con il protocollo HTTPS ed il servizio CLI sulla porta 10000 con il protocollo SSH.

L'applicazione di gestione della console di OVM e' raggiungibile all'indirizzo:
http://ovm-manager.xenialab.it:7002/ovm/console


OVM - Console

OVM Server

Gli OVM Server sono i server che ospitano le macchine virtuali. L'architettura di ogni OVM Server e' quella classica di Xen (da non confondere con Zen di cui ho scritto una completa descrizione) con un Hypervisor, un dominio Dom0 per la gestione ed i domini utente DomU con i sistemi operativi ospite. Xen e' un hypervisor di tipo 1 (ovvero si installa direttamente sul sistema fisico e non richiede un sistema operativo sottostante). La gestione dello scheduling dei processori e della memoria e' svolta dall'Hypervisor mentre il dominio Dom0 si occupa della gestione dei device driver per gestire l'HW. Come per tutti gli Xen il processo principale di Dom0 e' il demone Xend lanciato da uno script scritto in Python.

Con OVM Dom0 e' un Oracle Unbreakable Linux 5.7 con Xen 4.1.3 ed un agent Oracle che colloquia con l'OVM Manager. Nella configurazione standard il partizionamento e':

Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 7134992 884352 5882352 14% / /dev/sda3 5080828 191556 4627012 4% /var /dev/sdh1 101086 38660 57207 41% /boot tmpfs 1032928 0 1032928 0% /dev/shm none 1032928 120 1032808 1% /var/lib/xenstored

Oltre ai file system indicati vengono montati sugli OVM Server i file system dei Repository che vengono gestiti con un cluster OCFS2.

Su ogni OVM Server e' installato ed e' sempre attivo un Oracle VM Agent su Dom0. Anche i processi necessari al funzionamento dell'Agent vengono lanciati con script Python. Il primo OVM Server installato diventa anche il Server Pool Master (SPM). Tutti gli Oracle VM Agent comunicano con l'SPM e questo a sua volta comunica con l'OVM Manager. Le attivita' in un pool (eg. la migrazione di una VM tra due OVM Server) vengono coordinate dall'SPM e non richiedono l'intervento del Manager.

Repository

La gestione dello storage e' fondamentale in un abiente virtualizzato. Lo spazio su disco non e' solo necessario per mantenere i dati ma anche le immagini delle VM, i CD per l'installazione del software, i template con le VM preconfigurate, ...
OVM gestisce l'accesso concorrente allo storage con un cluster OCFS2 ed utilizza un'organizzazione ben precisa: il Repository.

Tutti i repository definiti vengono montati sotto la directory /OVS/Repositories/ ed utilizzano la stessa struttura:

. |-0005fb02000300003a393034f2966969 (ID repository) |---Assemblies |---ISOs |---Templates |---VirtualDisks |---VirtualMachines

Il contenuto di ciascuna directory dovrebbe essere chiaro!

Per chi e' abituato a Xen vi sono alcune differenze con vantaggi e svantaggi... Per esempio il nome delle VM, come visto dai comandi Xen, corrisponde all'ID della VM, un lungo numero un po' scomodo. Viceversa l'organizzazione di directory di OVM e' lineare e di semplice interpretazione.

Virtualizzazione e paravirtualizzazione

OVM e' in grado di ospitare sugli OVM Server molteplici Virtual Machine (VM). Ciascuna VM ritiene di essere eseguita su un hardware dedicato. In realta' il software di virtualizzazione cattura i riferimenti alle risorse fisiche e li simula. Ogni partizione del sistema e' chiamata Dominio. L'unico dominio che accede direttamente alle risorse HW e' Dom0 (ID=0), gli altri domini (DomU) passano sempre attraverso Dom0 per ogni accesso. Su ogni dominio viene installato un sistema operativo Guest e su questo tutte le applicazioni utente. Le applicazioni utente non richiedono alcuna modifica per essere utilizzate su una macchina virtuale.

Le modalita' di virtualizzazione utilizzate da Xen sono due:

Ogni dominio vede un certo numero di processori e di memoria. Anche questi sono virtuali e vengono in realta' condivisi tra tutti i Guest. L'Hypervisor si occupa dell'assegnazione dei processori e della memoria ai diversi domini.
Il sistema operativo ospite vede come device tutti i componenti HW necessari al suo funzionamento (eg. dischi, schede di rete). In realta' si tratta di device virtualizzati chiamati Front-End. A ciascun driver di Front-End presente nel dominio DomU corrisponde un driver di Back-End attivo nel dominio Dom0. Nel caso in cui la VM sia virtualizzata HW e' necessario un ulteriore device QEMU (tapio) che simula il comportamento di un device fisico.

Poiche' richiede un'emulazione la virtualizzazione fisica e' meno efficiente rispetto alla paravirtualizzazione. La differenza e' evidente sopratutto nell'utilizzo dell'I/O. La HWV induce un consumo elevato di memoria su Dom0 in caso di forte traffico di I/O. Per tale motivo, per i principali sistemi operativi, sono stati sviluppati Device Driver paravirtualizzati che possono essere installati su una VM e che rendono piu' efficiente l'I/O anche sui guest virtualizzati HW. In questo caso si tratta di virtualizzazione Hardware con driver paravirtualizzati (PV-HVM).

L'elenco di sistemi operativi supportati, il tipo di virtualizzazione utilizzato e l'eventuale disponibilita' di driver PV supportati da Oracle e' riportata in questa pagina. Per installare i driver PV vanno seguiti i seguenti documenti per Linux e per Windows.

Networking

Le possibilita' di configurazione del networking di OVM sono molto ampie poiche' ereditano tutte le funzionalita' disponibili su Linux e su Xen. Per l'installazione e' sufficiente una sola scheda di rete con una sola subnet. Ma tale configurazione non presenta le caratteristiche di affidabilita' e sicurezza necessarie su un ambiente di produzione. Nel seguito vedremo un esempio su come separare le reti ed evitare single point of failure.
I canali previsti da OVM, e configurabili nella console di amministrazione, sono diversi:

I canali vengono associati alle diverse reti dalla console di amministrazione. Ma per capire l'esatto funzionamento bisogna analizzare la configurazione su Dom0 degli OVM Server.
La figura seguente riporta un esempio ridotto ma con tutti gli elementi necessati per una descrizione completa dei device dedicati al networking: OVM - Networking

E' importante ricordare che la gestione di tutte le componenti HW e' svolta dal dominio Dom0 che comunica mediante device driver ai vari Guest.

Nell'esempio l'OVM Server ha quattro schede fisiche eth*. Le schede sono configurate in bonding per non avere SPOF (Single Point Of Failure). La configurazione consigliata e' in load balancing ottenendo cosi' una banda piu' ampia.
La bond0 e' utilizzata direttamente da Dom0 per il canale di Management sui cui e' impostato l'IP del sistema. Anche gli altri canali di servizio (Heartbeat e Live Migrate) utilizzano la stessa rete. Se il Server e' il Server Pool Master viene utilizzato il VIP bond0:1 ed assegnato l'IP relativo.
La bond1 e' utilizzzata per le reti pubbliche routate che vengono definite sulle VM. Nell'esempio e' mostrato l'utilizzo di una VLAN 69 ed e' quindi stato creato il VLAN tagging bond1.69. Su tale rete sono definite le reti su cui dialogano le VM ed e' quindi necessario un bridge per indirizzare il traffico verso tutti gli IP dei Guest.
Il primo dominio DomU con domain ID=2 e' un sistema paravirtualizzato (PVM) e vede la scheda di rete eth0. Non e' una scheda fisica ma un componente netfront che si comporta come scheda fisica verso il kernel del guest. Al componente netfront corrisponde il componente netback vif2.0 su Dom0. Dal punto di vista del sistema operativo ospite il netfront e' una normale scheda di rete cui si assegna un IP Address.
Il secondo dominio DomU 3 e' un sistema virtualizzato HW (HWM). In questo caso e' necessario un ulteriore tapio QEMU device (tap3.0) che emula un device fisico. Anche il questo caso per il sistema ospite non vi sono differenze e viene normalmente assegnato un IP alla scheda.
Il terzo dominio DomU con ID=4 e' un sistema virtualizzato HW con device driver paravirtualizzati (PV-HWM). Il sistema operativo non e' modificato ma vengono utilizzati Device Driver ad hoc che consentono l'accesso efficiente alle risorse HW. Dal punto di vista di configurazione di rete e di device presenti in Dom0 non vi sono differenze tra PVM e PV-HWM.

Se sono presenti ulteriori VM o reti la struttura resta la stessa e si aggiungono i componenti necessari.

La console di OVM presenta una visione generale della rete... Come vedere i dettagli della configurazione? Semplice: collegandosi a Dom0 ed utilizzando i comandi unix ifconfig -a e brctl show per controllare le schede di rete ed il bridging. Lo stato del bonding e' riportato nei file /proc/net/bonding/*.

Una descrizione piu' completa delle diverse possibilita' e' presentata in questo documento Oracle.

VM

L'utilizzo di OVM e' quello di fornire un ambiente affidabile e cost-effective su cui configurare i sistemi operativi ospite. Spesso questi sistemi manterranno istanze dell'RDBMS Oracle o altri prodotti Oracle ma possono essere ospitati sistemi con funzioni di qualsiasi tipo.
OVM consente di creare, avviare, clonare, migrare, ... VM in modo semplice agendo sulla console di gestione. Nel seguito sono riportati gli elementi architetturalmente piu' importanti.

Per creare una nuova macchina virtuale esistono diverse possibilita':

Per caricare un'immagine (ISO, template, ...) su un repository e' necessario specificare l'URL. I protocolli supportati sono FTP, HTTP e HTTPS. Una tipica stringa e': ftp://root:xxx@10.0.0.1/../stage/V29029-01.zip

La creazione di una VM comporta una serie creazioni/copie di file all'interno del Repository. OVM serializza gli accessi delle attivita' amministrative; quando un repository e' impegnato su un'attivita' la console lo indica con un luchetto ed eventuali job amministrativi vengono accodati.
Per ogni macchina virtuale e per ogni template e' sempre presente un file vm.cfg che contiene i dettagli della configurazione ed uno o piu' file con le immagini dei dischi.

Una volta creata una VM questa viene gestita in modo semplice dalla console e puo' essere utilizzata installando tutte le applicazioni desiderate.

Tra i nodi del Pool e' possibile migrare le VM in modo trasparente all'utente finale con la Live Migration. Naturalmente la migrazione e' possibile solo tra Server della stessa piattaforma (eg. non e' possibile una live migration tra Intel e SPARC).

CLI

La versione 3.2 introduce la OVM Command-Line Interface (CLI): finalmente!
Si tratta di un'interfaccia funzionalmente completa (si possono fare tutte le cose che si fanno da console) e di semplice utilizzo.

Per utilizzare la CLI basta un client SSH:

$ ssh -l admin ovm_manager -p 10000 OVM> list ? AccessGroup Assembly BondPort FileServer FileSystem Job Network NfsAccessGroup PhysicalDisk Port Repository SanServer Server ServerPool StorageInitiator Tag VirtualCdrom VirtualDisk VlanGroup VlanInterface VlanSegment Vm VmDiskMapping Vnic VolumeGroup OVM> list server Command: list server Status: Success Time: 2013-03-25 11:14:16,691 CET Data: id:32:31:30:36:3a:31:5a:63:4a:32:31:33:30:35:56:53 name:xenia_vm01 id:32:31:30:36:3a:31:5a:63:4a:32:31:33:30:35:56:57 name:xenia_vm02 id:32:31:30:36:3a:31:5a:63:4a:32:31:33:30:35:56:6b name:xenia_vm03 id:32:31:30:36:3a:31:5a:63:4a:32:31:33:30:35:56:6c name:xenia_vm04 ...

I comandi principali sono: ? list show help showversion exit... In realta' ho riportato solo quelli che non fanno danni! Ma accedendo all'help si trovano tutti gli altri.

I comandi della CLI sono utilizzabili interattivamente o integrabili con script e su tool esterni.

Naturalmente per accedere e' necessario conoscere e digitare la password... pero' e' possibile automatizzare il login generando una chiave SSH come descritto in questo documento Oracle oppure utilizzando uno script Expect.

Dal punto di vista architetturale la CLI e' un'applicazione ospitata su WebLogic, in ascolto sulla porta 10000 e configurabile agendo sul file /u01/app/oracle/ovm-manager-3/ovm_cli/config/CLIConfigParams.xml.

Configurazioni in alta affidabilita'

Gli elementi da considerare per una configurazione in alta affidabilita' di OVM sono molteplici. Nel seguito riportiamo i principali elementi tecnici di interesse, senza specificare se sono rivolti all'alta affidabilita' (High Availability: HA), alla continuita' di servizio (Business Continuity: BC), alla protezione dei dati, al Disaster Recovery (DR), ...

La progettazione dell'infrastruttura e' fondamentale. Se l'infrastrutttura di base non e' correttamente progettata basta un banale guasto su una porta di uno switch oppure spegnere per errore l'interrutore sbagliato per bloccare tutto!
Vengono dati per scontati ma sono fondamentali: utilizzo di piu' server, alimentazioni separate e ridondate, condizionamento e controllo ambientale, la configurazione in bonding di piu' schede di rete, l'utilizzo di schede in fibra in configurazione multipath, l'utilizzo di RAID-x sullo storage, ... Riassumendo l'infrastruttura non deve presentare SPOF (Single Point Of Failure).

I Server OVM vengono raggruppati in Pool. Oltre a consentire la condivisione di risorse (eg. Storage) e di servizi (eg. VM da manatenere), un Server Pool puo' essere definito come "Clustered Server Pool" fornendo cosi' funzioni di HA. La gestione del cluster e' svolta da OCFS2 che si occupa sia dell'Heartbeat che del locking delle risorse.
E' possibile definire i Server di un Pool e le singole VM in alta affidabilita'. Affinche' sia possibile e' necessario disporre di un cluster di OVM Server con il flag Cluster Enabled attivo e le singole VM debbono essere configurare con il flag HA attivo.
In una configurazione in HA quando viene effettuato uno shutdown di un server tutte le VM in HA vengono migrate in modo trasparente sugli altri server disponibili. Se un server cade tutte le VM in HA vengono riattivate in modo bilanciato sugli altri server disponibili. Il coordinamento dei Server viene svolto dal Server Pool Master (SPM), in caso di caduta dell'SPM un altro server si prende carico delle attivita' ereditando l'IP e divenendo a sua volta SPM.

Significativa e' la gestione dell'HA nel caso di VM che ospitano istanze Oracle RAC. La continuita' di servizio tra istanze diverse e' gestita dal RAC stesso. Su OVM e' possibile definire un gruppo di Anti-Affinity in modo che le VM vengano attivate su Server differenti. In questo modo non sono presenti SPOF: in caso di caduta di un server fisico viene coinvolta una sola istanza del database in RAC e le altre possono continuare ad erogare il servizio.
La configurazione OVM+RAC e' quindi particolarmente efficace sia in termini di flessibilita' che di continuita' di servizio.

A livello di Server Pool e' possibile definire un Policy Control. Per default la policy e' in OFF, le impostazioni possibili sono DRS (Distributed Resource Scheduling) e DPM (Distributed Power Management). E' inoltre possibile impostare il monitoraggio sia sull'utilizzo dele CPU che della rete.

L'OVM Manager nell'architettura OVM e' un componente singolo! Tuttavia il Manager non e' necessario per nessuna attivita' delle VM poiche' e' il Server Pool Master che si occupa del coordinamento tra gli OVM Server. In caso di perdita completa del Manager e' possibile reinstallarne uno nuovo con:
./runinstaller.sh --uuid original_manager_uuid
Lo UUID del Manager e' mantenuto sul file /u01/app/oracle/ovm-manager-3/.config. Terminata l'installazione del software si effettua il restore della base dati (lo script da utilizzare e' /u01/app/oracle/ovm-manager-3/ovm_shell/tools/RestoreDatabase.sh i backup vengono mantenuti su /u01/app/oracle/mysql/dbbackup/AutoFullBackup-data_ora) ed il nuovo Manager e' in grado di riprendere le attivita'. Maggiori dettagli sono riportati in questo documento [NdE oppure in questo documento per le versioni precedenti alla 3.2].

OVM puo' essere integrato in una complessa soluzione aziendale di disaster recovery con un Manager di StandBy in grado di riprendere le attivita' nel caso di caduta del sito di produzione. L'idea di base e' quella di mantenere sulla stessa rete e con lo stesso UUID il server di standby replicando i set di dati su SAN (ma non le configurazioni). Una descrizione completa si trova su questo white paper Oracle.

Hardware Partitioning

Con OVM e' possibile assegnare specifiche CPU ad una VM con il processor pinning. Oracle definisce tale possibilita' Hardware Partitioning e cio' consente di ridurre i costi di licensing dei prodotti Oracle quando si utilizzano le licenze a processore. Dal punto di vista teorico la tecnica del pinning e' di Soft Partitioning ma con le licenze non conta la teoria ma solo la pratica! Per effettuare il pinning delle CPU si utilizzano le OVM utility:
ovm_vmcontrol -u $OVMU_USER -p $OVMU_PASS -h $OVMU_HOST -v VMname -c vcpuset -s 0,1

La VM deve essere riavviata perche' raccolta la nuova configurazione. La verifica dell'assegnazione delle CPU fisiche alle VCPU assegnate alla VM (affinity) si effettua con il comando:
xm vcpu-list VMname

Nelle precedenti versioni (OVM 2.x) l'unico modo per assegnare CPU specifiche alle VM era agire sul file vm.cfg (/OVS/Repositories/Repository_ID/VirtualMachine/VM_ID) impostando il parametro cpus (eg. cpus='0,1').

Per controllare la configurazione delle CPU presenti e l'assegnazione alle varie VM sono utilizzabili i seguenti comandi Xen:
xenpm get-cpu-topology
xm vcpu-list

La funzionalita' di live migration non e' consentita dalle politiche di licensing Oracle a processore e non vanno abilitate le funzionalita' di DRS e DPM. Maggiori informazioni si trovano sulla documentazione ufficiale.

Una nota importante: a differenza di altri prodotti Oracle, OVM ed OEL non hanno un costo di acquisto della licenza ma solo di supporto ed il supporto non e' obbligatorio.

Monitoraggio

In un ambiente di virtualizzazione il monitoraggio dei server e delle VM e' fondamentale sia per verificare il corretto funzionamento di ogni componente che per il controllo delle prestazioni.
La versione 3.2 di OVM ha introdotto importanti nuove funzionalita' che indirizzano proprio questi punti.

Un nuovo tab sulla console di gestione permette di controllare con una sola pagina il corretto funzionamento di ogni componente. Vengono definite delle soglie (eg. CPU%) e la console riporta le VM che eventualmente superano i limiti impostati.

Dal punto di vista prestazionale e' possibile visualizzare grafici relativi all'andamento dell'utilizzo sulle varie VM: OVM - Monitoraggio console

Oltre alle funzioni specifiche di OVM sono comunque disponibili tutte le funzionalita' offerte da Linux e da Xen.

Il controllo delle prestazioni sui sistemi Unix puo' essere svolto con comandi di sistema operativo o con tool appositi di terze parti. Anche se graficamente non curati e poco integrati tra loro, i semplici comandi di sistema forniscono tutte le informazioni necessarie. Tra i comandi piu' utilizzati: top sar vmstat iostat mpstat ...
Sui Linux DomU i normali comandi sar ed iostat forniscono da tempo la colonna %steal che indica la percentuale di CPU utilizzata dall'Hypervisor.

Su Dom0 i comandi Unix (eg. top) forniscono le indicazioni prestazionali relativi al sistema stesso; per verificare lo stato dell'Hypervisor vanno utilizzati comandi aggiuntivi come: xentop xenmon.py ...

Le figure seguenti mostrano l'andamento di un sistema monitorato con xentop durante l'esecuzione di un benchmark di database (TPC-B su Grinder) su una o piu' VM :

OVM - Monitoraggio xentop 2 OVM - Monitoraggio xentop 1

Per il controllo di eventuali errori sono utili sono anche i comandi xm dmesg e xm log e le informazioni contenute nei file di log in /var/log/xen.

Sicurezza

OVM consente di gestire una Farm di VM con un grado di sicurezza a livello Enterprise ma solo se correttamente configurato.
Ad esempio vanno definite password sufficientemente difficili da indovinare. Poiche' le procedure richiedono una lunghezza minima, un carattere numerico, ... le password piu' utilizzate sono Manager1 e Welcome1. Non utilizzatele!

Durante l'installazione dei Server viene richiesta la password degli Agent. Tale password e' necessaria durante la fase di discover del Server. Tutti i Server dello stesso Pool debbono avere la stessa password. E' possibile cambiare successivamente la password di tutti gli Agent di un Pool da console.
Durante l'installazione del Manager viene richiesta una password. Tale password viene utilizzata su un'ampia serie di componenti ed ambienti. L'utente piu' importante e' l'utente admin della console. La stessa password viene utilizzata per WebLogic.

Le utenze di root sia dei Server che del Manager OVM possono essere cambiate senza problemi e debbono essere securizzate.

Nella versione 3.x di OVM non sono piu' gestiti i ruoli come era possibile nelle versioni precedenti. E' possibile creare piu' utenze gestite localmente da WebLogic ma sono tutte utenze amministrative.
Per creare un'utenza (oltre all'utente admin) si usa il comando:
/u01/app/oracle/ovm-manager-3/bin/ovm_admin --createuser

E' possibile crittografare i pacchetti di dati trasmessi durante le live migration. Basta abilitare il relativo flag sulla console (Secure Migration). Ovviamente risulta piu' lenta la live migration...

E' molto opportuno che la rete di management e le eventuali reti distinte di Heartbeat, ... siano su reti dedicate, protette e non routate.

Le impostazioni di sicurezza delle VM dipendono dal sistema operativo ospite e debbono essere eseguite tutte le impostazioni necessarie alla messa in sicurezza dei sistemi cosi' come avverrebbe per un'installazione su macchina fisica.

I template forniti da Oracle hanno tutti la stessa password... quando si crea una VM a partire da tali template ovviamente va cambiata la password di root!

Oracle Corp. pone una particolare attenzione agli aspetti di sicurezza. Le principali indicazioni si trovano questo documento.

Oracle Enterprise Manager

Nella versione 3.x di OVM non sono piu' gestiti i ruoli come era possibile nelle versioni precedenti. E' possibile creare solo utenze amministrative gestite localmente da WebLogic. OVM e' pero' integrabile con Oracle Enterprise Manager Cloud Control 12c (EM) che offre tutte le funzionalita' di gestione necessarie per un'implementazione Enterprise: Role based access control (RBAC), integrazione LDAP/Directory Service, un portale cloud di amministrazione e di self-service per gli utenti finali, ...

L'integrazione tra OVM ed EM e' completa ed le console amministrative due strumenti possono essere utilizzate in modo indipendente [NdE nella versione 2.x se si utilizzava EM non poteva piu' essere utilizzata la Console di OVM].

OVM - Integrazione con Oracle Enterprise Manager


Varie ed eventuali

Un documento introduttivo su OVM e' Oracle VM; il documento contiene un'introduzione e descrive l'installazione dei vari componenti.

E' disponibile un'ampia documentazione sul sito ufficiale Oracle e sul sito di Supporto.

C'e' qualche eccezione e qualche volta la documentazione di base Oracle non basta...
Con i guest Windows, in alcuni casi e' necessario modificare il Registry per caricare i driver IDE (ID 754071.1) al boot.
Su un Linux recente teoricamente i driver PV sono gia' presenti nel kernel quindi l'utilizzo dei driver paravirtualizzati su domini HVM dovrebbe essere automatica... Ma a volte e' necessario escludere i driver normali per fare in modo che non vengano usati agendo sul file /etc/modprobe.conf o su /etc/modprobe.d/blacklist. Con un guest HVM RH5 il disco di boot viene emulato mentre gli altri dischi possono essere paravirtualizzati come descrive questa nota.

L'aggiornamento delle release di OVM e' importante e continuo... conviene sempre utilizzare l'ultima versione di OVM: le funzionalita' sono in continua evoluzione!

L'Oracle Database Appliance (ODA), dalla versione 2.5, supporta Oracle VM 3.1 consentendo di limitare il numero di core licenziati per l'RDBMS. In tale configurazione oltre ai domini Dom0 e DomU viene creato un dominio speciale ODA_BASE con accesso diretto all'HW e CPU dedicate.

Nella versione 3.2 viene installata di default un'utility che estrae la configurazione di OVM nel formato richiesto dal Supporto Oracle. Ecco come lanciare il comando [Doc ID 1521931.1]:
/u01/app/oracle/ovm-manager-3/ovm_shell/tools/vmpinfo/vmpinfo3.sh --username=admin --password=xxx


Titolo: Architettura Oracle VM 3.2
Livello: Esperto (4/5)
Data: 14 Febbraio 2013
Versione: 1.0.3 - 14 Febbraio 2014
Autore: mail [AT] meo.bogliolo.name