Linux VM lose IP, MAC, Networking after replication, backup

[pkuczynski]

Using veeam 4.1
Ubuntu 8.04.4 LTS JEOS virtual machine [server] Hardy

when performing a replca to a second iscsi SAN, then starting the machine from ESXi4, the machine boots without networking.

I then have to reset the network interfaces by typing:
rm /etc/udev/rules.d/70-persistent-net.riles
and reboot the vm, init6

only then does the machine come up with networking on.

doing a BACKUP [not replacation] but a BACKUP of the same virtual machine, then a restore, and the machine boots fine.

Thoughts as to why this might be happening during replication?
Peter

[tsightler]

When replicating, Veeam is replicating to a "different" VM with a different UUID because VMware doesn't allow two host with the same UUID to both be registered. By default VMware uses some algorithm with the UUID to create the virtual MAC address of the network card, unfortuntely, by default Ubuntu binds devices by MAC address. Since the UUID of the source VM and the UUID of the replica VM are not the same, neither is their MAC address, so Ubuntu things it's a "different" network card and is likely assigning it to "eth1" instead of "eth0".

There are really two simple solutions:

1. Assign a static MAC address to the source VM using vCenter. Since the MAC is statically entered in the configuration, the replica will have the same MAC address as the source system and Ubuntu will be happy. Just remember to not power on both of these on the same ethernet segment (probably not something you would do anyway, but two ethernet ports with the same MAC on the same LAN is an obvious no-no).

2. Make Ubuntu smarter by teaching it not to persistently bind VMware MAC addresses. This is accomplished by editing /etc/udev/rules.d/70-persistent-net.rules on the source rather than removing it from the target. Just edit 70-persistent-net-rules, delete the current line which binds the current mac address to eth0 which will look something like this:

Code: Select all

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:44:55:66", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

And add these lines to the top of the file:

Code: Select all

# ignore VMware virtual interfaces
ATTR{address}=="00:0c:29:*", GOTO="persistent_net_generator_end"
ATTR{address}=="00:50:56:*", GOTO="persistent_net_generator_end"

Now replicate your VM and you should be good to go.

EDIT -- Actually Option #2 might not be 100% right. I haven't made this change in a while (we're mostly a Redhat shop) and I got antsy and looked it up and found two websites with similar instructions but they mention two different files. I'm not sure which one is correct but here are the links to both:

http://professionalvmware.com/2009/03/u ... ge-mayhem/

http://blog.core-it.com.au/?p=524

[pkuczynski]

Cant wait to try it!!!
THANK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[pkuczynski]

Works Great.
I used the second option.

[antivir]

This does not work in Ubuntu 10.04.1.
The proper solution:
75-persistent-net-generator.rules

Code: Select all

ENV{MATCHADDR}="$attr{address}"
ENV{address}=="00:0c:29:*", GOTO="persistent_net_generator_end"
ENV{address}=="00:50:56:*", GOTO="persistent_net_generator_end"

[tsightler]

Actually, Ubuntu 10.04.1 should already include a rule to do this in 75-persistent-net-generator.rules. The default file has the following line:

# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"

Which should be the exact equivalent to what you posted. If it's not working without manually adding then someone should file a bug against Ubuntu to get that fixed.

[antivir]

Actually, Ubuntu 10.04.1 should already include a rule to do this in 75-persistent-net-generator.rules.

Ubuntu 10.04.1 LTS does not include it.

[tsightler]

You're right, I think this was added in 10.10. Old age and confusion go together.

[Gostev]

Similar topic about CentOS > SureBackup networking with Linux VMs

[kir@tech]

hi to all,

after a replication job I have tested my VM_replicated but, very big surprise , she didnt respond to ping... MAC address and IP address are different.
the VM have tools installed.
tested other two different VM linux based (with different linux) and there is the same situation.

no problem wtih MS W2003/2008R2
env: 2 host with localdatastore (RX300S3 and RX300S5)

thanks,

Luigi

[jakko]

Hi. I'm evaluating Veeam B&R for my company. I am currently trying to get failover working successfully on a replicated linux guest. There are two issues that I'm experiencing:

1) The replica's mac address changed. It also changed in the /etc/sysconfig/network-scripts/ifcfg-eth0 file.
2) I have the network settings statically set in the source vm. None of these settings are carried over to the replica.

Due to this, the failover time increases because I still need to go in and restore the network settings manually. Is this the correct behavior for replication with linux hosts or is it supposed to make an exact copy (including network settings) to the replica.

Note: I am using esxi5 and a distributed vswitch.

Thanks!

[Gostev]

Similar topic about RHEL > RHEL6 SureBackup

[sengelmann]

Hi to all,

we have the same problem with sles 10 10 servers (novell oes2)
in /etc/sysconfig/network/ config script form the network card there is no mac adress line

somebody knows how i can change this under sles 10 ?

when t tried to set the mac address manual with the vmware client to the mac address the sles server now have i get an error
wrong range

[sengelmann]

i found an solution
you must edit the vmx config file of the virtual linux server manual then sure backup works fine

here are the steps:
- power off server
- copy vmx config file to your pc
- open with editor
- modify two lines ->
ethernet0.addressType from “vpx” to “static
"ethernet0.GeneratedAddress" to "ethernet0.Address"
- copy vmx config file back and overwrite the existing one
- deregister virtual server vom vcenter or esx
- register vmx file back to the vcenter or esx server
- modify backup jobs in veeam (because od deregsiter and register it are new servers for veeam)
- rerun backup jobs
- and now the surebackups are working fine

testet with oes 2 sp3 (sles 10 sp4) and oes 11 sp1 both 64 bit

[gbaya]

Hi,

I have a Linux Server running in a Vsphere 5.0 infraestructure in a Datacenter with two hosts.
When I do a replica using Veeam Backup and Replica 6.1 from one host to the other, network adapter 1 with static IP address in source VM, becomes in network adapter 2 with dynamic DHCP IP address in target (replicated) VM

I want to keep the same IP address in replica.
How can I do?

Regards.

Gabriel.

[tom11011]

Hi Group,

I'm working on migrating our Citrix Netscaler VPX virtual machines from PRD to DR. Netscalers are BSD based.

The replication goes ok and the device will boot up on the DR side, however none of the licensed features will activate because Netscaler ties all this to a MAC address for licensing.

Is there a way this replica can retain its MAC address during replication? I went ahead and set the replicas mac address manually in vmware before booting it up and this does work, however, the mac address is overwritten on the next replication cycle.

Running the latest Veeam 6.1 plus patch1.

Thanks.

[tsightler]

Statically set the MAC address on the source VMs and after the next replicaiton the target VMs should have the same static MAC.

[stuartmacgreen]

@tsightler I have come to the conclusion that Manual MAC addressing is the only method to work when a replica or specifically SureBackup of my SuSE Linux Enterprise Server VM's takes place.
Let me summarize:

VM Guest OS: SLES11 SP3 x64
VM NIC: VMXNET3
VM NIC MAC: Automatic

In the OS:
rm /etc/udev/rules.d/70-persistent-net.rules
vi /lib/udev/rules.d/75-persistent-net-generator.rules
Add the lines
#ignore VMware virtual interfaces
ENV{MATCHADDR}=="00:50:56:*", GOTO="persistent_net_generator_end"

Surebackup of this VM is a success.

Now apply the latest OS patches, including kernel updates.

Patching complete and before rebooting check the status of persistent files.

75-persistent-net-generator.rules has been restored back to its original or latest and my entries above are not in the file.
70-persistent-net.rules has been generated.

Therefore the only proven way is with a Manual MAC addressing scheme for SureBackup to work seamlessly between patching.

Unless there is a .local file which survives patching when using Automatic.

[dellock6]

Hi Stuart,
udev rules are managed by /lib/udev/write_net_rules, you should look here for changing the behaviour of this.
I always had issues too with udev and network interfaces, one "quick and dirty" I used once is this:

- create a copy of the modified and desired /etc/udev/rules.d/70-persistent-net.rules to some where
- under rc.local I've placed two quick commands:
rm -rf /etc/udev/rules.d/70-persistent-net.rules
cp /WHERE-YOU-COPIED-THE-FILE /etc/udev/rules.d/70-persistent-net.rules

So at every reboot rc.local replaces the eventually modified udev rule with the desired one. Probably there's a better and official way to do it, but the dirty trick did the job.

[rurouni]

Hi,
I'm trying to Replicate SLES Vms on Veeam 9.5 and i'm having the issue with the replica losing Network Configuration.
The Configuration is as Follow:
Vcenter manages both Source Cluster and Replica Cluster, So by design it is set up to avoid Mac address Conflicts which leads to Replica Mac Address Change.
Portgroup and Subnet are the same on source and destination clusters, so there is no point using Remapping or Re-Ip Features here.
T
hat Said, when Replica Boots up, it considers the original Nic to be lost and populate the 70-persisent-net.rules file with a new ethX nic set on DHCP that leads to network configuration loss.

What is the proper/clean way to deal with this issue?

(From my point of view, the best deal would have been to keep the Replica as a mirror of the Source VM, keeping both MAC Addr and Network config)

Thanks.
Case is open: ID# 03132715.

Regards,

[rurouni]

Anybody has a clue about this issue? I guess many customers running Linux vms observed this behavour too.
Regards