Veeam connects to wrong ip address on Linux agent

[mlott@gie.com]

Open case 02060405. I searched and found this happening for others here:

We have a Linux VM to which is attached a snapshot for another server. This is connected via a private network for iSCSI. We are trying to do a files to tape backup, not a VM backup.

When Veeam attempts to backup this server, it connects to the other interface which is on the server network common to Veeam and this VM. The agent gets pushed and is running. However, Veeam tries to connect to the agent on the other ip address on the private iSCSI lan and of course fails.

I checked the hosts file on the Linux machine and neither ip was listed. I added the 'public' ip address there, which did not help.

I added the server ip address to the hosts file on the B&R server, which also did not help.

Error in the job log is "Failed to connect to agent's endpoint 'ip.ad.dr.ess'. Host: 'host.name'."

I suppose I could add that network on a secondary interface on the Veeam server. But... why?

[mlott@gie.com]

FYI, eth0 is the server LAN interface and eth1 is the iSCSI LAN.

[PTide]

Hi,

We have a Linux VM to which is attached a snapshot for another server. This is connected via a private network for iSCSI. We are trying to do a files to tape backup, not a VM backup.

When Veeam attempts to backup this server<...>The agent gets pushed and is running

PLease clarify whether you're trying to backup the VM with Veeam B&R or with Veeam Agent for Linux?

Thank you.

[mlott@gie.com]

I am only using the Veeam Agent in the sense that B&R pushes out a temporary agent during the backup. This is a B&R file to tape job...

[mlott@gie.com]

If I add an interface on the B&R server to the iSCSI network, it does get past the error. However, as soon as the enumeration hits a link to a non-existent file, the agent segfaults.

[mlott@gie.com]

I was able to backup a single file. It just can't make its way through the directory enumeration...

[mlott@gie.com]

I can also backup if the LUNs on the Linux server are not mounted.

[PTide]

Error in the job log is "Failed to connect to agent's endpoint 'ip.ad.dr.ess'. Host: 'host.name'."

That happens because temporary agent passes all available IPs on interfaces to VBR, in your case agent sees eth0 and eth1 IPs and VBR attempts to connect to an IP that is assigned to eth1.

We have a Linux VM to which is attached a snapshot for another server.

I'm not sure what does that part mean? Did you attach a vmdk from another VM's snapshot and are trying to backup files from that snapshot vmdk to Tape?

Thank you

[mlott@gie.com]

The source machine is a VM but I am not handling it as a VM, so vmdk files and vmware snapshots are not in play.

The snapshots mounted on the source VM are from our SAN. They are a point in time snapshot to be used for backing up our fileserver. The fileserver is a physical machine with FC connectivity to storage. The snapshots are accessed from this separate VM so that we don't put undue load on the fileserver itself.

As far as I am concerned, Veeam should only see this VM as a physical machine since we are doing a file to tape backup, not a VM backup. I can browse the files all day when setting up the job or when looking at the FILES tab in the Veeam console. The VM was added as a managed Linux server in the BACKUP INFRASTRUCTURE tab. This was required in order to be able to select the server and its folders and files.

[mlott@gie.com]

Note that for some unrelated reason, I cannot browse files if I setup the file server itself (centos 7) as a managed server. Also, we do not have sufficient space to sync the entire file server to an intermediate disk.

[PTide]

I cannot browse files if I setup the file server itself (centos 7) as a managed server.

That is probably due to the lack of perl modules.

I was able to backup a single file. It just can't make its way through the directory enumeration...

This has to be investigated by our support team, please keep working with your support engineer.

Thank you

[mlott@gie.com]

As far as the server that seems to crash, I unpacked veeam_soap.tar there and was able to run the veeam_soap.pl script without error (or any output). Perhaps it is dynamically including additional modules that are missing during its run.

Support is working with us on the backup to tape issue. Since both file copy and file to tape jobs should use the VeeamAgent64 exec, they are not yet sure why the tape job causes the segfault when enumerating files.

[mlott@gie.com]

From support, based on other cases and what was done to fix this issue, I installed and started running nscd. I don't understand that at all. But, it fixed the problem. The tech said there were looking at removing that requirement for use with NAS devices that might not be able to run this or be modified to do so.

[mlott@gie.com]

Unfortunately, this all ultimately failed because of the massive volume of files on this server. Files to tape was apparently not designed for such a large volume of files. I don't know what the actual limits are but I guess we exceeded them at around 65000 files during enumeration. This varied depending on the subset of data chosen.

[PTide]

I installed and started running nscd

You have installed it on the VM that has SAN snapshot mounted, is that correct?

I guess we exceeded them at around 65000 files

File to Tape job limit is way higher, it goes to tens of millions of files, but the real figure depends on the amount of available resources. What are the specs of the VM that you use?

Btw, have you tried to use Veeam Agent for Linux to perform a backup of that CentOS fileserver?

Thanks

[mlott@gie.com]

Yes, nscd was started on the machine with the snapshots.

I was told otherwise by support. But, not with any detail as to file count. It was just an ambiguous suggestion that it really wasn't designed for this... The fact is that we never exceeded available resources that I could see. It just bombs during enumeration.

[Dima P.]

Hi Miles,

After checking with our QA folks we found a proper fix for your issue. I asked our support folks to reach you, so please let us know how it goes.

[Delphius]

Referring to support case 02114713.

I also have this issue when trying to do backup using Linux agent.
OS: Ubuntu 14.04.5 LTS

[andyg]

Error in the job log is "Failed to connect to agent's endpoint 'ip.ad.dr.ess'. Host: 'host.name'."
That happens because temporary agent passes all available IPs on interfaces to VBR, in your case agent sees eth0 and eth1 IPs and VBR attempts to connect to an IP that is assigned to eth1.

What is the fix for this, I have the same issue and I tried setting the "preferred network", but its still trying to use the wrong ip to backup.
I have opened Case # 02259574