Newsgroup: it.comp.os.linux.sys
Titolo: Virtualizzare macchine gia' in produzione

Per questioni molto spiacevoli mi ritrovo con 3/4 macchine linux fisiche 
attualmente in produzione da virtualizzare.
Un paio sono Slack ed un paio sono Debian il problema e' che il Converter mi 
dice che non ne riconosce nessuna, puo' dipendere dal kernel ricompilato ?
Come potrei fare in questi casi per non doverle rifare da capo ?
Inoltre, anche se riuscissi a virtualizzarle poi riuscirebbero a fare boot in 
virtuale sempre considerando che hanno un kernel "hardennizzato" ?
Grazie
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra facile a 
prima vista...ma la veritï¿œ ï¿œ che non avere nulla da perdere significa essere 
pronti a rischiare tutto ciï¿œ che si possiede.

 virtuale sempre considerando che hanno un kernel "hardennizzato" ?
Credo che sia fortemente dipendente dall'ambiente in cui le
virtualizzi e
dalla modalita` (virtualizzazione/paravirtualizzazione?).
Secondo me ti funzionano. Sicuramente se l'ambiente e` OpenVZ,
probabilmente
in altri casi.
Comunque fossi in te cercherei di approfondire un po' perche' il
Converter (di non
sappiamo cosa) non funziona. Se pero` non ci dici qual e`,
difficilmente si puo`
aiutare.
Andrea

 virtuale sempre considerando che hanno un kernel "hardennizzato" ?
Dipende da quanto hai pasticciato il kernel. Sono sempre piï¿œ convinto che 
compilarsi il kernel nel 99% dei casi sia andare a mettere il culo nelle pedate.
Oggigiorno lo compilo solo in rarissimi casi ove sia realmente 
giustificabile l'immensa perdita di tempo ed il maggiore onere di gestione.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 difficilmente si puo` aiutare.
Giustamente... essendo supportata Ubuntu dal converter pensavo che almeno le 
Debian se le pappasse ma invece nisba. E' che non capisco perche', non ho 
trovato il modo di fargli loggare nulla.
Cmq alla fine credo che seguiro' la strada della copia alla vecchia maniera 
(rsync come dici tu o simili).
Grazie
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra facile a 
prima vista...ma la verit� � che non avere nulla da perdere significa essere 
pronti a rischiare tutto ci� che si possiede.

 nelle pedate.
 > Oggigiorno lo compilo solo in rarissimi casi ove sia realmente
 > giustificabile l'immensa perdita di tempo ed il maggiore onere di gestione.
Il kernel non e' pasticciato ma ricompilato ;) e come avrai intuito non sono 
molto d'accordo con te su questa tesi ma sono fortemente allergico alle 
polemiche percio' puntualizzo solo che e' ricompilato ad hoc e resto in pace :)
Grazie delle info


 gestione.
Io con lenny *devo* compilarmi il kernel, causa altissime quantità di 
ciofeche ivi inserite.
Ovviamente lo faccio "the debian way", confezionandomi i vari linux-image, -
headers, -source etccc...
Mai avuto problemi, anzi, mi è tornato pure comodo per installare nuove 
macchine che non ne volevano di partire con i kernel dell'installer di lenny 
e testing.
Max
 

 boot in virtuale sempre considerando che hanno un kernel "hardennizzato" ?
Questo purtroppo non lo si puo' sapere in anticipo, occorre provare.
--
Bye
Gianfranco Bartolini

 
http://conshell.net/wiki/index.php/Linux_P2V
Grazie mille del link, ora me lo leggo bene.
Tengo presente anche l'osservazione sul controller LSILogic anche se temo che il 
problema possa non essere legato solo al controller. Cmq provo poi posto 
l'eventuale risultato positivo.


 provo poi posto l'eventuale risultato positivo.
VMware emula hardware molto standard (controller buslogic o lsilogic, 
schede di rete amd pcnet o intel pro1000, chipset 82443BX, ecc.) per cui 
come compatibilita' hardware non ci dovrebbero essere problemi, a meno 
di "magie" strane nel ricompilare il kernel.
-- 
Bye
Gianfranco Bartolini
(gianfranco punto bartolini at tiscali punto it)

 Ok, insomma non ci sono altri sistemi oltre alla copia, grazie mille.
Hai provato a fare una immagine della macchina con Acronis true image 
(9.1) e poi virtualizzare partendo da quella? So che dalla versione 
3.0.x (non ricordo quale di preciso) il virtualizzatore supporta anche 
le immagini acronis.
Oppure prova creando una VM vuota e ripristinandoci dentro l'immagine di 
acronis.
-- 
GenTLe ...di Varese, provincia.
La mia HP: 
http://digilander.iol.it/thegentle/index.htm
La vita è fatta anche di ardue scelte, tipo: "Un cuba... O una birra 
media???"

 acronis.
Ho provato con il ghost ed il problema principale e' stato il kernel panic 
all'avvio, non i driver dei device installati nel kernel, pero' una prova con 
TrueImage la faccio....
Grazie


 di "magie" strane nel ricompilare il kernel.
Magie direi di no, piu' che altro faccio pulizia solitamente, comunque ora provo 
a ricompilare inserendo qualche driver standard poi vediamo.


 ciofeche ivi inserite.
tanto per la cronaca, in genere cosa togli e cosa lasci?
andrea

 tanto per la cronaca, in genere cosa togli e cosa lasci?
Tolgo nulla.
Lascio tutto.
(uso i vanilla e di solito aggiungo la patch linux-vserver, usando il 
.config di debian).
Nel 2009 non ha senso fare kernel troppo customizzati a meno di non usare 
roba embedded.
Max

 ora provo a ricompilare inserendo qualche driver standard poi vediamo.
Scusa, ma i kernel odierni sono in grandissima parte modulari: se 
qualcosa non serve, non la caricano. A che ti serve fare "pulizia"?


 roba embedded.
condivido, tanto piu' che con le capability posso chiudere la porta a certe
funzioni che di solito mi avrebbero portata a ricompilare (es, impedire il
caricamento di moduli extra a server gia' a runlevel 'di esercizio')
pero' scusami, ma il senso della mia domanda era capire il motivo per cui tu
ricompili il kernel lasciando perdere quello della distribuzione e, in
generale, quali sono le differenze *abituali* tra il tuo e quello debian;
poi e' chiaro che ogni sistema ha i suoi requisiti e quindi il suo kernel
personalizzato, ma volevo tenermi su un approccio generale alla questione.
Andrea
(che non vuole smettere di lavorare ... pero' nel ced fa cosi'
fresco :) .... )

 qualcosa non serve, non la caricano. A che ti serve fare "pulizia"?
Sui server esposti (dmz o outside) la prima cosa che tolgo in assoluto e' 
proprio il supporto per i moduli.
Per il resto con "faccio pulizia" intendo che tolgo tutto cio' che la macchina 
non ha (driver, etc) o di cui non ha bisogno e ottimizzo tutto quello che posso 
per il mestiere che deve fare la macchina (perche' voglio che le mie macchine 
non siano dei jolly da giocare in sala server alla bisogna ma vengano prese per 
quel mestiere e facciano quello)


 generale, quali sono le differenze *abituali* tra il tuo e quello debian;
Come ho accennato altre volte:
1) soprattutto perchè il kernel di lenny fa cagare con KVM e crasha che è 
una bellezza sotto carico
2) ora aggiungo: perchè lenny su alcuni nuovi server che ho non funziona e 
ho bisogno di kernel più aggiornati.
Max

 proprio il supporto per i moduli.
ah perchè se ti bucano almeno non caricano altri moduli. 
Giusto.
In effetti se non caricano i moduli per la scheda audio almeno non possono 
sentire gli MP3.
Max

 sentire gli MP3.
Apprezzo che tu mi abbia detto la tua opinione in merito... grazie.
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra facile a 
prima vista...ma la verità è che non avere nulla da perdere significa essere 
pronti a rischiare tutto ciò che si possiede.

 e' proprio il supporto per i moduli.
Tempo fa anche io facevo cosï¿œ.
Poi ho scoperto che era solo una grandissima rottura di coglioni
nel caso si debba fare manutenzione urgente.
Metti che ti si rompa un server. Puoi tamponare in un secondo spostando
i dischi dalla macchina morta ad un muletto. Se non hai tutti i moduli
necessari per l'hardware sulla macchina nuova devi perdere del tempo
a ricompilare questo, ricompilare quest'altro, testare che tutto
funzioni etc etc etc etc...
No grazie, preferisco dormire la notte.

 proprio il supporto per i moduli.
Pratica assolutamente inutile al giorno d'oggi.
Se uno ha i diritti di caricare i moduli allora ï¿œ root, e se ï¿œ root allora 
anche se manca il supporto ai moduli nel kernel non interessa perchï¿œ puï¿œ 
accedere a kmem e patchare il kernel direttamente.
google => kernel patching kmem
La pratica di disabilitare il supporto LKM oggi ha senso solo per sistemi 
embedded (o molto particolari) in cui serve risparmiare spazio, ma non 
aggiunge nulla alla sicurezza dei sistemi contrariamente a quanto molti sono 
portati a pensare.


 google => kernel patching kmem
interessante.
Ciao Jack

 molti sono portati a pensare.
Per quanto mi riguarda non mi serve a nulla averlo percio' lo tolgo. Se mi 
dovesse servire sul momento, per rispondere anche a Peregrino, lo rimetto; 
lavorando su un kernel "pulito" ci metti 2 secondi ad aggiungere una X e 
ricompilare.


 aggiungere una X e ricompilare.
Certo, si, 2 minuti.
Compila un kernel bello pesante su un sistema embedded con magari 16mb
o 32mb di ram poi vediamo se
a) hai abbastanza spazio disco per ricompilare
b) hai abbastanza spazio per tenenrti tutti i tools necessari
a ricompilare
c) hai abbastanza tempo (su una VIA EPIA 1000 impieghi tipo 20 minuti
buoni buoni e lo so perchï¿œ ho ricompilato piï¿œ volte kernel su delle epia
1000)
d) sprechi inutilmente delle scritture su CF (se sei embedded ï¿œ
difficile che tu abbia un hdd)
e) varie ed eventuali.
Discorso diverso se compili su una macchina esterna, ma in tal caso come
giustifichi il dover utilizzare due macchine per fare il lavoro di una?
Io preferisco spostare i dischi in toto da un server A ad un server B
e non pensarci piï¿œ. Ho ricompilato per anni (da buon utilizzatore di
Slackware) kernel vanilla partendo dal .config della distro, mi sono
letteralmente stracciato i maroni [francesismo] di perdere ogni volta
mezzora per dei moduli mancanti, figuriamoci in caso di problemi con
40 persone che ti stan con il fiato sul collo a chiederti "Quanto 
manca?" e te devi dirgli: sto ancora ricompilando il kernel per poter
cambiare il server.

 una bellezza sotto carico
Questo e` interessante, ho giust'appunto una macchina con due guest KVM
che sembra avere problemi di rete in alcune ore del giorno. Sai darmi
piu` informazioni?
Enrico

 cambiare il server.
Forse farebbe bene anche a te un po' di vacanza ;-)
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 Forse farebbe bene anche a te un po' di vacanza ;-)
Confermo.....


 cambiare il server.
Probabilmente lavoriamo in due realta' molto (molto molto molto) differenti.
Ciao


 piu` informazioni?
Non sono problemi di rete.
Se guardi il DMESG dell'host, vedrai qualcosa tipo: "CPU #1 Stuck for 30 
seconds" o simili.
Ho provato di tutto e alla fine l'unica cosa funzionante era: upgrada il 
kernel.
Max

 una bellezza sotto carico
]zac[
A me sembra invece che il problema sia dovuto al fatto che kvm è fortemente
in sviluppo e non raramente ne ribaltano il codice introducendo migliorie
ma anche frequenti malfunzionamenti.
In sintesi è kvm che 'costringe' all'uso di kernel recenti.

 In sintesi è kvm che 'costringe' all'uso di kernel recenti.
In generale potresti aver ragione (pure se non ho mai avuto nessun problema 
se non con il 2.6.26 di debian, e li ho provati tutti, dal .27 al .30).
In particolare, per un kernel debian, fare schifo non è normale.
Max

CtRiX wrote:

Forse la cosa è dovuta al fatto che in debian sono più prudenti in quello
che mettono dentro il kernel, i problemi di mancato boot di win vista che
io ho avuto li ho avuti con i sorgenti ufficiali del kernel, con un vecchio
kernel/kvm il boot si bloccava subito, poi nelle versioni successive e
recenti del kernel il boot è andato più avanti, e poi funzionava tutto, in
una versione successiva ha ricominciato a bloccarsi subito il boot.
Alla fine ho rinunciato, ho installato virtualbox, finiti i problemi al
boot.
P.S. Mi ricorda molto wine, cosa e come funzionava dipendeva dalla versione
di wine.

 seconds" o simili.
Mmm... ho appena controllato[1], ma non ho alcun messaggio del genere.
Tra l'altro, e` l'unica macchina che mi da problemi simili...
Enrico
[1] c@%%0, sono in ferie!!! :/

 Certo, si, 2 minuti.
[cut]
cross-compiling questo sconosciuto....
ilSimo
-- 
now playing: 
Marching soldiers of death, so proud to fight and to die
We will win in the end, and we will conquer this land
Marching soldiers of death, ready to fight and to die
                                Drakkar - Soldiers Of Death

 cross-compiling questo sconosciuto....
Che non risolve il problema della tempistica...
Enrico
P.S. massimo rispetto per voi che nel 2009 ancora compilate il kernel
per i piu` disparati motivi, ma non dimenticate che li fuori c'e` anche
gente che ha delle scadenze da rispettare

 Giusto
L'importante è crederci. :-)

 ho bisogno di kernel pi� aggiornati.
ok. ma permettimi una domanda:
se non dovessi usare KVM oppure non ti servisse supporto HW aggiornato,
ricompileresti il kernel distribuito?
cioe', quello che ti chiedevo io era piu' o meno cosi': "In assenza di una
necessita' effettiva e bloccante per il servizio (instabilita' di sistema,
mancanza supporto HW, mancanza di una specifica funzionalita' necessaria)
ricompileresti il kernel al posto di utilizzare quello distribuito? e, se
si, per quale motivo/policy (es. bloccare il load dei moduli, ecc) ??"
ecco forse ora mi son spiegata bene; intendiamoci, condivido tutto quello
che hai detto e probabilmente farei anch'io cio' che fai tu se fossi al tuo
posto, ma come dicevo mi interessa il tuo parere sul caso generale.
ciao
 Andrea

 ricompileresti il kernel distribuito?
Secondo me non ha senso.
Max