AMD e Intel proseguono sulla strada della virtualizzazione

Mi sembrano tutte ottime cose ma da tecnico mi sembrano ancora un po' lontane... Poi magari mi sbaglio (e sarebbe una cosa davvero ottima)...

in effetti di XEN non ne conoscevo solo l'esistenza, pero', visto che parli di para-virtualizzazione, lo posso solo che prendere come un emulatore piu' sofisticato, ne piu' ne meno che il bios emulato di VMware.
per arrivare alla virtualizzazione tutto l'HW DEVE essere adatto alla virtualizzazione, o meglio il BIOS deve consentire la virtualizzazione degli indirizzi fisici dell'HW, ed i driver devono poter essere gestiti da un OS di gestione.
se XEN e' un OS di gestione che ha funzioni di loader e bios per altri OS, questo mi piacerebbe saperlo (anche perche' aspettavo da anni una soluzione del genere!), ma gia' solo per il controllo dell'HW con accesso diretto alla memoria, DMA, ci sarebbero non pochi problemi da risolvere, visto che gia' i driver per un OS "normale" li ha;
ti cito il caso della SB-LIVE su chipset VIA in winXP, che faceva letteralmente crollare le prestazioni sul BUS PCI impadronendosi della gestione DMA, del BUS ed infischiandosene delle altre periferiche, come gli HDD, causando corruzione di dati in spostamenti di file abbastanza grandi, ed annullando anche la funzione di Halt sui procesori AMD; in quel caso era un mix di bug, ma riuscire a districarlo non fu' semplice, tanto che alcuni produttori sconsigliavano l'uso dei tale periferica su alcune schede madri (mentre gli altri modificarono il bios eliminando l'Halt sul processore,eliminando il supporto ATA66, ed impostando il PCI-latency a 0 time).

e si...
credo anche io che siano ancora troppo lontane da oggi..
prevedo che ua situazione del genere sia fruibile tra' 3-5 anni.
ben venga pero' l'inizio di un tale trend HW..

aggiungo..
c'e' da dire,pero', che alcune di queste cose si potrebbero gia' fare:

l'uso contemporaneo di un PC con 2 utenti si poteva effettuare gia' diversi anni fa' montando una piccola scheda nel PC; questa piccola scheda non era nient'altro che una scheda matre formato SCB (subcompact-board), con un suo processore (di solito un AMD k6-x), un bios, la ram, la scheda video e audio ecc, alla quale collegare tastiera, mouse e video;
sulla macchina host si applicava un driver, o meglio un programma per consentire l'uso del disco rigido.
Non era virtualizzazione, in quanto c'era un'altro PC fisico, anche se in forma non standard, ma l'operativita' potrebbe essere considerata simile.

per quanto riguarda gli OS-applicazione, anche questi possono essere costruiti oggi, ma possono solo essere supportati in emulazione; con una unattended inst, tramite famosi tools atti a questo, si puo' creare un OS specifico per il sistema e l'applicazione che si vuole avere; winXP puo' essere letteralmente smontato fino ad arrivare a 185MB, ma e' piu' che fattibile un OS-funzione da meno di 1GB (personalemnte ci sto' facendo un HTPC), senza contare che con il vecchio win9x si puo' arrivare a meno di 20MB con avvio su ram (ma questo appoggia gia' su un OS-gestore, qual'e' il DOS che ha sotto), o l'uso di win9x con avvio funzionale selettivo tramite caricamento degli adatti registri prima dell'avvio del kernell.

La virtualizzazione pero' e' una cosa che va' ben oltre queste "customizzazioni" informatiche, che concettualmente possono portare allo stesso aspetto, ma nell'essenza sono decisamente diverse: la vistualizzazione e' nativa nell'HW, e' pulita e senza escamotage per farla funzionare; l'HW viene richiesto all'occorrenza e per la quantita' che serve, percio' e' differente l'approccio nel progettarlo.

Oggi, avere un dual core virtualizzabile serve a poco (o meglio, a nulla), ma intanto e' un'inizio!
sarebbe stato meglio rivedere la struttura del BIOS (anche se ci sono gia' esempi in questo senso), per rendere questo miniOS piu' adatto ai nuovi d'uso delle macchine che gestisce.

comunque, aspetto fiducioso..

BuddyPC se non ricordo male il nome, fortunatamente non ha sfondato perché mi sembrava una soluzione davvero "sporca"

si, esatto, ma se non ricordo male c'e ne era un'altro..
comunque era una soluzione realmente poco praticabile, abbandonata sia per l'alto costo, sia perche' i PC hanno cominciato a scendee parecchio di prezzo.

il marchio fu' acquistato da un'altra azienda, che diversifico' la linea dei prodotti soprattutto con soluzioni software, mentre in HW si giunse all'adozione di un P4 SCB credo, ma uno degli ultimi kit era una audio USB/HUB per mouse e tastiera e una VGA secondaria, piu' un software di emulazione; nel software, grazie all'avvento di win2000 e WinXP, ci fu' un ottimo terminal server da 21 utenze dal costo irrisorio (rispetto al TS microsoft su win2000/2003TS): 300 dollari o euro, non ricordo.. l'ho usato per un po' ed era fantastico!

x lucusta:

Il sistema che dipingi assomiglia a un OS (attuale) a microkernel, con il "supervisorOS" a fare da microkernel e i vari client "OS-applicazione" a fare le veci, in un certo senso, dei vari moduli-servizi "esterni". L'idea è interessante, ma temo che possa avere delle implicazioni e degli effetti collaterali che paradossalmente potrebbero sortire l'effetto opposto a quello voluto, in particolare in termini di leggerezza e sfruttamento delle risorse.

Innanzi tutto, se non ho frainteso la tua idea di applicazione-microkernel, gli sviluppatori dovrebbero sobbarcarsi la progettazione/realizzazione di un bel po' di roba che ha poco a che fare con l'applicazione in sè, con un paio di conseguenze notevoli (che mi vengono in mente):

- possibili problemi di compatibilità con il supervisorOS (ed eventualmente con gli altri OS-client): oggi una buona parte dei problemi di compatibilità tra applicazione diverse su una stessa piattaforma hw-sw (leggi: stesso os) sono dovuti al mancato rispetto (di alcune) delle linee guida dell'os in questione, con conseguente uso sbagliato di alcune risorse e/o "collisione" con altre applicazioni (anch'esse eventualmente mal concepite); nel tuo scenario avremmo da un lato una minore libertà dell'applicazione (divenuta os client), in quanto isolata rispetto alle altre, dall'altro una maggiore libertà della stessa applicazione, poprio in quanto diventata os-client e dotata di un maggior controllo sull'hw, per quanto virtualizzato (temo possibili eventuali maggiori grattacapi per il supervisor dovendo previnire problemi di deadlock e starvation provocati da client mal concepiti che, ad esempio, chiedono ed ottengono privilegi e priorità eccessivi, privilegi e priorità che potrebbe essere necessario comunque prevedere e garantire in circostanze particolari, ad esempio potrebbero servire a dei moduli-interfaccia, ma si potrebbero fare altri esempi più concreti e difficili da risolvere, solo che non me ne vengono in mente di specifici );

- un aumento considerevole dei costi di progettazione/realizzazione/manutenzione dell'applicazione, che potrebbero diventare proibitivi per alcune (molte) software house, soprattutto perchè a regime (ovvero una volta diffusosi l' "os multi-virtualizzato" ) non avrebbero un ritorno economico: non si tratta di sfruttare delle nuove, maggiori risorse di calcolo, o un nuovo trend di progettazione che sfruttabile in termini di marketing, ma semplicemente di sobbarcarsi una parte del lavoro che prima era prerogativa dell'OS "vero";

- maggiori difficoltà nell'effettuare il porting dell'applicazione da una piattaforma a un'altra, ovvero nel supportare più di un supervisorOS creando un "kernel-client" appropriato, a meno di sfruttare dei client che facciano da middleware di interfaccia, un po' come accade oggi con java o .net, ma temo che il risultato rischierebbe di essere anche molto più macchinoso e pesante.

In sostanza, ritengo che possa avere senso in alcuni ambiti ristretti, meno in molti altri. In realtà si potrebbe realizzare ciò in modo molto più semplice e meno problematico, "limitandosi" a stilare una sorta di requsiti di configurazione che consentano al supervisor di creare on the fly, o una volta per tutte in fase di installazione, l'ambiente operativo basandosi su queste informazioni, ed eventualmente, ove necessario, installando delle proprie versioni dei driver necessari (caso estremo, perchè ci sobbarchiamo il supporto a una gran quantità di hw, anche solo scegliendo delle versioni realizzate dai produttori che meglio si confanno alle nostre necessità ), ma anche questo avrebbe un costo forse non trascurabile, poichè si tratterebbe di individuare in maniera estremamente precisa e per ciascun supervisor supportato non soltanto tutte le risorse necessarie (es: driver delle periferiche da utilizzare, quantità di memoria ecc.), ma anche la suddivisione delle stesse in risorse essenziali (da caricare/richiedere al supervisor all'avvio) e risorse secondarie (da caricare/chiedere quando servono), in modo da consentire la creazione di un ambiente client in grado di gestire le sue risorse in maniera veramente ottimale: sicuramente è più semplice progettare l'applicazione tenendo si conto delle risorse necessarie, ma non della loro gestione, limitandosi a chiederle all'OS nel momento in cui servono e demandando ad esso la loro gestione (cosa che nello scenario dell'OS multi-virtualizzato diventerebbe impossibile, dovendo ciascun os client avere una conoscenza intrinseca delle caratteristiche della/e applicazione/i che va a gestire, conoscenza che in un modo o nell'altro dev'essere l'applicazione stessa a fornire, e deve farlo "pensando" al modo in cui tali informazioni verranno sfruttate). Una conseguenza potrebbe essere che molti, per scarsa voglia/scarsa capacità/fretta(= tempi ristretti) potrebbero scegliere di limitarsi a definire i requisiti in maniera generica (es: tutte le periferiche che l'applicazione potrebbe usare, quindi scheda audio anche per il word processor se è previsto l'inserimento di clip art con effetti sonori o comunque l'import di file multimediali), vanificando i potenziali vantaggi di una virtualizzazione così spinta.

Inoltre, per quanto snelli possano essere i vari client e il supervisor, si rischia di rendere il sistema meno reattivo e più vorace di risorse, dovendo caricare per ogni applicazione anche i driver e qualche modolo relativo all'os necessari: se devo caricare più roba dal disco, essendo questo più lento della ram, tenderà ad aumentare l'intervallo tra la richiesta e la risposta; se ho molti client in esecuzione con esigenze simili avrò anche delle copie superflue di driver e moduli os. Questo è tanto più vero quanto più si considera:

- un tipico scenario di utilizzo con molti programmi in esecuzione, che diventerebbero molti piccoli os con il proprio kernel minimale e i propri driver, che potrebbero essere in parte identici e replicati ( -> rischio di peggiorare l'occupazione della ram e di "swappare" quantità maggiori di dati, con possibili rallentamenti), se poi ottengo dei rallentamenti che mi costringono (o spingono il supervisor) a "parcheggiare" alcuni os client (in misura maggiore di quanto sarebbe accaduto prima) ne traggo una perdita in termini di capacità in multitasking (ok, avrò anche maggiori risorse hw, ma ci penseranno le sole applicazioni a trovare il modo di sfruttarle non al meglio per risparmiare sui tempi di sviluppo), se poi devo farlo manualmente, ho perso anche in termini di usabilità (in particolare se non sono un power user);

- la possibilità che alcuni moduli client operino come interfaccia per altri moduli, come ad esempio nel caso del client-videogame + client-firewall/antivirus (che nel caso specifico può risultare superfluo, poichè se le cose sono fatte bene, al massimo rischio problemi con il solo client-videogame, ma nessuna o limitate possibilità di accesso per il virus/intruso agli altri moduli, comunque può risultare utile in questo e in altri scenari - ad esempio utilizzo di internet per fini lavorativi con possibile esposizione di dati sensibili): in questo caso avrò un modulo dell'os videoludico che consente la connessione diretta a internet (ovvero l'accesso all'hw di rete) e un modulo analogo nel client-firewall, ma chiaramente non ha senso consentire ad entrambi l'accesso diretto alla rete (altrimenti il firewall non avrebbe alcun potere di controllo sul traffico generato dal videogame), quindi dovrò provvedere, nel client videoludico, un ulteriore modulo che emuli in qualche modo l'accesso alla rete, o quanto meno faccia credere al videogioco di poter accedere alla rete: deve poter gestire i pacchetti in uscita dal gioco e quelli in entrata, senza però accedere fisicamente alla rete, ma connettendosi "virtualmente" al client-firewall con uno schema client-server (di qui il comportamento da "interfaccia" di quest'ultimo); il modulo firewall dovrà quindi comportarsi da router/proxy con funzioni di firewall, content filter e antivirus (a meno di voler dividere tutte le funzioni in moduli diversi, con ulteriore complicazione: si allungherebbe la catena delle interfacce e ciascun modulo si comporterebbe da client rispetto all'interfaccia più "vicina" all'hw e da server rispetto a qella che si appoggia ad essa). Insomma, con delle risorse hardware sufficienti, può essere una soluzione interessante ai fini della sicurezza, ma forse un po' (troppo) macchinosa: in fondo, in un certo senso stiamo emulando via software, seppur con il beneplacito di periferiche e componenti ad hoc, un firewall hardware mediante uno o più server virtuali dei quali solo uno ha accesso diretto all'hw (mi pare ovvio, altrimenti ognuno genererebbe un traffico diverso), per cui i vantaggi del supporto alla virtualizzazione vanno a farsi benedire: ho solo aggiunto degli strati che oltretutto comunicano tra di loro come se ciascun modulo operasse su macchine differenti.

Il problema della (possibile) mancata corrispondenza della leggerezza globale del sistema alla leggerezza di ciascun modulo os (il quale funzionerebbe magnificamente e senza inconveniente alcuno, usando sempre le risorse minime indispensabili, ma da solo ), a mio modo di vedere, si complica, come si potrebbe dedurre dall'esempio del gioco online, se si considerano le implicazioni della comunicazione tra i diversi moduli: poichè si comportano come se fossero in esecuzione su macchine diverse, dovremo dotare ciascuno di un servizio in grado di comunicare, di ricevere e inviare dati, quindi avremo sempre almeno due (o più ) componenti software identici in "funzione" durante l'interazione di due (o più ) moduli, se vogliamo che i moduli gestiscano l'interazione - ed eventualmente la sincronizzazione - bypassando il supervisor (ha senso farlo: per fare un parallelo esemplificativo potremmo paragonare questo meccanismo al multiprocessing simmetrico), più un terzo se invece vogliamo che il supervisor intervenga e faccia da arbitro (un po' come nel multiprocessing asimmetrico), elementi che, per quanto "leggeri" impiegano delle risorse che in un "mono-os" potrebbero essere relative ad uno soltanto di essi, a meno che non si voglia demandare l'intero meccanismo al supervisor (quindi un solo "servizio di comunicazione" ), limitandosi a inserire nei client le funzioni necessarie per richiedere un servizio al supervisor, riducendo la questione ad una funzione generica con dei parametri che rappresentino il servizio richiesto e l'oggetto della comunicazione (può essere un puntatore all'area dati da copiare nell'area corrispondente dell'altro os-client, a meno di voler far condividere una certa area di memoria ai due os, ma in questo modo l'isolamento garantito dalla virtualizzazione andrebbe a farsi benedire), ed avremmo comunque delle copie evitabili che non mi sento di trascurare non tanto per il loro peso (parlando della funzione per richiedere un servizio al supervisor, meno per i dati scambiati, pensando ad esempio ad una scansione di un immagine ad alta definizione ad opera del client relativo, da passare al client che la dovrà elaborare), quanto più per la perdita di funzionalità come la condivisione di librerie (dll, so e compagnia), a meno di voler rinunciare in parte all'isolamento degli os che non caratterizzerebbe più questa forma di virtualizzazione (anche se si potrebbe trasformare in un servizio di tipo client-server in cui un modulo si comporta da "server-dll" per gli altri, ma non avrebbe più senso in questo caso demandare la gestione dell'interazione tra os client all'os supervisor), oppure a meno di demandare anche questa funzionalità al supervisor, però così facendo rischiamo di inserire troppo roba nel supervisor, appesantendolo, snaturandolo e complicando la progettazione di tutto: ci troveremo a dover scrivere degli os client completi ma non troppo, con alcune funzionalità demandate al supervisor, e un supervisor os snello e con funzioni ridotte ma non troppo, per poter "switchare" da uno scenario in cui le macchine virtuali non interferiscono, non interagiscono, usano risorse differenti e non appesantiscono il sistema con moduli replicati, ad uno in cui è preferibile un comportamento più simile ad un "mono-os" general purpose classico. Il rischio è sbagliare da qualche parte, esagerare in un senso o nell'altro, complicare comunque la progettazione e lo sviluppo, e creare un pastrocchio che coniughi i difetti di entrambe le soluzioni (mono-os classico/multi-virtualizzato) e di entrambe perda i pregi (naturalmente potrei aver torto su tutta la linea).

Poi non ho capito bene il discorso che facevi sui driver: il driver generico di xp per le schede video in pratica emula (in realtà non so con certezza se si tratti di una emulazione software o dello sfruttamento di caratteristiche di base comuni a tutte le vga, passami il termine - e potrebbe essere, per esperienza ho notato rallentamenti paurosi nello scorrere una pagina web, ma avevo anche altri problemi che però non credo influissero) una vga molto generica e con caratteristiche molto limitate (refresh fisso a 60hz, limiti di risoluzione, profondità di colore, ecc. ). Un driver "ufficiale" deve ovviamente supportare tutte le caratteristiche della scheda per sfruttarle appieno, poi (su disco) deve avere anche dei moduli per poter gestire schede differenti (specialmente se è un driver all-in-one), più altri moduli per l'interazione con l'utente (mediante interfaccia grafica) e un'eventuale tray. Ultimamente ci infilano anche dei jit per sistemare gli shader dei giochi e ottimizzare il codice al volo, ma chiaramente ci sono sempre degli elementi che si possono considerare superflui e non utilizzarli se non quando realmente necessari (e se il driver carica di tutto di più allora magari andrebbe rivisto), tuttavia per quanto si possa ridurre non sempre si possono fare miracoli (se le funzioni "native" e specifiche della periferica sono tante, a meno di rifare i driver e creare tante varianti per tanti scopi diversi, ma credo sia più facile che Ati e Nvidia ci rifacciano i connotati se glielo chiediamo ), e si presenterebbe comunque la questione delle copie multiple per ciascun os-applicazione, per quanto alleggerite (ma da molti mega fare pochi k la vedo dura), poichè ritengo quanto mai essenziale, in uno scenario "multi-virtualizzato", ai fini della stabilità operativa, tenere i driver il più possibile, a meno di una parte piccola e molto generica, nello spazio utente, ovvero quello del sistema-applicazione, perchè se un eventuale crash coinvolgesse in qualche modo anche un driver rischierebbe di colare a picco tutta la nave (a spanne direi che la stabilità delle macchine virtuali sia in qualche modo proporzionale al loro reciproco isolamento: maggiori sono i legami e le risorse condivise, eventualmente a mezzo di un "intermediario", quale il supervisor in questo caso, e maggiori possono essere le ripercussioni reciproche dei problemi che si verificano in ciascuna).

Temo che potrebbero esserci più contro che pro, del resto spezzare troppo un problema in sottoproblemi (in questo caso la funzione di un unico os general purpose multitasking in tanti piccoli os monotask, coordinati da un os supervisore) può risultare controproducente tanto quanto il suo opposto. Personalmente propenderei per una virtualizzazione più classica (sulla scia degli esempi fatti da leoneazzurro e bjt2), con un supporto nativo da parte dell'os che consenta di creare più istanze di se stesso customizzabili, in modo da renderle leggere ed essenziali per non appesantire troppo il sistema, in congiunzione ai vantaggi prodotti dalla virtualizzazione (sicurezza, stabilità operativa) in casi specifici o per scelta dell'utente.

Chiaramente, tutto IM(very,very,very)HO.

Per quanto riguarda il discorso delle licenze, anche a prescindere dalla capacità nativa dell'os di creare altre sue istanze, credo che molto dipenderà da come verrà gestita l'interazione con il sistema ad opera dello strato software di supervisione e allocazione delle risorse a ciascuna istanza di os: se le macchine virtuali saranno esportabili/verranno esportate su altre macchine e utilizzabili/utilizzate come una installazione dell'os allora il problema della licenza sarà inevitabile, diversamente, gestendo il tutto su una sola macchina, come una sorta di multiboot contemporaneo da installazioni e partizioni diverse (ma sempre sulla stessa macchina) allora potrebbero ricrearsi le stesse condizioni che hanno portato la MS a considerare, nei sistemi monoprocessore multicore, i core logici/fisici in più come ininfluenti per la determinazione del numero di licenze, in modo da non affossare la tecnologia dualcore (e multicore in generale) in ambito desktop. Non escluderei che venga presa una decisione simile anche per la virtualizzazione, prima di passare al supporto nativo, sempre che si voglia promuovere da subito la nuova tecnologia hw anche nel segmento desktop, o SOHO se vogliamo.

x leoneazzurro

Immagino che quelle due applicazioni siano pesanti da gestire tramite virtualizzazione "emulata" classica con l'hw che avete, o forse si è preferito tagliare la testa al toro e usare due macchine piuttosto che una sola e sobbarcarsi la licenza di un gestore di macchine virtuali, tipo vmware server.

Sono applicazioni windows? Se è così, ti è possibile fare una prova alla cieca (su partizione diversa o altra macchina, in modo da non causare problemi al lavoro), di quelle fatte tanto per vedere che succede, e se va male al massimo bisogna ricostruire l'universo (:P)? No, perchè mi chiedevo (niente di così tragico, l'espansione delle galassie non si può invertire ) quanto fosse "profonda" l'incompatibilità e se non potesse bastare l'isolamento minimo (minimo, minimo) concesso dalla multiutenza: se bastasse tenere separate (ammesso che supportino la multiutenza) chiavi di registro, cartelle di lavoro e user space, facendo eseguire una applicazione direttamente sulla macchina e l'altra contemporaneamente ma loggandosi come un altro utente (via lan, da un'altro computer), allora forse ci sarebbe una speranza di risolvere il problema con una macchina sola, usando più utenti e il runas su explorer (non ie, proprio explorer.exe). Con runas su explorer oltre ad acquistare i privilegi fai girare i programmi col profilo completo dell'utente, quindi le chiavi usate sono quelle dell'utente (se non vengono usate chiavi in hklm chiaramente), le cartelle di lavoro possono essere separate facilmente (e ti rimangono due diverse istanze di explorer con accesso alla cartella documenti ed altre con restrizioni particolari relative a quell'utente), ma non so quanto separati siano i contesti di esecuzione degli utenti (la management consolle, quindi servizi, gestione eventi ed altri oggetti di sistema, è sempre unica, ma lo è anche usando la multiutenza via lan per eseguire applicazioni su un computer remoto). Magari non c'entra un cactus col vostro problema...

Si, chiaramente con l'hardware attuale sarebbero applicazioni pesantucce da gestire con VMWare, non tanto il PDM quanto il CAD. Purtroppo le ho provate tutte, anche attraverso il supporto tecnico, ma nisba.
Il problema poi sarebbe che le due applicazioni sovrascrivono a vicenda delle chiavi di registro (appunto), condividono alcune librerie ma richiedono per funzionare bene versioni diverse delle stesse, richiedono ovviamente alcuni path specifici per i file di inizializzazione e altrettanto ovviamente tutto è gestito non a livello di utente. Provato ad installare in due partizioni diverse, ecc.
Tu pensa solo che per installare gli aggiornamenti del CAD non sono previste patch incrementali, ma bisogna reinstallare il pacchetto da capo
Questo senza parlare dei casini con il manager delle licenze (presente FlexLM?), che per fortuna ho risolto con un file batch eseguito all'avvio...