Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Neue MAC alte IP

Hilfe bei Problemen mit der Installation und Benutzung der VMware Workstation und VMware Workstation Pro.

Moderatoren: Dayworker, irix

Member
Beiträge: 38
Registriert: 12.09.2012, 08:57

Neue MAC alte IP

Beitragvon Locke85 » 20.09.2012, 08:08

Hallo
Erstmal danke für eure Hilfe beim letzten Thema.

Nun will mein Chef folgendens von mir und ich habe keinen blassen schimmer wie ich vorgehen soll.
Vmware ist auf XP und auf dem Gastsystem läuft Linux Suse

Er möchte jetzt beim Klonen das, das die neue VM, die alte IP beibehält auch wenn sie eine neue MAC-Adresse bekommt.
Ist sowas möglich?

Thank in advanced
Locke85

Experte
Beiträge: 1006
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 20.09.2012, 08:28

Ich möchte eigentlich erstmal die Anwendung verstehen. Warum soll sich die MAC Adresse ändern, die IP aber nicht ? Damit kann man die nicht gleichzeitig einschalten.

Wenn das aber nur für Sicherungszwecke ist dann mach doch keinen Klon sondern eine Kopie (das Unterverzeichnis der VM kopieren),

Mit einer CentOS VM die ich für NFS Zugriffstests nach Einrichtung von NAS Systemen verwende mach ich das schon länger so; die wird dauernd zwischen 4 Rechnern rumkopiert (je nachdem auf welchem System ich sie aktualisiert habe) aber es läuft nie mehr als eine Version davon gleichzeitig; da hätte ich dann doppelte bis dreifache Hostnamen, Macadressen und IP-Adressen.

Member
Beiträge: 38
Registriert: 12.09.2012, 08:57

Beitragvon Locke85 » 20.09.2012, 08:42

mbreidenbach hat geschrieben:Ich möchte eigentlich erstmal die Anwendung verstehen. Warum soll sich die MAC Adresse ändern, die IP aber nicht ? Damit kann man die nicht gleichzeitig einschalten.

Wenn das aber nur für Sicherungszwecke ist dann mach doch keinen Klon sondern eine Kopie (das Unterverzeichnis der VM kopieren),

Mit einer CentOS VM die ich für NFS Zugriffstests nach Einrichtung von NAS Systemen verwende mach ich das schon länger so; die wird dauernd zwischen 4 Rechnern rumkopiert (je nachdem auf welchem System ich sie aktualisiert habe) aber es läuft nie mehr als eine Version davon gleichzeitig; da hätte ich dann doppelte bis dreifache Hostnamen, Macadressen und IP-Adressen.


Danke für deine Antwort,
die Variante mit CentOS und dem Kopieren ist wie eine Sicherung zu erstellen.
Jedoch ist es im Betrieb einfach Rechtsklick und Klonen, da hat man aber wieder das Problem, das Linux eine weitere Netzwerkarte erstellt und somit muss man es überLinux wieder anpassen. Genau das soll nicht mehr passieren.

Benutzeravatar
Member
Beiträge: 146
Registriert: 05.04.2011, 20:08

Beitragvon Santa » 20.09.2012, 10:06

Was spricht denn dgegen die gleiche MAC-Addresse? Dann erkennt das BS beim Start auch keine neue Netzwerkkarte und man hat eine identische Kopie.
Wenn Du die VM zum weiteren Gebrauch kopierst, braucht sie eine neue MAC- und IP-Addresse (eventuell auch auch via DHCP).

Member
Beiträge: 38
Registriert: 12.09.2012, 08:57

Beitragvon Locke85 » 20.09.2012, 10:28

Santa hat geschrieben:Was spricht denn dgegen die gleiche MAC-Addresse? Dann erkennt das BS beim Start auch keine neue Netzwerkkarte und man hat eine identische Kopie.
Wenn Du die VM zum weiteren Gebrauch kopierst, braucht sie eine neue MAC- und IP-Addresse (eventuell auch auch via DHCP).


Danke für deine Antwort
bei diesem System sollen nicht 2 gleiche MAC-Adressen vorhanden sein.
Ich denke eher das Problem liegt in Linux Suse.

MfG
Locke85

King of the Hill
Beiträge: 13652
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.09.2012, 12:11

Ich meine mich dünkel bei Suse zu erinnern, daß man die Festmachung der Nic an der MAC-Adresse auch ändern kann.
Auf eine ähnlich gelagerte Problematik war ich bei Ubuntu-Linux gestossen, als ich dessen Disk per "gparted" vergrössert hatte und dadurch eine neue UUID generiert wurde. Viele Linux-Distro's machen dabei wie Windows ab Vista ihr Bootlaufwerk nur anhand dieser ID fest. Beispielsweise spielt es dann keine Rolle mehr, an welchen Anschluß man letztendlich die Platte steckt, solange die UUID übereinstimmt und das OS den passenden Treiber für den Anschluß mitbringt.

Member
Beiträge: 38
Registriert: 12.09.2012, 08:57

Beitragvon Locke85 » 20.09.2012, 12:45

Dayworker hat geschrieben:Ich meine mich dünkel bei Suse zu erinnern, daß man die Festmachung der Nic an der MAC-Adresse auch ändern kann.
Auf eine ähnlich gelagerte Problematik war ich bei Ubuntu-Linux gestossen, als ich dessen Disk per "gparted" vergrössert hatte und dadurch eine neue UUID generiert wurde. Viele Linux-Distro's machen dabei wie Windows ab Vista ihr Bootlaufwerk nur anhand dieser ID fest. Beispielsweise spielt es dann keine Rolle mehr, an welchen Anschluß man letztendlich die Platte steckt, solange die UUID übereinstimmt und das OS den passenden Treiber für den Anschluß mitbringt.


ich wäre auch bereit VSphere, zu benutzen aber würde es nicht gerne doppelt Posten.
Habe einen altern Thread hier im forum gefunden.

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

Leider habe ich Suse und weiss nicht wie ich vorgehen soll, weil den orderner
z25_persistent-net.rules habe ich nicht im angegeben verzeichnis.

MfG
Locke85

Benutzeravatar
Member
Beiträge: 146
Registriert: 05.04.2011, 20:08

Beitragvon Santa » 20.09.2012, 13:30

Dayworker hat geschrieben:Ich meine mich dünkel bei Suse zu erinnern, daß man die Festmachung der Nic an der MAC-Adresse auch ändern kann.
Ja - eben.
Bei SuSE ist das Netzwerkinterface defaultmäßig nicht durchnummeriert (eth0 und so), sondern an die MAC gebunden: eth-id-xx-xx-xx-xx-xx-xx.
Der OP hat uns leider noch nicht verraten, was der Sinn dieser Aktion ist.
Wenn es seine Sicherheitskopie sein soll, würde ich sie so unverändert wie möglich (gleiche MAC und IP) erhalten.
Wenn es ein Klon sein soll, der parallel laufen soll, braucht es eine neue MAC und IP.
Wenn es um eine Hochverfügbarkeitslösung geht, würde ich mit einer virtuellen IP arbeiten, welche von den physikalischen MAC und IP abgekoppelt ist.

King of the Hill
Beiträge: 13652
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.09.2012, 18:49

@Santa
Der Sinn dahinter ist doch eigentlich ganz einfach. Eine kopierte VM hat auf einem anderen Host dank der sich ändernden MAC-Addy meistens kein Netzwerkinterface mehr.
Falls man eine Linux-VM trotzdem mehrfach ausrollen will, löscht man entweder die udev-Regel im Template oder sorgt dafür, daß die MAC keine Rolle mehr spielt.
Das man die MAC nachher vielleicht doch noch im Switch/Router/etc eintragen muß, steht auf einem anderen Blatt.


@Locke85
eth0 verschwindet in Debian VMware ;)

King of the Hill
Beiträge: 13652
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 21.09.2012, 11:32

Bevor wir den Debian-Thread im Player-Bereich übernehmen, sollten wir lieber bei der Suse-Thematik bleiben. Deshalb kommt dein Fullquote auch jetzt nochmal hier:
Locke85 hat geschrieben:
Dayworker hat geschrieben:Versuch mal den VMTN-Eintrag SUSE 10 and changing MAC addresses, ob das auch noch mit deiner Suse-Version funktioniert.


vielen dank aber jetzt fangen die Proleme erst an :cry:

1. rename the ifcfg-eth-id-<MAC-ADDRESS> to ifcfg-eth0 (in /etc/sysconfig/network)

Bild

soll ich ifcg-eth-id-00:50:56:XX:YY:ZZ >> ifcg-eht0
oder
ifcg-eth-id-00:50:56:XX:YY:ZZ >> ifcg-eth0-id-00:50:56:XX:YY:ZZ??

2. remove the rules file (/etc/udev/rules.d/30-<rest of name here>

Bild

diese Datei ist nicht vorhanden oder soll ich komplett rules.d löschen?

3. edit /etc/sysconfig/network/config and change FORCE_PERSISTENT_NAMES to "no".



Code: Alles auswählen

## Path:   Network/Hardware/Config
## Description:   Set some general network configuration
## Type:   string("","-","+")
## Default:   "+"
## ServiceRestart: network
#
# DEFAULT_BROADCAST is used when no individual BROADCAST is set. It can get one
# of the following values:
# ""  : don't set a broadcast address
# "-" : use IPADDR with all host bits deleted
# "+" : use IPADDR with all host bits set
DEFAULT_BROADCAST="+"

## Type:   yesno
## Default:   yes
# sometimes we want some script to be executed after an interface has been
# brought up, or before an interface is taken down.
# default dir is /etc/sysconfig/network/if-up.d for POST_UP and
# /etc/sysconfig/network/if-down.d for PRE_DOWN
GLOBAL_POST_UP_EXEC="yes"
GLOBAL_PRE_DOWN_EXEC="yes"

## Type:        yesno
## Default:     no
# If ifup should check if an ip address is already in use, set this to yes.
# Make sure that packet sockets (CONFIG_PACKET) are supported in the kernel,
# since this feature uses arping, which depends on that.
# Also be aware that this takes one second per interface; consider that when
# setting up a lot of interfaces.
CHECK_DUPLICATE_IP="no"

## Type:        yesno
## Default:     no
# Switch on/off debug messages for all network configuration stuff. If set to no
# most scripts can enable it locally with "-o debug".
DEBUG="no"

## Type:        yesno
## Default:     yes
# Should error messages from network configuration scripts go to syslog, or do
# you like them on stderr?
USE_SYSLOG="yes"

## Type:        yesno
## Default:     yes
# There are some services (ppp, ippp, dhcp-client, pcmcia, hotplug) that have to
# change the /etc/resolv.conf dynamically at certain times.  E.g. if ppp/ippp
# establishes a connection and is supplied by the peer with a list of
# nameservers. Or pcmcia needs to set the correct nameserver for the choosen
# configuration scheme. If you don't like these services to change
# /etc/resolv.conf at all, then set this variable to "no".
# If unsure, leave it at the default (which is "yes").
#
MODIFY_RESOLV_CONF_DYNAMICALLY="yes"

## Type:        yesno
## Default:     no
# Like MODIFY_RESOLV_CONF_DYNAMICALLY, except it modifies /etc/named.conf.
# If unsure, leave it at the default (which is "no").
#
MODIFY_NAMED_CONF_DYNAMICALLY="no"

# Handling of network connections
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# These features are designed for the convenience of the experienced
# user. If you encounter problems you don't understand then switch
# them off. That is the default.
# Please do not complain if you get troubles. But if you want help to
# make them smarter write to <http://www.suse.de/feedback>.

## Type:   yesno
## Default:   no
#
# If you are interested in the connections and nfs mounts that use a
# network interface, you can set CONNECTION_SHOW_WHEN_IFSTATUS="yes".
# Then you will see them with 'ifstatus <interface>' (or 'ifstatus
# <config>')
# This one _should_ never harm ;)
#
CONNECTION_SHOW_WHEN_IFSTATUS="no"

## Type:   yesno
## Default:   no
#
# If an interface should be set down only if there are no active
# connections, then use CONNECTION_CHECK_BEFORE_IFDOWN="yes"
#
CONNECTION_CHECK_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If these connetions (without the nfs mounts) should be closed when
# shutting down an interface, set CONNECTION_CLOSE_BEFORE_IFDOWN="yes".
# WARNING: Be aware that this may terminate applications which need
# one of these connections!
#
CONNECTION_CLOSE_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If you are a mobile laptop user and like even nfs mounts to be
# closed when you leave your current workplace, then set
# CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="yes". This does only work
# if CONNECTION_CLOSE_BEFORE_IFDOWN="yes", too.
# WARNING: Be aware that this may terminate applications which use
# these nfs mounts as working directory. Be very carefull if your home
# is mounted via nfs!!!
# WARNING: This may even lead to hanging ifdown processes if there are
# processes that could not be terminated. If you are using
# hotpluggable devices (pcmcia, usb, firewire), first shut them down
# before unplugging!
#
CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="no"

## Type:   yesno
## Default:   no
#
# If terminating processes that use a connection or nfs mount is not
# enough, then they can be killed after an unsuccesfull termination.
# If you want that set CONNECTION_SEND_KILL_SIGNAL="yes"
#
CONNECTION_SEND_KILL_SIGNAL="no"

## Type:        string
## Default:     ""
#
# Here you may specify which interfaces have to be up and configured properly
# after 'rcnetwork start'. rcconfig will return 'failed' if any of these
# interfaces is not up. You may use interface names as well but better use
# hardware descriptions of the devices (eth-id-<macaddress> or eth-bus-...  See
# man ifup for 'hardware description'). The network start script will wait for
# these interfaces, but not longer as set in WAIT_FOR_INTERFACES.
# You need not to add dialup or tunnel interfaces here, only physical devices.
# The interface 'lo' is always considered to be mandatory and can be omitted.
#
# If this variable is empty, rcnetwork tries to derive the list of mandatory
# devices automatically from the list of existing configurations. Configurations
# with names bus-pcmcia or bus-usb or with STARTMODE=hotplug are skipped. (try
# '/etc/init.d/rc5.d/S*network start -o debug fake | grep MANDAT')
MANDATORY_DEVICES=""

## Type:   integer
## Default:   20
#
# Some interfaces need some time to come up or come asynchronously via hotplug.
# WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in
# seconds. If empty no wait occurs.
#
WAIT_FOR_INTERFACES="20"

## Type:   yesno
## Default:   yes
#
# With this variable you can determine if the SuSEfirewall when enabled
# should get started when network interfaces are started.
FIREWALL="yes"

## Type:        string("off","guess","auto-off","auto-manual","manual")
## Default:     "off"
#
# !!!This feature is still not implemented. Leave it to 'off'!!!
# What shall we do if there is no valid configuration?
# off:         do nothing, just fail
# guess:       try to guess the needed info (zeroconf)
# auto-off:    trigger automatic creation of a config file; if that fails, do
#              nothing, just fail
# auto-manual: trigger automatic creation of a config file; if that fails, ask
#              user to provide configuration (via yast)
# manual:      ask user to provide configuration (via yast)
# !!!This feature is still not implemented. Leave it to 'off'!!!
FAILURE_ACTION=off

## Type:        string
## Default:     "eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
#
# Automatically add a linklocal route to the matching interfaces.
# This string is used in a bash "case" statement, so it may contain
# '*', '[', ']'  and '|' meta-characters.
#
LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"

## Type:        string
## Default:     "-a -f -I -u 0 -d 10"
#
# Set default options for ifplugd. You may also set them in an ifcfg-* file
# individually. Have a look at 'man ifplug' for details. We let ifplugd set the
# interface UP when starting, because there are many interfaces where link beat
# cannot be detected otherwise. If you want the interface to stay down then add
# the option '-a'.
#
IFPLUGD_OPTIONS="-f -I -u 0 -d 10"

## Type:        yesno
## Default      yes
#
# If you don't want to use ipv6 at all, set this to 'no'. Then ifup will always
# flush all ipv6 adresses. This might be usefull together with ifplugd, if link
# beat detection is only possible with interface UP.
#
USE_IPV6=no

FORCE_PERSISTENT_NAMES sowas finde ich leider nicht :(

Benutze 9.3 suse

Das hättest du aber auch gleich sagen können und die Suchparameter "suse 9.3 changing MAC address" sollten dich weiterbringen. ;)

Member
Beiträge: 38
Registriert: 12.09.2012, 08:57

Beitragvon Locke85 » 21.09.2012, 12:31

Das hättest du aber auch gleich sagen können und die Suchparameter "suse 9.3 changing MAC address" sollten dich weiterbringen. ;)


Also
es funktioniert einwandfrei :D
habe sogar es bei mehr als eine VM probiert. Wenn man die VM klont zeigt ifconfig etho an.
Beim ersten Versuch hatte ich einen Fehler, den ich mir nicht erklären konnte evtl habe ich mich vertippt.

Thankfully there is a relatively easy (though not intuitive) way to solve this. What you need to do is to get to a command prompt and type in the following commands:

cd /etc/sysconfig/network


ls

At this stage you should see a file called 'ifcfg-eth-id-00:03:ff:xx:xx:xx' (substitute the 'xx:xx:xx' appropriately). This is the cause of the problem.


sudo mv ifcfg-eth-id-00\:03\:ff\:xx\:xx\:xx ifcfg-eth0

Once again you should substitute the 'x's appropriately
Once you have done this you should be able to reboot the virtual machine and have the networking continue to work no matter what the MAC address is of the virtual network card.

Cheers,
Ben

http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/09/06/461658.aspx

SUPER FETTEN DANK AN DAS FORUM :)

MfG
Locke85


Zurück zu „VMware Workstation und VMware Workstation Pro“

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 1 Gast