resource not ready: source vmware host

[jbarrow.viracoribt]

The "cores-tasks" relationship is not "1 task = 1 core" thus all depends on how OS's (Windows) resource manager will disrtibute the load.

Thank you.

That seems to contradict what this shows though...



If it was all dependent how windows distributed the load, then why have this message here?

[PTide]

That message is just a warning, you still can set a number of concurrent tasks to whatever number you want, however it's recommended not to set the it larger than amount of cores.

Thank you.

[jbarrow.viracoribt]

So if this is set to 20, and the registry key mentioned here is set to the default 7, will I still see 20 concurrent tasks? I'm having a hard time understanding what exactly this key does or how it effects multiple jobs running or disks being processed at once.

[PTide]

So if this is set to 20, and the registry key mentioned here is set to the default 7, will I still see 20 concurrent tasks?

That depends on a transport mode.

I'm having a hard time understanding what exactly this key does or how it effects multiple jobs running or disks being processed at once.

The registry constraint of 7 NFC connections is in power if and only if you use an NBD mode. In other words, no more than 7 disks can be backed up from a single host simultaneously when using nbd.

In proxy settings you configure the maximum amount of disks that proxy may take no matter which mode is used. For example:

NFC = 7, proxy task limit = 12, transport mode = hotadd - 12 disks can be processed at once

NFC = 3, proxy task limit = 5, transport mode = nbd - 3 disks can processed at once

NFC = 3, proxy task limit = 2, transport mdoe = nbd - 2 disks can processed at once

Hope this helps.

Thank you.

[jbarrow.viracoribt]

We are using direct storage access for a transfer mode. We have FC connected physical proxies which talk to an FC connected NetApp FAS8020.

When I look at the job logs, I see that the source proxy is using SAN but then the target proxy is using NBD (even though it's set to SAN mode in Veeam under proxy settings).

I wonder why my target proxy isn't using SAN mode even though it's configured to do so?

How does the direct SAN method play into the numbers you shared above since we aren't using hotadd but we seem to be forced to use NBD on the target proxy?

[foggy]

Direct SAN on target has several limitations, for example, it can be used only during the first run of the replication job.

[jbarrow.viracoribt]

Okay, so this explains why we see it using NBD on the target every time then. Thanks!