Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
forse ha usato la parola sbagliata. Penso che intendesse dire "i radicali" o qualche cosa del genere. ciao MaX On 26/08/2017, andrea biancalanawrote: > il giorno Fri, 25 Aug 2017 18:15:18 + "Lorenzo \"Palinuro\" Faletra" > ha scritto: > >> [...] (mi correggano i nazi) [...] > > ma che significa?! > > Rimango stupito > > -- ciao, MaX
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
il giorno Fri, 25 Aug 2017 18:15:18 + "Lorenzo \"Palinuro\" Faletra"ha scritto: > [...] (mi correggano i nazi) [...] ma che significa?! Rimango stupito
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
ciao, personalmente per "virtualizzare senza emulazio e hardware" (i debian nazi mi concedano il termine) in ambito server amo usare lxc, che consente di sfruttare una feature del kernel che gli consente di gestire in maniera isolata piu user spaces lxc nello specifico serve proprio a dare un risultato simile alla virtualizzazione (mi si conceda nuovamente la bestemmia) dando come risultato u host con varie VPS a bordo, quindi per intenderci è un po come una bella copia del vecchio openvz altra soluzione è usare il buon vecchio chroot che (mi correggano i nazi) dovrebbe effettuare un isolamento di un environment dentro l'userspace corrente la vera questione in questi casi è che tipo di risorse offrire dentro un container: per intenderci dentro una chroot classica per sviluppo o test si usa fare un bind mount dei vari /dev, /proc, /sys e /run che saranno quindi uguali tra i 2 ambienti che vedranno e condivideranno gli stessi processi e le stesse periferiche un sistema come lxc invece isola il tutto e offre devices virtuali dedicati ad ogni "box" comunque una soluzione simil-chroot nativa di debian e usata dal sistema di build di debian stessa è schroot, che ti permette di gestire piu chroots con relativi overlay e snapshots automatizzando anche il processo di mount e start dell'ambiente feature molto carina di schroot è che di default ti permette di rendere temporanee le modifiche ad una box copiandola dal template originale ed eseguendo tutte le operazioni in scrittura su uno snapshot che viene cancellato a fine utilizzo, quindi in un ambiente di build ti consentirebbe di partire sempre da un ambiente vergine e riproducibile, o in alternativa puoi accedere direttamente ai templates per rendere le modifiche permanenti docker è un'altra soluzione carina e alternativa a lxc che però personalmente non userei mai in produzione solitamente docker lo si utilizza per applicativi ruby, poichè ruby ha il problema esageratamente grave di non riuscire a lavorare con versioni non corrette dellr varie gems, quindi o si lavora di containers "precotti" o si lavora di virtualenv alla maniera di python (come avviene ad esempio con gitlab omnibus) ma per i dettagli tecnici su docker passo la palla ad altri, io resto un cane da lxc e schroot/sbuild p.s. il bello di schroot è che è molto facile gesrire box di altre architetture, come ad esempio armhf, arn64, mipsel o ppc64el Il 25 agosto 2017 18:54:57 CEST, maxlinux duemilaha scritto: >a radice dell'altro tread, mi stavo chiedendo se qualcuno ha provato >in debian, dock o altri sistemi simili, per avere spazi di emulazione >del SO, ma senza emulare anche l'hardware. > >A quanto ho capito, dock o simili, creano una specie di chroot in cui >riscono a fare correre un qualsiasi sistema operativo basato in >linux,gli assegnano una percentale di cpu, uno spazio di ram e disco, >ma l'hardware non viene emulato, per cui l'emulazione corre alla >stessa velocità del sistema principale host. >Tra l'altro usando varie macchine con lo stesso sistema operativo, >queste compartono tutti i files dei binari (deve essere qualche cosa >tipo hard-links) e la macchina viene creata con un semplice script, in >modo da poterla creare a distruggere a seconda delle esigenze > >qualcuno ha esperienze a riguardo? > >saluti, >MaX -- Lorenzo "Palinuro" Faletra Parrot Security GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4 GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4 GPG Key: http://pgp.mit.edu/pks/lookup?op=get=0x97CAA129F4C6B9A4
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
Si sono d'accordo all'utilizzo di qemu / kvm (lo uso pesantemente da anni). Ma qui la domanda riguardava container. Sono una cosa diversa rispetto ad una VM ed hanno pro e contro rispetto a questa seconda soluzione. Poi, per il mio modo di lavorare uso esclusivamente VM pure in qemu / kvm. Ma questo è un altro discorso. Luca Il giorno 26 ago 2017, 12:00, alle ore 12:00, gerlosha scritto: >Il 25/08/2017 18:54, maxlinux duemila ha scritto: >> a radice dell'altro tread, mi stavo chiedendo se qualcuno ha provato >> in debian, dock o altri sistemi simili, per avere spazi di emulazione >> del SO, ma senza emulare anche l'hardware. > >Arrivo un po' "tardi" nella conversazione, scusatemi se ripeto quanto >potrebbe essere già stato detto da altri... > >Prima di mettere mano a contenitori e quant'altro, come "alternativa" a > >Virtualbox io suggerirei la piattaforma di virtualizzazione nativa di >Linux, QEMU+KVM: >https://wiki.debian.org/KVM > >Le prestazioni sono migliori di VirtualBox, ed usando l'interfaccia >grafica virt-manager non è poi più difficile da usare rispetto a >VirtualBox (anzi...). > >saluti, >gerlos
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
Il 25/08/2017 18:54, maxlinux duemila ha scritto: a radice dell'altro tread, mi stavo chiedendo se qualcuno ha provato in debian, dock o altri sistemi simili, per avere spazi di emulazione del SO, ma senza emulare anche l'hardware. Arrivo un po' "tardi" nella conversazione, scusatemi se ripeto quanto potrebbe essere già stato detto da altri... Prima di mettere mano a contenitori e quant'altro, come "alternativa" a Virtualbox io suggerirei la piattaforma di virtualizzazione nativa di Linux, QEMU+KVM: https://wiki.debian.org/KVM Le prestazioni sono migliori di VirtualBox, ed usando l'interfaccia grafica virt-manager non è poi più difficile da usare rispetto a VirtualBox (anzi...). saluti, gerlos
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
Si, uso anche molto BSD :) Il giorno 25 ago 2017, 21:26, alle ore 21:26, maxlinux duemilaha scritto: >On 25/08/2017, Luca De Andreis wrote: >> Si, ti rispondo con tre lettere : LXC. >> >> (però lo usi solo per Linux...) > >perché?... esistono altri S.O.? :)
Re: Altenative a macchine virtuali - Era: Re: Far funzionare virtualbox (testing) con Linux 4.12.0-1
On 25/08/2017 19:54, Luca De Andreis wrote: Si, ti rispondo con tre lettere : LXC. io ho iniziato a guardarlo in mese scorso, però in sintesi: * è un docker[1] e non una virtualizzazione di una macchina * non è presente in Debian LXD per problemi di dipendenze[2] * non è semplice, nel senso che non è come virtualbox che schiacci due bottoni, installi e hai la macchina pronta per l'uso. Devi sapere bene cosa stai facendo e cosa vuoi configurare, i permessi che vuoi dare, ... * avere un ambiente grafico eseguito in LXC non è semplice, non è sufficiente avviarlo e hai la tua macchina... puoi farlo, ma devi fare passi ulteriori (però lo usi solo per Linux...) io lo uso solo per creare altre macchine Debian sia a casa che al lavoro. Ciao Davide [1] https://linuxcontainers.org/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073 https://wiki.debian.org/LXD -- Dizionari: http://linguistico.sourceforge.net/wiki Motivi per non comprare/usare ms-windows7: http://windows7sins.org/ Non autorizzo la memorizzazione del mio indirizzo su outlook