Failed to create NFC download stream

[d117403]

Hey,

This Problem here is on every server, witch i'd like to backup
I use esxi v4.0.0



0 of 0 files processed

Total VM size: 30.03 GB
Processed size: 0.00 KB
Processing rate: 0 KB/s
Backup mode: agentless
Start time: 18.02.2010 15:04:19
End time: 18.02.2010 15:07:41
Duration: 0:03:21

Retrieving VM files information
Failed to retrieve "SCSI (0:0) Festplatte 1" disk information. Check VM virtual hardware configuration.
GetLocalText failed
Client error: NFC storage connection is unavailable. Storage: [stg:datastore-4442,nfchost:host-5546,conn:172.16.1.10]. Storage display name: [hp-disk03].
Failed to create NFC download stream. NFC path: [nfc://conn:10.10.10.10,nfchost:host-5546,stg:datastore-4442@server/server.vmdk].

Server error: End of file


Thank You

[Vitaliy S.]

Hello Habib,

It seems like there is a connectivity issue while retrieveing information on your VMDK files from the source storage. Are you able to download any file from your source datastore using Virtual Infrastructure Client?

Also for all technical issues I encourage you to open a support call with us by sending all the logs for investigation, our technical team will be able to assist you better having all logs in hands.

Thank you!

[d117403]

Hello Vitaliy,

Yes I can donwload files from the storage with Virtual Client, and it work also wo copy files with veeam scp.
But to create a Backup with Veeam Backup is not Possible.

Do you have an other tipps or tricks?

kind regards
habib

[Vitaliy S.]

Habib, please contact our support team, so they could look at your issue more effectively.

[d117403]

Can I contact it also with a evaluation licence, because it is only a test for a new backup software...

[Gostev]

Yes, absolutely.

[neurosis]

Hello,

This problem was resolved ?
I have the same issue on my platform and don't find where it may come !

Best regards.

[Gostev]

neurosis, could you please also contact our support with logs. Thank you.

[d117403]

i contac't the support last week on monday, but i haven't got a answare until now.

[Gostev]

Habib, this is normal as support cases from evaluators have lower priority than ones from paid users. But I thought you only submitted on Thursday 18th according to the thread above? What is your support case number?

[epruess]

Not sure if this applies to ESXi as well but I have been experiencing this problem in an ESX/VCENTER 4 environment for a couple of weeks now and just found the solution. When we upgraded from Vcenter 2 to 4 it put some of our Datastores in a separate folder with different permissions. Apparently the account used for the VEEAM service also needs to have enough rights to the datastore in VCenter. Once I gave the account admin rights in VCENTER we no longer got NFC errors. I sent logs to VEEAM support and they were positive this was because port 902 was not open. We had no firewall so I knew this was not the case. Support materials may need to be updated.

Eric

[Gostev]

Thanks for sharing this Eric!!!

[Jax]

Hi

I have the same issue with copying from an ESX4 to an ESXi4 - however when I built the ESXi host and used the dhcp address given to it and no domain name, I could copy to the store attached to it. Only after adding the host name and a static address does it fail.

Any ideas what is wrong and how I can get it working?

Thanks

[Vitaliy S.]

Hello Eric,

Could you tell me if you are able to upload/download any file using Datastore Browser with the hostname and static IP address configuration?

On top of that, as far as I know, you always need to have a name for the host, it simpy cannot be installed without using either a default name or a specified one during the setup process.

Thank you!

[Franco13]

>Only after adding the host name and a static address does it fail.

Sorry a little late, but i just had the same issue with a static address here.

I solved it by adding an entry for the ESXi Host to the hosts file of the backup server (with veeam running on).

[Gostev]

Thank you for posting the resolution! So this ended up to be DNS issue...

[Matt-WGSB]

I just ran into the same issue on Veeam 5.0.2. The Veeam server was not added to the domain, though it was statically configured to look to the correct DNS server. I added it to the domain and a retry was successful. 2 cents in case it helps anyone else.

[Andreas Neufert]

Had the same issue at a POC.

It was a DNS Error.
Backup Server and VCenter DNS worked, but on the Proxys the ESX Hosts where not resolved.

[Andreas Neufert]

At another customer it was caused by a special character in datastore name.

[dellock6]

Andreas, it happened right today at a customer too, some "genius" from another System Integrator following this customer before me configured one of the datastores with an exclamation mark in the name......

Luca.

[Gostev]

Was it named like "DO NOT DELETE!!!" or something?

[tsightler]

I had a client with a datastore named something along the lines of "Old & Slow - No New VMs!"

[dellock6]

No kidding, it was:

!Backup only! Do not place VMs here!

Right as I wrote it here (well, was in italian to be honest, but that's the exact translation)

[Ben Milligan]

A bit of a deeper dive on this for you folks in the field. Our source agent logs will many times point directly at the culprit if it is an issue of ports/permissions/DNS. These are the most common reasons we see this behavior.

IE: Agent.JOBNAME.Source.log:
Look for: "Creating NFC download stream"

You'll first see the host and port the agent is attempting to communicate with:
Host: [Test-vc01]
Port: [443]
Successfully logged in ( server: [Test-vc01], user: [test\bmilligan] )

This is the control connection above to the vCenter. Next you'll see the NFC connection to the host being made as determined by vCenter:
Native NFC file path: [[SAN-Test-LUN1] TestVM/TestVM.vmx].
Reconnecting to the NFC storage. Storage: [stg:datastore-25648,nfchost:host-458,conn:test-vc01]. Display name: [SAN-Test-LUN1].
Preferred NFC server: [host-458].
Connecting to NFC session. Target host: [ESX1.test.local]. Storage: [SAN-Test-LUN1]. VI SOAP connection ID: [test-vc01].
NFC service: [vpxa-nfc]. Port: [902].

If you see "failed" next to this line: Establishing connection with the host [ESX1.test.local]. Port: [902]., it's fairly clear you need to modify your firewall.

Next, you'll see the hostname DNS resolution attempt:
Resolving host name (ESX1.test.local) to IP address...


If you see failed next to the above line, you need to update your DNS records so that host is resolvable from the source proxy.

Lastly, you'll see the file begin to download:
Starting file download. File: [[SAN-Test-LUN1] TestVM/TestVM.vmx].

When it fails here, we're talking permissions to download the file at this point. As you can see, all three problems are fairly clear in logs context.

Hope this helps!

[Ben Milligan]

Oh! Forgot one thing. You'll see this in the target agent log when there is an upload failure during replication job from target proxy to target host/datastore, as opposed to source agent log.

[cackerson]

"Connecting to NFC session. Target host: [ESX1.test.local]. Storage: [SAN-Test-LUN1]. VI SOAP connection ID: [test-vc01].
NFC service: [vpxa-nfc]. Port: [902].[/i]

If you see "failed" next to this line: Establishing connection with the host [ESX1.test.local]. Port: [902]., it's fairly clear you need to modify your firewall."

Ben - have the same issue and support told me to modify my firewall. But they could not tell me what firewall. Do you mean a Windows firewall? On the Machine being replicated or the proxxy? Or do you mean a firewall across a WAN link?

[Ben Milligan]

Sorry for any lack of clarify here.

Port 902 needs to be open between the Source Proxy and the source ESX(i) host where the VM you are backing up/replicating resides. It would also need to be open between the target proxy and target ESX(i) host on destination side for replication. Most times this is a Windows firewall or router in between the source proxy and source host that is disallowing the traffic. You can open vSphere client and use datastore browser to test file copies to/from the datastore to your Windows server running as the Veeam Backup source proxy for manual testing as it uses the same port. Once this is working then the job should not throw this error any more.

[cackerson]

After getting the Port: [902] error message mail failback did not work. I now have a "Veeam Replication Failback Snapshot" in my Snapshot Manager in Vsphere Client.

Is it ok to delete this snapshot?

[Ben Milligan]

Craig - that snapshot is likely not filled with good data. It resides on the original source machine, and contains the failback data (changes) from the replica. You could revert to that snapshot, to ensure it is good/bad, then delete if its not needed. If it failed during the data transfer, which is likely considering a block on port 902, the snapshot likely contains no information. In that case, its OK to delete the snap, and retry the failback after port 902 is confirmed open between target proxy and target host.

Hope this helps!

[Dwayneair]

I posted on an older Post with very similar issues, and the Administrator pointed me here.
After placing a service request for the same error message, we were able to find out that one of the Hosts was backing up with no issues but any of the others would result in this same error. 1) Checked DNS on all components and Proxies and yes we had a typo in the Host files for Host ESX1 and ESX2 (the 2 problem children). Fixed it.
But now only a couple of the backups work and nothing was working from Host ESX3 ???? so we then 2) disconnected a mapped drive (N:) to the repository (my NAS), I guess there are issues when you do this on the Veeam Backup server. and 3) Recreated the backups but selected the Virtual servers from the Standalone Host objects instead of the VCenter object. Now everything seems to be working fine. Although I have yet to test vmotioning one of the servers over to a different Host and seeing if the backup will follow or error out.