Link alla notizia: http://www.hwupgrade.it/news/server/16324.html

I due produttori di processori comunicano passi in avanti concreti nella disponibilità delle proprie tecnologie hardware per la virtualizzazione

Click sul link per visualizzare la notizia.

Sicuramente è una cosa interessantissima. Non vedo l'ora di poter usare istanze diverse di SO diversi ... Perchè non pubblicate un bell'articolo a riguardo quando questi processori saranno effettivamente disponibili? Magari con dei bei casi d'uso...

All'interno delle sale dati si sta sempre più manifestando il problema della corretta alimentazione e del raffreddamento dei server
In tal caso può aiutare una dieta bilanciata e un po' di moto, che mantengono in forma le difese immunitarie... :asd:

Io vorrei capire in cosa questa virtualizzazione si differenzi da Xen per fare un esempio
:huh:

Che Xen virtualizza a livello software con decadimento delle prestazioni, mentre amd e intel stanno facendo la virtualizzazzione a livello hardware, quindi senza decadimento delle prestazioni. Il problema è capire a che serve per l'utente comune.

In tal caso può aiutare una dieta bilanciata e un po' di moto, che mantengono in forma le difese immunitarie... :asd:

:rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl:

Vorrei approfittarne per segnalare che VMWare ha in programma di rilasciare gratuitamente, dopo VMWare Player, anche il nuovo programma (attualmente in versione beta) VMWare Server. Per ottenere un numero di serie occorre una registrazione (sempre gratuita)...

Quindi queste tecnologie permetterebbero di sfruttare meglio programmi come VMware? Ma non basta una cpu dual core per farlo?

Quindi queste tecnologie permetterebbero di sfruttare meglio programmi come VMware? Ma non basta una cpu dual core per farlo?

Si queste tecnologie permettono o permetteranno di sfruttare al meglio VMWare, VirtualPC/VirtualServer e XEN (in particolare sembra che XEN le supporti già). Il requisito non è per forza di cose una CPU dual core (che ovviamente aiuta moltissimo), infatti VT è attiva anche sulle CPU della serie P4 6x1. Il vantaggio di VT e Pacifica è che permettono di migliorare anche la condivisione del resto del sistema e non solo della CPU che non verrà più gestita da uno sei due sistemi ma da entrambi.


Sicuramente è una cosa interessantissima. Non vedo l'ora di poter usare istanze diverse di SO diversi ... Perchè non pubblicate un bell'articolo a riguardo quando questi processori saranno effettivamente disponibili? Magari con dei bei casi d'uso...

Come non quotarti, mi associo alla richiesta :D

Sembra che uno dei più immediati vantaggi delle tecnologie hardware di virtualizzazione sarà quello di semplificare enormemente la scrittura di programmi di virtualizzazione.

Attualmente gli HyperVisors (che sono delle specie di "semafori" software che regolano le priorità e la riscrittura di codice fra sistema host (quello reale) e sistema guest (quello virtuale)) richiedono veri salti mortali a livello di codice per poter funzionare correttamente.

Dopo l'introduzione di queste tecnologie questi software diventeranno molto più semplici, e presumibilmente più veloci.

Basta pensare ai "numeri" che vengono fatti a livello di semgemnti e vari Ring di funzionamento per il funzionamento di VmWare per esempio! Le tecnologie di virtualizzazione aggiungono un livello di indirezione hw alla paginazione,segmentazione,I/O ! Cose che sono in fatti ora il collo di bottiglia delle soluzioni sw citate anche precedentemente :)

prima di gridare al miracolo voglio vedere in cosa consiste e se serve davvero...
:/

prima di gridare al miracolo voglio vedere in cosa consiste e se serve davvero...
:/

Il fatto non è "se serva davvero" ma quanto possa portare in cambiamenti dalla situazione attuale. Al momento le macchine virtuali ci sono e funzionano. Ma pur restando sempre aggiornato per quanto mi è possibile, ho notato che quella della Virtualizzazione è l'unica tecnologia delle nuove CPU di cui non ho ancora capito i benefici al 100%...

Qualcuno sà se verra implementato anche Presidio?

In ambito casalingo probabilmente non la utilizzerete mai la virtualizzazione...
Ma in ambito server è utilissima!

Su un server con 2 Opteron dual core ci ho messo su Xen e su una macchina virtuale faccio hosting con una certe configurazione software, su un'altra faccio dei test con un'altra configurazione software sempre per l'hosting e ora penso che farò una per il voip e una per testare dei server per caldav.

Che Xen virtualizza a livello software con decadimento delle prestazioni, mentre amd e intel stanno facendo la virtualizzazzione a livello hardware, quindi senza decadimento delle prestazioni. Il problema è capire a che serve per l'utente comune.
Questo non penso sia vero. La virtualizzazione di Xen (paravirtualization) è la migliore in termine di prestazioni per quanto riguarda la virtualizzazione di SO diversi, l'unico svantaggio è che richiede la modifica del kernel dei SO virtualizzati (quindi nessun problema per Linux, NetBSD, Solaris, mentre NO Windows).
Con le estensioni Hardware anche con Xen sarà possibile virtualizzare qualsiasi SO, quindi anche Windows, perchè utilizzerà una virtualizzazione (come VMWare), solo che le prestazioni saranno inferiori rispetto a quelle della paravirtualization.

Qualcuno sà se verra implementato anche Presidio?

Si

credo che si stia facendo un po' di confusione sull'argomento..

la virtualizzazione proposta da AMD e Intel non e' la stessa cosa della "virtualizzazione" di VMWare, XEN e VirtualPC: queste sono EMULAZIONI.

La virtualizzazione dei sistemi permette di creare altri ambienti operativi, indipendenti dal primo, con i quali dividere le risorse dell'intero sistema, usando l'HW per come dev'essere usato al meglio, ossia con i propri driver, e non emulando i driver, e tantomento emulando l'HW.

Questa nuova operativita' permette di avere piu' ambienti lavorativi, sulla stessa macchina, ma separati; delle shell capaci di sfruttare la macchina in ogni sua parte per quanta potenza e' disponibile al momento, capaci all'occorrenza di dialogare tra' loro.

gli esempi per le realta' professionali sono molteplici, ma focalizzerei piu' che altro sulla realta' casalinga, quella degli utenti normali:
ad oggi gia' un dual-booting puo' dare dei vantaggi considerevoli, permettendo di separare un'ambiente lavorativo da un'ambiente ludico; con alcuni sistemi operativi si puo' decidere all'occorrenza che servizzi abilitare, gravando sulle risorse del sistema, ma domani sara' possibile avere ambienti dedicati, ossia delle shell con OS dedicati a compiti specifici, a livello di applicazione, moduli da poter avviare indipendentemente dagli altri, leggeri, accuratamente studiati, semplici, e percio' facilmente proteggibili; interattivi tra' di loro, ma indipendenti, diversamente da oggi, dove si ha un registro unico per tutto il sistema, e dove un'applicazione puo' "invadere" settaggi e operativita' di un'altra, sia essa anche una parte vitale del sistema.

a questo punto si potra' avere una shell per la navigazione, protetta da una shell firewall, e controllata da una shell antivirus, scaricare un'immagine, avviare la shell di lavorazioni immagini, elaborarla e poi passarla alla shell d'impaginazione e metterla su un foglio di lavoro.
qual'e' il vantaggio?
tra' uno step e l'altro si possono chiudere le shell non indispensabili e scaricare dalle risorse del sistema, potendo ottenere cosi' un sistema intrinsecamente leggero e veloce.
guardate i sistemi general porpouse di oggi: ora ho aperta una sola pagina del browser, ho un'allocamento della ram di oltre 280MB, e sono pochi, perche' in background girano decine di piccoli programmi e servizzi che non sono necessari al momento, ma che lo potrebbero diventare a richiesta, richieste che per certi lavori non avverrano mai: avere il servizio di Acquisizione immagini di windows WIA, o il "zero configuration per le reti senza fili" ora non serve, ma e' comunque attivo, perche' potrebbe servirvi in un'altro ambito di lavoro, ed e' poco utile arrestarlo per poi riavviarlo; ma il problema non e' se e' attivato o disattivato, ma che per averlo, questo, come innumerevoli altri servizzi, programmi e funzionalita', ho un registro di configurazione del sistema da oltre 80MB, e si' che lo curo abbastanza.
Non sarei sorpreso se alcuni utenti avessero oltre 200MB di registro sulle proprie macchine..
(per rendervene conto aprite regedit ed esportate tutto il registro della vosta macchina)

La virtualizzazione mi permetterebbe di lavorare con si e no 50MB di ram occupata, eliminerebbe il 50% del carico della CPU (ma solo perche' il carico e' quasi nullo), il che mi consentirebbe di poter fare agevolmente lo stesso lavoro con un 400MHz, invece che con un 1000Mhz calmierato dal C&Q; con il modo di operare dei sistemi moderni, o meglio l'uso che ne fanno le persone, un processore da 1000Mhz e' il minimo che si possa avere, e sarebbe quasi inutile progettare una CPU piu' complicata in modo da poter scendere ancora sotto questa soglia, senza poi avere reali benefici sia di risparmio che di operativita' (tanto in basso non ci andrebbe quasi mai).
Ma un dual core e' diverso, infatti i nuovi yotha hanno stati di quiete ben piu' aggressivi (ma funzionano?).
comunque, all'ocorrenza, potrei aver bisogno di altri 500MB di ram per il fotoritocco, e qui' c'e' la differenza, perche' in una situazione odierna questi sono utilizzati da tutto il sistema, e il resto e' a disposizione del programma di fotoritocco, mentre un domani potrei utilizzare esclusivamente la shell dedicata all fotoritocco, e mi risparmierei un'altro banco di ram..

serviranno ancora 5 o 6 anni prima di ottenere reali vantagi da questa tecnologia, ma prevedo che l'evoluzioni degli OS saranno sensibili: si comprera' un OS di gestione, una specie di BIOS a livello superiore, e tanti moduli specifici da poter aggiungere, alla stregua dei programmi di oggi.
in questo modo il passaggio sara' inavvertibile, ma saranno sensibilmente piu' sfruttate le macchine, soprattutto in previsione di multi-core di futura generazione.

OK, ma mi associo a chi chiede: a cosa servono ad un utente comune? Fino ad ora l'unica cosa che ho scoperto è, ad esempio, che è possibile avviare una VM basata su Linux (mi sembra fosse Ubuntu) con FF preinstallato per navigare con una sicurezza prossima al 100%. Ma questo vale milioni di $ di investimenti in queste nuove tecnologie HW?

Credo ci sia ben altro sotto... mi sbaglio?

La virtualizzazione è per aziende o per power users. L'utente domestico non può averne vantaggi. Se Bill riesce a rendere Windows più stabile e immune da virus/malware magari limitando i privilegi dell'utente standard per default.

Per una casa avere la multiutenza vera che è stata introdotta con Windows XP è già sufficiente. Chiaro che se poi c'è lo studente a cui serve Linux, il fratellino che deve provare giochi e download, il padre che usa programmi di contabilità e non vuole vedere il pc devastato dalle porcherie dei suddetti due allora la virtualizzazione può essere utile anche in casa...

queste tecnologie devono lavorare con XEN, non funzionano mica senza un software. Sono pensate per xen e xen già le supporta. (S3pHiroTh: decadimento prestazionale di xen??? ma dove? fa il 98% delle performance native)

OK, ma mi associo a chi chiede: a cosa servono ad un utente comune? Fino ad ora l'unica cosa che ho scoperto è, ad esempio, che è possibile avviare una VM basata su Linux (mi sembra fosse Ubuntu) con FF preinstallato per navigare con una sicurezza prossima al 100%. Ma questo vale milioni di $ di investimenti in queste nuove tecnologie HW?

Credo ci sia ben altro sotto... mi sbaglio?

Ad esempio si potrebbe far girare ogni applicazione in una macchina virtuale ad essa dedicata con elevate prestazioni e stabilità elevatissima, dato che la separazione delle applicazioni viene realizzata in hhardware e non in software come avviene ora. Secondo te quali vantaggi presenta questa situazione?

Ad esempio si potrebbe far girare ogni applicazione in una macchina virtuale ad essa dedicata con elevate prestazioni e stabilità elevatissima, dato che la separazione delle applicazioni viene realizzata in hhardware e non in software come avviene ora. Secondo te quali vantaggi presenta questa situazione?
o sono un patito linux, oppure devo comprarmi n licenze di OS...
hmm... :stordita:

@lucusta e tutti
la virtualizzazione di amd e intel è simile a quella di xen, ma realizzata in hardware. Tant'è che xen non è un emulatore!! ma si parla di para-virtualizzazione. Questi processori amd e intel necessitano comunque di un programma supervisore e di un sistema operativo "principale". Al momento xen solo supporta queste tecnologie e ho letto che sono già riusciti a far partire windows come sistema ospite... In pratica xen si basa su un kernel modificato e un "hypervisor" (più dei servizi di supporto). Quello che si ottiene con questi processori è un aumento delle prestazioni sul passaggio da un so all altro e su certe attività e non c'è più bisogno del kernel modificato. Questo hardware è sviluppato a stretto contatto con xen, almeno per ora.

o sono un patito linux, oppure devo comprarmi n licenze di OS...
hmm... :stordita:

No, perchè la cosa sarebbe possibile solo con un SO che supporta la virtualizzazione.
Mi spiego meglio: il multitasking di Windows si appoggia a mezzi software, nel senso che ad esempio per tenere separate le applicazioni utilizza dei meccanismi software che possono soffrire di determinati bug, ecc. Un SO "virtualizzato" potrebbe invece creare varie macchine virtuali gestite in HW, una per ogni applicazione e impedire qualsiasi tipo di conflitto SW.

Inizialmente tale tecnologia sarà utile soprattutto in ambiente server.
Pensate a tre server che hanno tre compiti diversi e che hanno un carico medio basso.
Soluzione: compro un solo server e virtualizzo i servizzi. Risultato: soldi risparmiati e tutti contenti. :D
E poi tutti quelli che hanno un dual-boot e che devono riavviare per usare un particolare software o per altri motivi.
Le possibilità di sviluppo sono infinite (considerando anche lo sviluppo di cpu multi-core).

queste tecnologie devono lavorare con XEN, non funzionano mica senza un software. Sono pensate per xen e xen già le supporta. (S3pHiroTh: decadimento prestazionale di xen??? ma dove? fa il 98% delle performance native)

Non sono pensate per XEN, sono pensate per i software di virtualizzazione in generale.

Inizialmente tale tecnologia sarà utile soprattutto in ambiente server.
Pensate a tre server che hanno tre compiti diversi e che hanno un carico medio basso.
Soluzione: compro un solo server e virtualizzo i servizzi. Risultato: soldi risparmiati e tutti contenti. :D


E perchè allora dovresti aver bisogno della virtualizzazione? Non puoi dare a un server i compiti di quei tre che sostituisci senza usare la virtualizzazione e vivere felice lo stesso?

Ho tre server, uno web, uno ftp e l'altro SMTP. Tutti con carichi bassi. Ne compro uno solo, installo e configuro Apache, vsftpd e Sendmail sullo stesso server. Non vado bene lo stesso?

E perchè allora dovresti aver bisogno della virtualizzazione? Non puoi dare a un server i compiti di quei tre che sostituisci senza usare la virtualizzazione e vivere felice lo stesso?

Ho tre server, uno web, uno ftp e l'altro SMTP. Tutti con carichi bassi. Ne compro uno solo, installo e configuro Apache, vsftpd e Sendmail sullo stesso server. Non vado bene lo stesso?


Nel tuo esempio sono tutti servizi installabili sullo stesso OS.
Ma se devo usare OS differenti?



Edit: tieni presente che a volte, per alcune esigenze, è meglio avere servizi separati su macchine diverse anche se possono essere installati sullo stesso OS e per alcuni di questi casi la virtualizzazione può anche essere una valida soluzione.

No, perchè la cosa sarebbe possibile solo con un SO che supporta la virtualizzazione.
Mi spiego meglio: il multitasking di Windows si appoggia a mezzi software, nel senso che ad esempio per tenere separate le applicazioni utilizza dei meccanismi software che possono soffrire di determinati bug, ecc. Un SO "virtualizzato" potrebbe invece creare varie macchine virtuali gestite in HW, una per ogni applicazione e impedire qualsiasi tipo di conflitto SW.

scusa ma che è il "multitasking software" O_o ? asd
La separazione degli spazi di indirizzamento è gestita a livello hw da quando esiste :PPP direi quindi col 286 a segmenti e 386 con paginazione ^ ^
Con ste tecnologie come gia detto si interpone un ulteriore livello di indirezione= tabella a 2 colonne con indice e puntatore che permette la condivisione risorse memoria/io tra i diversi so in esecuzione. Il cambio di contesto tra il processo di un so e quello di un altro avrà quindi lo stesso peso come se fossero 2 processi dello stesso sistema operativo. Immagino poi che il sistema operativo "master" sia in grado di "swappare" via i so magari in idle :PPPP

scusa ma che è il "multitasking software" O_o ? asd
La separazione degli spazi di indirizzamento è gestita a livello hw da quando esiste :PPP direi quindi col 286 a segmenti e 386 con paginazione ^ ^
Con ste tecnologie come gia detto si interpone un ulteriore livello di indirezione= tabella a 2 colonne con indice e puntatore che permette la condivisione risorse memoria/io tra i diversi so in esecuzione. Il cambio di contesto tra il processo di un so e quello di un altro avrà quindi lo stesso peso come se fossero 2 processi dello stesso sistema operativo. Immagino poi che il sistema operativo "master" sia in grado di "swappare" via i so magari in idle :PPPP

Infatti io non ho parlato di indirizzamenti (dove l'ho detto?) ;) Ma esattamente di quel che stai dicendo tu ;)
Mi spiego meglio: la mia idea partiva dal fatto che attualmente si utilizza una istanza di un SO e più applicazioni che condividono comunque l'utilizzo delle risorse a disposizione del SO. Magari con un SO "virtualizzato" si potrebbero utilizzare più istanze dello stesso SO, una per ogni applicazione, in modo che in caso di qualsivoglia crash potrei passare da una macchina virtuale all'altra.
Potrebbe ad esempio essere utile nel caso di software notoriamente mutuamente incompatibile (e me ne sono capitati). Preciso che non parlo di driver, ovviamente.
Si, lo so, potrebbe sembrare inutile a molti, ma in certi casi farebbe risparmiare parecchio sull'HW. PS: era solo una mia idea su come potrebbe essere usata la virtualizzazione.
Poi ovviamente per chi lavora con più SO è una manna.

OK, ma mi associo a chi chiede: a cosa servono ad un utente comune?

Se ho capito bene di cosa si discute, un esempio che mi viene in mente riguarda il mio HTPC (Home Theater PC).

E' difficile e molto oneroso raggiungere un equilibrio di software soddisfacente su un HTPC. Poichè occorre utilizzarlo anche per scaricare software e media da Internet, si pongono due problemi:

- gli antivirus, firewall, etc... sottraggono risorse prestazionali critiche in un HTPC (poi i film scattano);

- c'è il rischio che un virus preso da Internet devasti la configurazione faticosamente raggiunta.

Avendo due macchine virtuali, se queste fossero realmente separate, si risolverebbero i problemi di prestazioni e sicurezza. :cool:

Michele

Il problema è che immagino che la ripartizione della RAM debba essere fissa e che comunque ogni VM ha il suo spazio separato: quindi doppia copia del kernel, dei drivers, ecc... Invece con un unico SO è tutto condiviso e quando una applicazione non usa della RAM può essere usata per altro... Invece così hai della RAM perennemente occupata...

Se ho capito bene di cosa si discute, un esempio che mi viene in mente riguarda il mio HTPC (Home Theater PC).

E' difficile e molto oneroso raggiungere un equilibrio di software soddisfacente su un HTPC. Poichè occorre utilizzarlo anche per scaricare software e media da Internet, si pongono due problemi:

- gli antivirus, firewall, etc... sottraggono risorse prestazionali critiche in un HTPC (poi i film scattano);

- c'è il rischio che un virus preso da Internet devasti la configurazione faticosamente raggiunta.

Avendo due macchine virtuali, se queste fossero realmente separate, si risolverebbero i problemi di prestazioni e sicurezza. :cool:

Michele
dubito
l'occupazione del processore deve necessariamente esser maggiore, perchè deve tenere a bada due OS invece che uno, oltre ad entrambi i programmi, quindi si aggiunge una variabile, mica da poco
per quanto riguarda la sicurezza, questo è molto relativo. avrai un os scoperto, e uno invece a pericolo, quindi non è che cambi molto
il problema del virus mi sembra più semplicemente arginabile usando un semplice antivirus, ne esistono di free. oltretutto il rischio è tangibile solo durante la navigazione o l'apertura di eseguibili, cose che comunque non avvengono se sei impegnato a fare qualcos'altro (es: guardare il film)
l'unico campo per l'utente comune è quello della divisione effettiva delle risorse per la diversa utenza (PC di famiglia condiviso da te e i tuoi genitori), oppure una effettiva necessità di molteplici sistemi operativi (linux per passione, e xp per usare dei programmi specifici)
diciamo che in futuro non ci sarà più la scusa "ma non posso usare quel programma perchè non è per il mio OS", visto che per fruirlo basterà far partire l'OS in parallelo, come si facesse partire un eseguibile che crea il suo ambiente di lavoro

Nel tuo esempio sono tutti servizi installabili sullo stesso OS.
Ma se devo usare OS differenti?



Edit: tieni presente che a volte, per alcune esigenze, è meglio avere servizi separati su macchine diverse anche se possono essere installati sullo stesso OS e per alcuni di questi casi la virtualizzazione può anche essere una valida soluzione.

Si ma le risorse? Se un SO blocca una risorsa, come si può sperare che l'altro SO l'abbia disponibile?

Se ho capito bene di cosa si discute, un esempio che mi viene in mente riguarda il mio HTPC (Home Theater PC).

E' difficile e molto oneroso raggiungere un equilibrio di software soddisfacente su un HTPC. Poichè occorre utilizzarlo anche per scaricare software e media da Internet, si pongono due problemi:

- gli antivirus, firewall, etc... sottraggono risorse prestazionali critiche in un HTPC (poi i film scattano);

- c'è il rischio che un virus preso da Internet devasti la configurazione faticosamente raggiunta.

Avendo due macchine virtuali, se queste fossero realmente separate, si risolverebbero i problemi di prestazioni e sicurezza. :cool:

Michele

E' la prima volta che sento parlare di HTPC. Soprattutto di film che scattano con gli antivirus. Ma di che si tratta?

Il problema è che immagino che la ripartizione della RAM debba essere fissa e che comunque ogni VM ha il suo spazio separato: quindi doppia copia del kernel, dei drivers, ecc... Invece con un unico SO è tutto condiviso e quando una applicazione non usa della RAM può essere usata per altro... Invece così hai della RAM perennemente occupata...

Si ma guarda, se per spendere un pò di più in RAM non debbo comprare due macchine separate ne sono ben felice. Ti faccio un esempio: in azienda si usa un noto programma di progettazione PCB su una workstation che è costata dicamo non pochissimo. E chiaramente i files creati con questo programma devono andare archiviati nel nostro gestore PDM, che utilizza come motore database un altro notissimo programma di gestione DB.
Il problema è che questi due programmi proprio non ne vogliono sapere di digerirsi a vicenda, con problemi dell'ordine di:

- crash dell'applicazione
- reinstallazione periodica di una delle due applicazioni

Sarà anche che si tratta di applicazioni scritte in parte coi piedi, ma alla fine siamo noi che dobbiamo utilizzare due macchine, perchè comunque quei programmi costano parecchio.
Ovviamente con due VM che lavorano con due istanze di SO (e con partizioni separate) avrei potuto risparmiare una macchina.

Ok, questo è più sensato... Ma mi pare quando meno scocciante dover mettere una pezza ai sofware mediante dell'hardware (anche se lo si è fatto per l'NX bit e l'NCQ)... Basta cambiare software... Anche se in certi casi (come questo ad esempio) immagino non ci siano alternative... Quindi o così o così... In questo caso si è trovato un uso inteligente, anche se non credo che la virtualizzazione sia stata creata per risolvere questi problemi, ma piuttosoto per condivisione computer e/o per i developer che devono testare su più S.O. : infatti se vai sul sito della MS alla descrizione di VirtualPC, vedrai che il caso tipico è lo sviluppatore che sviluppa per più S.O. (MS ovviamente... ;) ).

Ma infatti non ho mai detto che lo scopo principale sia quello, anzi.
però è un'applicazione che a qualcuno faccia comodo anche quello, così come farebbe comodo una macchina virtuale per la navigazione che rimane "isolata" rispetto al resto del sistema, e viene resettata ad ogni riavvio con conseguente riduzione dei problemi relativi al malware, e così via.
Molti software professionali sono complessi per natura, e magari sviluppati da software houses che non hanno le risorse di altre grandi multinazionali.
Pensiamo poi anche a determinati ambiti di applcazione, non solo al testing software: si potrebbero utilizzare per la progettazione programmi che sono nativi per SO differenti senza dover dedicare delle macchine allo scopo, ad esempio si potrebbero disegnare delle turbine in un CAD che lavora sotto un SO, e poi passare i parametri ad un programma di simulazione di fluidodinamica che lavora sotto un altro SO, sulla stessa macchina, magari in tempo reale.

Capisco benissimo i vantaggi che comportano un'implementazione hardware della virtualizzazione di SO. D'altra parte, invece, non sono convinto di uno dei vantaggi citati per quanto riguarda la virtualizzazione "emulata".

Ad esempio se avessi Win Xp come SO e volessi virtualizzare un'altro Xp dove tengo tutto leggero (niente antivirus, il minimo di applicazioni in background ecc..) per ottimizzare il funzionamento di alcune applicazioni (un gioco ad esempio), in questo caso il primo SO dovrà cmq girare e quindi non avrò miglioramenti se utilizzo il secondo ma sarò pesante almeno quando uso dolo il primo, o sbaglio?

Ad esempio se avessi Win Xp come SO e volessi virtualizzare un'altro Xp dove tengo tutto leggero (niente antivirus, il minimo di applicazioni in background ecc..) per ottimizzare il funzionamento di alcune applicazioni (un gioco ad esempio), in questo caso il primo SO dovrà cmq girare e quindi non avrò miglioramenti se utilizzo il secondo ma sarò pesante almeno quando uso dolo il primo, o sbaglio?

Nella realtà attuale dei fatti, sia VMWare Workstation / Player sia Microsoft Virtual PC rendono migliore un Windows "nativo" ma pesante (antivirus/firewall/installazioni precedenti) che un Windows "emulato" ma leggero. C'è troppo decadimento di prestazioni, a volte i tempi per l'installazione (esempio Fedora Core 4 su VMWare Player) sono più che raddoppiati rispetto all'installare su un PC fisico.

Night82,

sbagli in parte, come tutti gli altri, perche' ti soffermi all'attuale struttura di un OS.

pensa invece ad un OS molto semplice, che occupa ridottissime risorse (anzi, quasi nulle), che gestisce l'ordine di occupazione delle risosrse HW in base alle rischieste effettuate da altri OS, piu' specifici per applicazioni precise, ossia applicazioni che si comportano come sistemi operativi; in pratica OS server e OS client.

per spiegarmi meglio posso rifarmi al tuo esempio:
ho una macchina general porpouse, sulla quale e' installato un supervisorOS, un OS che non ha bisogno nemmeno dell'interfaccia grafica, alla stregua di un piccolo kernell che gestisce il flusso delle richieste tra' HW e SW, dove pero' il SW sono gli altri OS client, piu' o meno come il BIOS e il POST di avvio.
di solito uso questa macchina per lavorare con un word processor, programma che ha gia' di per se un microkernell e dei driver atti a manovrare l'HW, che, quando gira assorbe parecchie delle risorse a disposizione, ma piu' o meno pari alle risorse di un word processor sotto un OS standard (non avendo dietro tutto il corollario di un sistema);
mi vien voglia di giocare?
metto il CD del mio giochetto che avvia da DVD un nuovo OS fatto apposta per l'HW, e il gioco vero e proprio, ne piu' ne meno come avviene per le console (almeno di penultima o terzultima generazione).
il gioco scatta un po'? e' per colpa dell'OS con il word processor che gira sotto; switch sull'altro OS (e questo potrebbe essere uno dei compiti del supervisorOS) e metto l'OS-word processor in sospensione; switch sul gioco e trovo che gira molto meglio, perche' le risosrse sono piu' libere;
a questo punto voglio giocare una partitella in rete con il gioco, ma.. la rete e' pericolosa!
ho bisogno di avere un firewall e altre protezioni per stare in rete, ed in piu' mi servono alcuni server per poterlo fare (anche se gia' potrebbe averli il gioco);
avvio una consolle remota per il supervisorOS e gli dico di avviarmi l'OS-protezione.
Ho un po' meno risorse per il gioco, ma sono protetto.
arriva un'altro utente del PC per lavorarci sopra, ma io sto giocando!
fortunatamente la virtualizzazione consente anche l'uso contemporaneo di periferiche di input, quali tastiera e mouse, ed io, avendo 2 schede video separata sul PC, una per i giochi, e una economica, alle quali sono collegati 2 diversi monitor, malvolentieri, apro una consolle sul supervisorOS e gli dico di avviare il OS-chat utilizzando la seconda scheda video, il mouse "id01" e la scheda video "id01" (io uso quelle con "id00"), e magicamente si avvia l'OS sul secondo monitor, consentendo all'inopportuno utente di chattare con le amiche..

come fare e' abbastanza semplice;
basta avere un OS di base a cui poter montare i moduli e i driver necessari per operare con l'applicazione desiderata, dedicargli uno spazio proprietario sul disco (piu' o meno condiviso) ed installare l'OS-applicazione; il setup dell'installazione creera' un'istallazione OS-applicazione, magari chiedendoci che tipo di avvio deve avere, se ad esempio da periferica ottica virtualizzato totalmente in ram, o su HDD, e su quale spazio.. ne piu' ne meno che come oggi.

il vantaggio:
tu non hai un sistema, ma molteplici sistemi leggeri adibiti ad uno specifico compito, potendo contare sulla totale potenza macchina per un'esclusiva applicazione quando e'necessario;
non hai "impicci" tra' applicazione ed appicazione, o meglio ne hai di meno, perche' le richieste all'HW verranno fatte con la gestione del supervisorOS, bello, snello, e ca...uto, si spera.
e se oggi un driver di periferica, tipo di una scheda video o una scheda audio pesa centinaia di MB sul disco e decine di MB sulla ram, domani potrai scegliere se avere o meno moduli di regolazione dell'overlay o moduli per il caricamento delle librerie EAX per la scheda audio sull'OS-word-processor, cosa che trovo "leggermente" inutile, evitando anche i driver e l'applicazione di controllo di un ultrasofisticato joystick che usi per giocare, potendo scegliere che tipo di driver abilitare sull'OS-applicazione.
Ora puo' sembrare uno spreco caricare tot windowsXP con la matassa di driver con i piu' impensati gingilli che l'appesantiscono su una sola macchina, ma considera che il driver di una periferica, giusto per farla funzionare a dovere, e' costituito da poche librerie di qualche KB, non da infiniti moduli da MB;
guarda i driver di riferimento di XP per alcuni HW, come le schede video; sono di pochi KB, mentre i driver "ufficiali" sono di svariati MB.

...
pensa invece ad un OS molto semplice, che occupa ridottissime risorse (anzi, quasi nulle)
...
ho una macchina general porpouse, sulla quale e' installato un supervisorOS, un OS che non ha bisogno nemmeno dell'interfaccia grafica
...
avvia da DVD un nuovo OS fatto apposta per l'HW
...
avvio una consolle remota per il supervisorOS e gli dico di avviarmi l'OS-protezione
...
la virtualizzazione consente anche l'uso contemporaneo di periferiche di input, quali tastiera e mouse
...


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

@lucusta e tutti
la virtualizzazione di amd e intel è simile a quella di xen, ma realizzata in hardware. Tant'è che xen non è un emulatore!! ma si parla di para-virtualizzazione. Questi processori amd e intel necessitano comunque di un programma supervisore e di un sistema operativo "principale". Al momento xen solo supporta queste tecnologie e ho letto che sono già riusciti a far partire windows come sistema ospite... In pratica xen si basa su un kernel modificato e un "hypervisor" (più dei servizi di supporto). Quello che si ottiene con questi processori è un aumento delle prestazioni sul passaggio da un so all altro e su certe attività e non c'è più bisogno del kernel modificato. Questo hardware è sviluppato a stretto contatto con xen, almeno per ora.

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).

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

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..

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..

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
BuddyPC se non ricordo male il nome, fortunatamente non ha sfondato perché mi sembrava una soluzione davvero "sporca"

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 :p );

- 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 :Prrr: ), 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 :D) 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... :wtf:

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 :rolleyes:
Questo senza parlare dei casini con il manager delle licenze (presente FlexLM?), che per fortuna ho risolto con un file batch eseguito all'avvio...

Originariamente inviato da leoneazzurro
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.

Sospettavo che se ne infischiassero della multiutenza... Non è che tutto si riconduce a quelle librerie? Magari se le sovrascrivono a vicenda e sovrascrivono la chiave in shareddlls (mi pare il minimo per incasinare tutto, poi sta a vedere quali altre chiavi si fregano a vicenda... ma sono così simili sti programmi?). In generale penso che un po' di problemi relativi al registro si potrebbero risolvere se i programmi non potessero scrivere dove gli pare, ma venissero create delle tabelle e delle chiavi per legare ogni altra chiave all'applicazione che l'ha creata e la usa: si eviterebbero un po' di conflitti, si eviterebbe di lasciare immondizia nel registro dopo una disintallazione (ma questo credo che non piacerebbe a chi usa questo meccanismo per impedirti di reinstallare una versione a tempo), forse sarebbe più facile caricare in memoria solo le parti che servono, quando servono (per le librerie condivise sarebbe un po' più complicato, ma qualcosa si potrebbe fare).


Questo senza parlare dei casini con il manager delle licenze (presente FlexLM?)

Si, ho presente la bestiola... un miliardo di file per gestire una licenza a chiave hw (efficacissima...). Ma ve l'hanno fatta registrare online, oppure la vostra versione usa un altro meccanismo (non per farmi gli affari della tua azienda, eh! )? Immagino lo usi il cad (lo dico perchè ne conoscono uno per progettare e programmare circuiti che usa proprio FlexLM, se non ricordo male lavora su roba tipo pal, pla, rom varie e device con funzionalità di "base" da "assemblare" e integrare su vasta scala - magari e lo stesso). Sarebbe il colmo se lo usassero entrambi e la causa di tutto fosse proprio la protezione...

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)

non tanto..
l'idea e' di avere un OS capace di.. trasformismo... (non ho trovato un termine migliore, scusami).

come scrivi nel'ultimo pezzo:
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.
e' piu' o meno questa la mia visione..

non scordiamoci che sicuramente non e' e non sara' gradito l'uso di altri tipi di OS da parte delle software house, forse tollerato, ma sinceramente credo che se avessero voluto una cosa in tal senso, ad esempio, il bootloader di winXP sarebbe stato ben diverso.
percio' e' piu' ipotizzabile uno scenario dove c'e' un supervisorOS di marca XYZ che "aiuta" l'istalazione di un OS-applicazione, dove gli OS in oggetto sono la copia di se stessi di marca XYZ, depauperati dell'inutile.
in uno scenario del genere ecco che nel momento dell'istallazione di una generica applicazione, o tipo di applicazione (si potrebbe ricorrere a divisioni di marketing, categorizzando le applicazioni in base all'uso, tipo: office, game, image-processor ecc.., visto che se te ne serve un tipo probabilmente ne servira' anche un'altra dello stesso tipo che coadiuva il lavoro, es word-excel, o excel-access.. le classiche suite.. ora riprendo il filo del discorso...), all'istallazione viene richiamato il setup del OS, dove ci sara' una sorta di wizard che rendera' l'utente in grado di scegliere che caratteristiche dovra' avere l'OS adibito all'applicazione; wizard che potrebbe essere guidato in parte dallo stesso creatore dell'applicazione tramite un .ini, in pratica: per funzionare mi serve questo, questo, e quest'altro, a te la scelta se lo vuoi piu' elaborato o meno.
In questo scenario, effettivamente, si potrebbe assimilare il concetto di OS a microkernel che coopera con server-moduli (i migliori OS, anche se bisogna essere altro che power user per ora), ma sostanzialmente e' differente, perche' effettivamente gia' oggi, in un "tipico" OS, se viene richiesto un servizio da diverse applicazioni, questo potrebbe essere comunque ricaricato come nuova copia nella ram, separandone le istanze dal precedente, ed anche se usano le stesse librerie, queste potrebbero essere richieste replicate e distinte, se caricate in ram (alla faccia della condivisione delle dll!).
quindi, e' preferibile separare anche, come dovrebbe avvenire, la ram... ma allora perche' ci sono tutti questi bufferoverflow? ci sono troppi bug?
e si, rendiamoci conto che il codice, per quanto curato possa essere, ha sempre errori, e che anche se in virtualizzazione si separano gli ambienti di lavoro, nessuno promette che l'applicazione non possa andare in crash, ma ci va' d sola, senza intralciare il lavoro delle altre macchine virtuali!

veniamo alla quetione dei driver:
oggi ho un PC con 5 schede di rete, tutte uguali, tutte su PCI; grazie all'emulazione degli IRQ siamo sicuri che funzioneranno tutte superando la numerazione di sole 16 periferiche degli obsoleti PC.
hanno indirizzi virtuali diversi, ed e' questo che le fa' funzionare, gestiti dal driver IRQ streaming.
hanno pero lo stesso driver caricato e replicato 5 volte; infatti nei registri si fa' riferimento al loro indirizzo virtuale, ed ognuna puo' avere la propria configurazione personalizzata; logicamente, a livello superiore, si appoggiano sui driver di rete, o meglio sui protocolli, uguali per tutte, ma anche questi con istanze separate, ossia, durante l'uso di uno di questi, viene ricaricato il protocollo (non tutte le librerie, d'accoro); c'e comunque da dire che una sorta di servizzi base del supervisorOS sarebbe auspicabile.
non vedo molta differenza nel caricare piu' driver virtuali su diversi OS-client che fanno uso dello stesso HW, controllati da un piu' evoluto IRQ streaming.
D'altronde, gia' in VMware si fa' uso di ethernet AMD 10/100 emulata sulle varie macchine emulate, per creare una NET virtuale, e questa volta gli oggetti sono virtuali, e non emulati; oltretutto, sempre per il discorso "comunicazione intermacchina", gia' oggi, con 2 ethernet integrate, una IEEE1394 ed un modem, winXP chiede gia' di per se se si vuole condividere tutte le connessioni; e quello non e' un router e un gateway emulato?

in pratica la difficolta' e' essenzialmente dei produttori di HW per proporre driver per specifice categorie, o di produrre driver modulari.
si, lo so', e' gia' difficile che facciano un driver decente, chiedegliene 5 o 6.. li farebbero con i piedi :rolleyes:
pero', quando uscirono le API (che altro non sono che driver virtuali), tutti si adeguarono, fossero glide o directX, se volevano vendere quelle erano e il loro HW e SW doveva corrispondere a quei requisiti.

il fatto della pesantezza di piu' OS-applicazione + supervisorOS e' pressante, ma oggi, non scordiamoci che l'anno prossimo si va' sui quad e i 2GB di ram saranno la norma.

Perche' complicarsi la vita cosi', quando un multitasking/multiutenza potrebbe bastare?

bhe', forse per semplice evoluzione..
gia' da diverso tempo ho preferito separare i compiti a diverse macchine piuttosto che avere una supermacchina ultra oveclockata capace di tutto; questo perche' pur utilizzando OS multitasking/multiutenza, alcuni lavori richiedono macchine a se per essere eseguiti senza intralcio, o la sicurezza di certi ambienti d'evessere protetta da altri, o la semplicita' di alcuni compiti potevano essere assolte da macchine piu' piccole, silenziose e "leggere".
In quest'ottica mi sono abituato ad usare le varie macchine da istanze remote, in desktop remoto (ecco perche mi piaceva tanto il TS), o da semplice consol terminal.
Ad esempio ho un PC adibito alla navigazione, che prende i vari "preferiti" dal serverino, e mi consente di spostarmi in rete senza preoccuparmi di alcun pericolo, e all'occorrenza uso una ghost per ripristinare il tutto (addirittura prima utilizzavo un caricamento sulla ram e senza disco!), leggero, e su una macchina paurosamente lenta per oggi, un P2, ma adeguata al compito;
per l'home-banking e altre operazioni in ambiente controlato e sicuro ho un PC blindato, anche questo un semplice P2, ho un client di posta ordinaria sul primo e un client di posta "seria" sul secondo, ed opero da finestra dal desktop "un-po'-per-tutto".
ho un HTPC, leggero e dinamico (quasi...), e gestisco il serverino 24/24-365.
sul PC "un-po'-pe-tutto" posso volendo giocare, navigare, fare home-banking, scaricare, rippare, lavorare... tutto, ma in maggior parte lavorano altri PC avviati all'occorrenza.. crasha il PC "un-po'-per-tutto" (un vero puxxanaio, ultimamente)? riavvio, riapro l'istanza del desktop remoto e mi rimetto a fare quello che facevo..
il 90% di questi compiti lo potrebbe fare una sola macchina media odierna, ma solo se virtualizzata, mantenendo la stessa sicurezza e flessibilita' operativa (tranne per i lavori gravosi, ovvio).
in piu', sul server, potrei abilitare sessioni remote per qualsiasi utente, crossover o in qualsiasi altra modalita';
Ma se una macchina odierna potrebbe farlo, allora, perche' non fare un VERO server casalingo "un-po'-per-tutto" a cui si collegano semplici "gadget"?
la Xbox360 puo' comunicare con un server WMP e diventare uno pseudo HTPC... ok, ma non usa HW del server, usa IL server, come faccio ora io con il TS.
una periferica PCI-ex potrebbe essere usata da un altro PC (..fantasia che circolava qualche anno fa'), ma se questo e' un "gadget" che apre un'istanza sul server virtuale e abilita all'uso di una mega scheda grafica che accellera, compatta e rimanda al "gadget", il quale spara sul TV da 60"? mi stufo, vado in camera, apro un'altro "gadget" e virtualizzo da li?
1 sceda grafica, 1 server, 2 gadget distinti, steso risultato: fruibilita' e flessibilita'.

insomma, si, e' complicato, ma e' l'evoluzione dell'informatica, della domotica, di un nuovo tipo di bit-generation, quella che vive con l'informatica spalmata addosso (ed avvolte anche dentro di se, tipo i chip RFF), non certo dalla nostra bit-geneation, una generazione informatica di primo pelo, dove ci gasiamo nel riuscire a far funzionare un PC..

ok... ho degenerato dal discorso, e come al solito mi sono perso in altri..
che stavamo dicendo? :what:

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..

sono driver base per VGA, con accellerazione semplice in 2D e nessuna in 3D; tutti i prodotti "certificati" devono supportare tali caratteristiche; un po' come l'audio AC'97 (designazione INTEL), dove le schede audio devono poter supportare un driver generico SB16bit.
diciamo che prima, sulla scatola dell'HW,se trovavi il marchietto "engenering for WIN", e significava che supportava i driver generici di win (per winXP il video e' 800x600).
come vedi, loro danno le guide, e i produttori si devono adeguare;
questo e' sia un bene che un male del "monopolio" e della standardizzazione.

quello che dici sul fatto che i produttori hanno riluttanza a customizzare i loro driver e' un discorso ASSOLUTO, ma qui non stiamo parlando dei driver di Ati per supportare linux, ma di interesi economici alquanto marcati.