| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
rs80
Member
Anmeldungsdatum: 29.06.2007
Beiträge: 2
|
 Verfasst am: 29.06.2007, 17:06 Titel: eth0 verschwindet in Debian VMware |
 |
|
Hallo zusammen
Kennt jemand das Problem bei Debian-40r0 in VMWARE.
Manchmal wenn man die VMware virtuell ausschaltet,
(Also shutdown -h now und erneutes einschalten)
verschwindet einfach eth0, obwohl der Netzweradapter in VMware
noch immer auf Connected und Bridged steht.
Man kann ihn irgendwie auch nicht mehr aktivieren,
denn bei der Eingabe von: ifconfig eth0 dynamic up
erscheint:
eth0: ERROR while getting interface flags: Kein passendes Gerät gefunden
Wenn man allerdings den Bootschirm mit folgendem Kommando absucht:
dmesg | grep eth
erscheint:
eth0: registered as PCnet/PCI II 79C970A
Seltsam, denn auch ein neustarten mit
/etc/init.d/networking restart
hilft nichts.
Mit ifconfig -a findet man jedoch heraus, dass jetzt eth1
vorhanden ist. Warum auch immer!
Aber okay, dann versuchte ich eben diesen mit
ifconfig eth1 dynamic up
zu aktivieren.
Aber dieser holt sich nie eine DHCP Adresse und beim Neustart
verschwindet er auch immer wieder,
obwohl ich dann auch die /etc/network/interfaces
auf eth1 angepasst habe 
Dieses Problem habe ich nun schon bereits auf 3 verschiedenen
Debian Versionen auf VMware festgestellt.
Bei richtigen pysikalischen PCs mit Debians kommt dies nie vor.
Kann mir jemand weiterhelfen?
Wäre sehr dankbar.
Viele Grüsse
Ralph |
|
| Nach oben |
|
 |
rs80
Member
Anmeldungsdatum: 29.06.2007
Beiträge: 2
|
| Verfasst am: 02.07.2007, 16:19 Titel: |
|
|
Hallo zusammen
Hab nun folgende Änderungen in der Datei /etc/network/interfaces
vorgenommen und das Netzwerk neu gestartet:
VORHER:
| Code: | [...]
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp |
NACHHER:
| Code: | [...]
auto lo
iface lo inet loopback
# The primary network interface
#allow-hotplug eth0
auto eth1
iface eth1 inet dhcp |
Nun funktionierts. Wieso genau eth0 plötzlich einfach so rausfliegt,
was der Unterschied zwischen allow-hotplug eth1 und auto eth1
genau ist und wieso im dmesg trotzdem eth0 als Netzwerkadapter
gefunden wird, weiss ich noch nicht.
Wenn ich es rausfinde, werde ich mal noch was schreiben.
Ansonsten lege ich es zur Akte X.
Viele Grüsse
Ralph |
|
| Nach oben |
|
|
MSueper
Virtueller Chef
Anmeldungsdatum: 11.08.2004
Beiträge: 1437
Wohnort: Paderborn
|
| Verfasst am: 02.07.2007, 17:25 Titel: |
|
|
seltsam,
danke Für den Update!
Grüße, Martin |
|
| Nach oben |
|
|
okx
Member
Anmeldungsdatum: 30.07.2007
Beiträge: 4
|
| Verfasst am: 31.07.2007, 00:02 Titel: |
|
|
Ahoi,
wenn der Thread noch lebt, kann ich noch einen drauf setzen...
Ich habe ein sehr ähnliches Problem wie rs80:
Ein mit dem Server aufgesetzes Debian (etch) wird auf verschiedenen Windoof Rechnern mit dem Player abgespielt und bekommt dann keine Netzwerkkarte. Als Randbedingung wäre noch zu sagen, daß die VM mit Host-only konfiguriert wurde, was auch auf dem Server hervorragend funktioniert. Sobald die Maschine im Player auf einem fremden Rechner läuft, meldet Debian beim Aktivieren der eth0 "no such device". Witziger Weise passiert es nicht wenn der Host ein Linux ist - also nur bei Windows Hosts besteht diese Problem. 
Aus Spaß habe ich mal den Tip von rs80 umgesetzt und es mit der Konfiguration von eth1 ausprobiert - NIX GUT! 
Mehr oder weniger aus Blödellei habe ich es dann mal mit eth2 probiert... - siehe da, eth2 war ein Volltreffer! 
Ich bin ein wenig verwirrt, ich hatte gedacht, daß der Adapter vmnet1 (Host-Only) als einziger Adapter in die VM reingereicht wird und dieser dann auch vom Debian als eth0 erkannt wird? 
Bin ich da auf dem Holzweg, oder erkennt da vielleicht jemand ein logisches System?
Gruß,
okx |
|
| Nach oben |
|
|
okx
Member
Anmeldungsdatum: 30.07.2007
Beiträge: 4
|
| Verfasst am: 31.07.2007, 11:45 Titel: Help yourself |
|
|
Ok, selbst ist der Mann  :
Auch wenn ich nicht verstanden habe warum Debian sich so merkwürdig mit dem vergeben der eth Nummern verhält, kann man simpel mit
| Code: | | grep eth /proc/net/dev |
sich die vom System erkannten eths anschauen und dann gezielt diese hochfahren bzw. sie in der /etc/network/interfaces verdrahten.
Da ich die VMs auf verschiedenen Rechnern laufen lassen will/muß ist also in der VM jeweils ein einmaliger (hoffentlich) Eingriff nötig - hmm |
|
| Nach oben |
|
|
MSueper
Virtueller Chef
Anmeldungsdatum: 11.08.2004
Beiträge: 1437
Wohnort: Paderborn
|
| Verfasst am: 31.07.2007, 12:13 Titel: |
|
|
Hi,
dies sind alle meine Einträge zu ethernet0 und einer VM mit Linux:
ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:69:75:67"
ethernet0.generatedAddressOffset = "0"
bei einigen kommt noch
ethernet0.virtualdev = "e1000"
ethernet0.connectionType = "bridged"
hinzu.
Hast Du weitere Einstellungen? Trag mal >> ethernet0.connectionType = "bridged" << explizit bei Dir in die vmx-Datei ein und poste auch mal die ganze vmx-Datei. Da sind ggf. noch irgendwelche Reste drin...
Martin |
|
| Nach oben |
|
|
okx
Member
Anmeldungsdatum: 30.07.2007
Beiträge: 4
|
| Verfasst am: 31.07.2007, 15:13 Titel: |
|
|
So, hier kommt meine vmx:
| Code: | config.version = "8"
virtualHW.version = "4"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "256"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Other Linux 2.6.x kernel.vmdk"
ide1:0.present = "FALSE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.fileName = "A:"
Ethernet0.present = "TRUE"
displayName = "bomvers"
guestOS = "other26xlinux"
priority.grabbed = "normal"
priority.ungrabbed = "normal"
ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"
scsi0:0.redo = ""
ethernet0.addressType = "generated"
uuid.location = "56 4d a2 a6 4c ce c3 53-6b 31 ae a0 a7 52 01 3d"
uuid.bios = "56 4d a2 a6 4c ce c3 53-6b 31 ae a0 a7 52 01 3d"
ethernet0.generatedAddress = "00:0c:29:52:01:3d"
ethernet0.generatedAddressOffset = "0"
ide1:0.startConnected = "FALSE"
ethernet0.connectionType = "hostonly"
floppy0.present = "FALSE"
workingDir = "."
|
Der Connection-Type steht übrigens auf hostonly, was auch in meinem Fall korrekt und gewünscht ist. Der Zugriff soll nur über ein privates Netzwerksegment "sichtbar" sein.
Am ethernet0.virtualdev habe ich auch schon mal erfolglos rumgeschraubt. Der Eintrag hat für meine Problematik vermutlich keine Auswirkungen
Was mich an der vmx-Datei ein wenig wundert ist die bunte Reihenfolge der Einträge und die unterschiedliche Groß/Kleinschreibung von Ethernet. Ich habe dies jedenfalls nicht verursacht.
Gruß,
okx |
|
| Nach oben |
|
|
the13th
Member
Anmeldungsdatum: 19.08.2007
Beiträge: 2
|
| Verfasst am: 19.08.2007, 03:19 Titel: |
|
|
Da ich das Thema auch gerade durch habe hier mal als "Einstand" die Lösung 
Nach dem Kopieren eines VM Ware Images und dem importieren des selbigen wird die MAC Adresse der Netzwerkkarte geändert.
Da Linux eine Liste der MAC IDs pro IF vorhält und somit eth0 für die Netzwerkverwaltung "nicht mehr vorhanden ist", die neue MAC ID aber auch nicht bekannt ist, wird daraus dann eth1.
Die Lösung ist eigentlich ganz Simpel:
1. In der neu erstellen .vmx Datei die MAC Adresse der Netzwerkkarten auslesen (ethernet0.generatedAddress)
2. Die Virtuelle Maschine anschmeissen und dann mit dem Texteditor der Wahl die durch das kopieren neuerstellte MAC ID in der Datei /etc/iftab an entsprechender Stelle einfügen
3. Die virtuelle Maschine neustarten. |
|
| Nach oben |
|
|
okx
Member
Anmeldungsdatum: 30.07.2007
Beiträge: 4
|
| Verfasst am: 22.08.2007, 01:36 Titel: |
|
|
Hallo nochmal,
Da ich mit Deiner (the13th) und meiner Lösung nicht so ganz zufrieden war, habe ich noch ein wenig weiter geforscht. Auf alle Fälle ist das Verrutschen der eths auf die sich ändernde MAC-Adresse zurückzuführen, wie Du sehr richtig herausgefunden hast - vielen Dank für den Schubs in die richtige Richtung!
Im Thread des Ubuntu-Forums http://ubuntuforums.org/showthread.php?p=3196271 (ganz unten) wird geschrieben, wie man udev austricksen kann um immer eth0 zu vergeben, unabhängig von der MAC-Adresse.
| Code: | | GOTO="persistent_net_generator_end" |
an den Anfang von /etc/udev/persistent-net-generator.rules stellen
und den Inhalt von Datei /etc/udev/rules.d/z25_persistent-net.rules löschen und einmal durchstarten (ein frischer Boot tut immer gut ).
Der Vorteil von dieser Methode ist, daß man dies nur einmal machen muß und die VM dann auf jedem Host-System sich die eth0 schnappt - Ein rumpuzzeln in Config-Dateien für jede Player-Instanz bzw. jeden neuen Host entfällt somit 
Genau das ist für mich wichtig, wenn die VM auf vielen unterschiedlichen Hosts laufen soll!
Gruß,
okx |
|
| Nach oben |
|
|
emil82
Member
Anmeldungsdatum: 14.10.2007
Beiträge: 1
|
| Verfasst am: 14.10.2007, 15:17 Titel: |
|
|
Hallo okx,
dein letzter Beitrag verwirrt mich etwas. Wenn ich deine Anweisungen befolge schnappt sich mein Debian Etch überhaut keine eth mehr, ich muss diese immer erst mit "ifup eth0" per Hand starten.
Hab ich da etwas falsch verstanden? Kannst du mir bitte exakt beschreiben wo die besagte Zeil rein muss.
| Code: |
# These rules generate rules to keep network interface names unchanged
# across reboots write them to /etc/udev/rules.d/z25_persistent-net.rules.
#
# The default name for this file is z45_persistent-net-generator.rules.
# hier die von dir beschriebene Zeile.....
GOTO="presistent_net_generator_end"
ACTION!="add", GOTO="persistent_net_generator_end"
SUBSYSTEM!="net", GOTO="persistent_net_generator_end"
# ignore the interface if a name has already been set
NAME=="?*", GOTO="persistent_net_generator_end"
# ignore "secondary" raw interfaces of the madwifi driver
KERNEL=="ath*", ATTRS{type}=="802", GOTO="persistent_net_generator_end"
# provide nice comments for the generated rules
SUBSYSTEMS=="pci", \
ENV{COMMENT}="PCI device $attr{vendor}:$attr{device}"
SUBSYSTEMS=="usb", \
ENV{COMMENT}="USB device $attr{idVendor}:$attr{idProduct}"
SUBSYSTEMS=="ieee1394", \
ENV{COMMENT}="Firewire device $attr{host_id}"
SUBSYSTEMS=="xen", \
ENV{COMMENT}="Xen virtual device"
ENV{COMMENT}=="", \
ENV{COMMENT}="Unknown $env{SUBSYSTEM} device ($env{DEVPATH})"
ATTRS{driver}=="?*", \
ENV{COMMENT}="$env{COMMENT} ($attr{driver})"
# ignore interfaces without a driver link like bridges and VLANs
KERNEL=="eth*|ath*|wlan*|ra*|sta*", DRIVERS=="?*",\
IMPORT{program}="write_net_rules $attr{address}"
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"
LABEL="persistent_net_generator_end"
|
MfG Emil |
|
| Nach oben |
|
|
skammann
Member
Anmeldungsdatum: 15.06.2008
Beiträge: 1
|
| Verfasst am: 15.06.2008, 12:48 Titel: Problem gelöst |
|
|
Wollte mal kurz ein Danke in den Raum schmeissen
Hatte das gleiche Problem und konnte das , dank dieses Threads , sofort lösen.
Gruss
Stefan |
|
| Nach oben |
|
|
RogerG781
Experte
Anmeldungsdatum: 28.02.2008
Beiträge: 172
|
| Verfasst am: 28.05.2009, 11:23 Titel: |
|
|
Hi Leute,
ich hole den Thread nochmal hervor. Vor einigen Tagen habe ich meinem ESXi mehr RAM gegönnt. Beim Herunterfahren des ESXi wurde anscheinend meine Debian-VM nicht sauber beendet
Nach einschalten des ESXi erscheint beim Versuch die Debian-VM zu starten immer die Fehlermeldung:
Could not power on VM: No Swap File
Failed to Power on VM
Da es sich bei meinem ESXi um ein Standalone-Gerät handelt, konnte ich einen noch laufenden Prozess durch eine Migration ausschliessen. Ein Reboot änderte das Verhalten nicht. Speicherplatz ist ebenfalls genug auf dem Storage vorhanden.
Da ich nicht weiterkam, erstellte ich eine weitere VM und übergab ihr die Festplatte der alten VM.
Nun startet die VM auch wieder, erkennt aber keine Netzwerkkarten. Mit einem ifconfig, wird mir nur der Loopback-Adapter angezeigt.
Nun wollte ich zunächst die MAC-Adresse der alten VM auf die neue übertragen. Aber anscheinend hat sich durch ein ESXi Update die MAC-Range bei VMware geändert?
VM-Alt MAC-Adresse: 00:0C:29
VM-Neu MAC-Adresse: 00:50:56
Also konnte ich die MAC-Adressen nicht übertragen, da sich der VI-Client beschwert, dass es nicht innerhalb der Range liegen würde.
So versuchte ich zunächst mit dem Befehl grep eth /proc/net/dev die Nummer des neuen Interfaces zu ermitteln und es wurde mir eth5 angezeigt. Wenn ich nun allerdings versuche mit ifup eth5 das Interface zu starten, bekomme ich die Fehlermeldung: Ignoring unknown interface eth5=eth5
Wie bekomme ich es am besten wieder hin, die Debian-VM mit eth0 und eth1 und den bereits konfigurierten IP-Adressen ans Rennen zu bekommen?
Danke. |
|
| Nach oben |
|
|
chris72
Member
Anmeldungsdatum: 28.07.2009
Beiträge: 1
|
| Verfasst am: 28.07.2009, 15:21 Titel: ethX Nummern wieder von 0 weg zuweisen |
|
|
| RogerG781 hat Folgendes geschrieben: |
Wie bekomme ich es am besten wieder hin, die Debian-VM mit eth0 und eth1 und den bereits konfigurierten IP-Adressen ans Rennen zu bekommen?
|
öffne mal /etc/udev/rules/70-persistent-net.rules
und lösch alle Einträge raus.
Nach dem nächsten reboot werden die Netzwerkkarten
neu erkannt und aufsteigend beginnend bei eth0
wieder in die Datei eingetragen.
Kämpfe gerade selbst mit dem Anfangs beschriebenen Problem
das die Netzwerkkarte erst nach einem zusätzlichen "ifconfig eth0 up"
funktioniert. Verwende vmware-server mit Host Win2003 und Guest
CentOS5.3. Wobei ich bereits verschiedene Linux Distries durchprobiert
habe und auch unter vmware-server 1.09 dasselbe Problem hab.
Beim CentOS hab ich dann zufällig die Krücke mit dem ifconfig entdeckt.
eth0 hat statisch eine IP zugewiesen und wird über bridged mode mit
dem Lan verbunden. Nach /etc/init.d/network start ist das Interface up
aber ich kann weder raus noch rein pingen.
Wenn ich dann nochmal "ifconfig eth0 up" in der Shell starte, dann
funktioniert das Netzwerk. ifconfig eth0 liefert genau die gleiche
Ausgabe wie vor dem "up".
In den diversen Logfiles finde ich auch nichts.
Hab bereits einige Zeit gegoogelt und auch einige Postings von Leuten
mit dem gleichen Problem gefunden. War aber keine saubere Lösung dabei.
Hab jetzt einfach "ifconfig eth0 up" am Ende vom "start" case in
/etc/init.d/network ergänzt. Damit kann ich vorerst leben.
Hatte bisher noch nie Probleme mit vmware Netzwerkverbindungen. |
|
| Nach oben |
|
|
|
Login
Suchen
Registrieren
