Se avete mi utilizzato macchine Linux su sistemi vmware, quello che sto per descrivervi probabilmente non vi suonerà nuovo.
Come sappiamo, all’avvio di una VM (non del sistema operativo ospitato), così come in seguito a cloning, oppure vmotion, o altre operazioni, può capitare che vmware cambi il MAC Address delle schede di rete di una virtual machine. In windows questo non è mai stato un problema, ma sui sistemi linux decisamente si, o almeno sui CentOS coi quali lavoro solitamente io.
Cosa succede?
Fate questa prova: innanzitutto date il comando lspci, e vi accorgerete che la scheda di rete è perfettamente visibile dal sistema. Peccato che ifconfig -a vi restituisca solo l’interfaccia lo (loopback). Dove è finita eth0???E’ sempre al suo posto, ma siccome il mac address è stato modificato, durante il boot kudzu (il gestore del plug & play) vede una nuova scheda di rete, e udev confronta il mac address che trova nel bus pci con quello che ha memorizzato. Peccato che i due valori non coincidano più, e il sistema vi dica che non riesce ad attivare eth0. Invocando ifconfig -a| grep HW otterremo infatti un output simile a questo:
eth0 Link encap:Ethernet HWaddr 00:0C:29:C4:0A:F2
eth1 Link encap:Ethernet HWaddr 00:0C:29:C4:0A:FC
(Nel mio caso le schede di rete sono due, quindi i problemi sono anche peggiori con inversioni tra eth0 e eth1, nascita improvvisa di eth2). Se invece leggiamo il file /etc/sysconfig/network-scripts/ifcfg-eth0 potremmo ritrovarci con il valore HWaddr “vecchio”. Questo file infatti, come suggerisce il nome della cartella che lo contiene, è lo script che viene invocato al boot e configura eth0 con i parametri contenuti. Ma trovando un mac address diverso lo script fallisce.
Come rimediare?
Ci sono tre soluzioni bovine e una elegante.
Bovina 1: editiamo i parametri della virtual machine in vmware e invece di lasciare il mac address dinamico lo forziamo in modo statico. Il contro è ovviamente che un cloning della VM o un suo spostamento tramite converter non ci impedirà di perdere il mac address stesso.
Bovina 2: editiamo il file indicato prima e immettiamo il nuovo valore mac address. Ovviamente ad ogni reboot rischiamo di dover reimmettere il nuovo mac address. Inoltre se stiamo operando in remoto sul server, rischiamo di tagliarci fuori e doverci recare localmente sul sistema per ripristinare la connettività di rete.
Bovina 3: quello che udev fa è memorizzarsi i mac address delle schede di rete per far sì che ad ogni boot ad un dato mac address venga sempre assegnato lo stesso nome. Per fare ciò, memorizza questi parametri nel file /etc/udev/rules.d/70-persistent-net.rules. Ho trovato molti articoli in internet che suggeriscono di cancellare questo file in modo che udev possa ricreare i puntatori sui nuovi mac address. Sinceramente mi fa ancora più ribrezzo della bovina 2.
Elegante: ovviamente vorremmo un sistema che legge i nuovi mac address, ed aggiorna di conseguenza il file di udev, che a sua volta aggiorna gli script di avvio. Per fare ciò ci procuriamo innanzitutto gli indirizzi del bus pci della o delle nostre schede di rete tramite il comando ethtool -i eth0:
driver: vmxnet
version: 0.9.0.1
firmware-version: N/A
bus-info: 0000:00:11.0
Annotiamoci il valore di bus-info. Questo infatti fintanto che non variamo l’hardware della virtual machine rimarrà sempre fisso. Prendiamo adesso il file 70-persistent-net.rules. normalmente ci troviamo scritto stringe simili a questa:
SUBSYSTEM==”net”, DRIVERS==”?*”, ATTR{address}==”11:22:33:44:55:66″, NAME=”eth0″
Modificheremo la riga in modo che contenga:
SUBSYSTEM==”net”, DRIVERS==”?*”,ID=”0000:00:11.0″, NAME=”eth0″
D’ora in poi udev userà come discriminante il bus-ID e non più il mac address.