Geen netwerkverbinding na het klonen van Linux VM
Gepubliceerd op 27 oktober 2015 • 5 min leestijd • 928 woordenEen van de eerste dingen die ik deed, was inloggen op de server vanaf de console en controleren of, en welke, netwerkinterfaces werden gedetecteerd. Toen ik ‘ifconfig’ uitvoerde, merkte ik dat ik alleen een loopback-apparaat (lo) had, maar geen andere netwerkapparaten (eth0 of iets dergelijks). Hoe komt dat?
Het probleem was niet dat ik geen netwerkverbinding had, maar de verkeerde netwerkverbinding. Op de een of andere manier creëerde de Linux-apparaatbeheerder udev meer netwerkinterfaces dan de VM had. Om te begrijpen wat er gebeurde, moest ik weten wat er bij het proces betrokken was.
Kennisbankartikel 2002767 beschrijft de symptomen als:
- De netwerkconfiguratie in het Linux Guest-besturingssysteem verwijst nog steeds naar de originele MAC-adressen.
- Mismatch tussen de MAC-adressen in de instellingen van de virtuele machine en het Linux-besturingssysteem.
- Netwerken werkt niet in een gekloonde virtuele Linux-machine.
Dat lijkt bij mijn server het geval te zijn. Dus wat veroorzaakt het?
Wanneer een virtuele machine wordt gekloond, krijgen de netwerkadapter(s) nieuwe MAC-adressen.
Ja, oké, nog iets anders? Waarom?
Hardwaredetectie
De belangrijkste oorzaak van het nieuwe MAC-adres is dat uw VM een nieuw MAC-adres heeft gekregen omdat u de VM hebt gekloond. Elk nieuw apparaat dat u op uw server aansluit, wordt door de kernel gedetecteerd via een systeem genaamd udev.
Van Wikipedia:
udev is een generieke kernelapparaatbeheerder. Het draait als een daemon op een Linux-systeem en luistert (via netlink-socket) naar gebeurtenissen die de kernel verzendt als een nieuw apparaat wordt geïnitialiseerd of een apparaat uit het systeem wordt verwijderd. Het systeem biedt een set regels die overeenkomen met geëxporteerde waarden van de gebeurtenis en eigenschappen van het ontdekte apparaat. Een overeenkomende regel zal mogelijk een apparaatknooppunt een naam geven en creëren en geconfigureerde programma’s uitvoeren om het apparaat in te stellen en te configureren.
udev-regels kunnen overeenkomen op eigenschappen zoals het kernelsubsysteem, de kernelapparaatnaam, de fysieke locatie van het apparaat of eigenschappen zoals het serienummer van het apparaat. Regels kunnen ook informatie van externe programma’s opvragen om een apparaat een naam te geven of een aangepaste naam op te geven die altijd hetzelfde zal zijn, ongeacht de volgorde waarin apparaten door het systeem worden ontdekt.
Udev is dus de apparaatbeheerder voor de Linux 2.6-kernel en hoger die op dynamische wijze apparaatknooppunten in de map /dev aanmaakt/verwijdert. Het draait in gebruikersruimte en de gebruiker kan apparaatnamen wijzigen met behulp van Udev-regels. Sinds we de VM hebben gekloond, was het alsof de VM nieuwe hardware kreeg, in ieder geval de netwerkkaart met een nieuw MAC-adres.
De udev-regels
udev gebruikt regels om te weten wat er moet gebeuren als er een nieuw hardware-item in het systeem wordt geplaatst. Deze regels worden geplaatst in /etc/udev/rules.d
In deze map zijn al enkele regels geplaatst. Met deze regels kunt u vergelijken met geëxporteerde waarden van de gebeurtenis en eigenschappen van het ontdekte apparaat. Wanneer een regel overeenkomt, wordt het apparaat soms een naam gegeven en wordt er een apparaatknooppunt onder /dev gemaakt. Het maakt het ook mogelijk dat programma’s starten zodra het apparaat wordt geplaatst.
Nogmaals van Wikimedia:
udev-regels kunnen overeenkomen op eigenschappen zoals het kernelsubsysteem, de naam van het kernelapparaat, de fysieke locatie van het apparaat of eigenschappen zoals het serienummer van het apparaat. Regels kunnen ook informatie van externe programma’s opvragen om een apparaat een naam te geven of een aangepaste naam op te geven die altijd hetzelfde zal zijn, ongeacht de volgorde waarin apparaten door het systeem worden ontdekt.
Nadat ik de udev-regels in /etc/udev/rules.d had doorgenomen, merkte ik dat een van de regels, 70-persistent-net.rules, mijn oude netwerkapparaten had (eth0 en eth1), maar ook enkele nieuwe apparaten (eth2 en eth3).
Maar geen van hen verscheen met ifconfig. Waar gaat dat allemaal over?
De inzendingen zagen er ongeveer zo uit``` SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?”, ATTR{address}==”00:50:56:aa:xx:39″, ATTR{type}==”1″, KERNEL==”eth”, NAME=”eth0″ SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?”, ATTR{address}==”00:50:56:aa:xx:xx″, ATTR{type}==”1″, KERNEL==”eth”, NAME=”eth1″ SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?”, ATTR{address}==”00:50:56:aa:xx:xx″, ATTR{type}==”1″, KERNEL==”eth”, NAME=”eth2″ SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?”, ATTR{address}==”00:50:56:aa:xx:xx″, ATTR{type}==”1″, KERNEL==”eth”, NAME=”eth3″
Bij inspectie van de VM-eigenschappen kwam ik erachter dat eth2 en eth3 de apparaten waren die daadwerkelijk in de VM aanwezig waren.
Daarom heb ik de eerste regels uit het regelsbestand verwijderd (uiteraard nadat ik een kopie van het bestand op een andere locatie had gemaakt). Omdat het een firewall-VM was, heb ik ook de eth2 en eth3 gewijzigd in eth0 en eth1 en de VM opnieuw opgestart. Ik had verwacht dat alles zou werken.
## Meer veranderen
Ik was een beetje verbijsterd toen de VM opnieuw werd opgestart, omdat ik nog steeds geen netwerkverbinding had. Als ik het hele artikel las, merkte ik waarschijnlijk dat ik ook de if-eth0- en if-eth1-scripts moest veranderen. Deze scripts configureren de netwerkapparaten nadat ze door de kernel zijn herkend. Waar de scripts worden geplaatst, hangt af van de distributie die u gebruikt. In mijn geval bevonden ze zich in /etc/sysconfig/network-scripts.
Nadat ik ifcfg-eth0 en ifcfg-eth1 had bewerkt en het MAC-adres daarin had gewijzigd naar dezelfde waarden als in de udev-regels, heb ik de hele server opnieuw opgestart (ja, niet erg Linux-achtig, ik weet het) om er zeker van te zijn dat alles op de juiste manier begon en we weer aan de slag konden.
Dus nu weet je het: als je VM na het klonen geen ethernetapparaten weergeeft, moet je waarschijnlijk de udev-regels en de if-eth*-bestanden wijzigen.