Using guest interaction proxy ...

[marius roma]

A backup job reports a message saying "Using guest interaction proxy x.y.z.t (Different subnet)".
The job is copying a VM from a subnet where the vSphere infrastructure is located to a different subnet where the NAS is located.
The problem is that x.y.z.t is the proxy used for replicas and that it is located in a different site...
I specified to use the proxy on the Veeam server itself instead of the the remote proxy, but it is used anyway!!!
How can I avoud such problem???
Regards
Marius

[foggy]

Mario, the message is talking about guest interaction proxy, not the proxy server that actually retrieves data from the source storage. You can select the guest interaction proxy at the Guest Processing step of the job wizard.

[marius roma]

Thank you for your message.
I don't see any option to select the guest interaction proxy at the Guest Processing step: whre is it?
Regards
Marius

[veremin]

Here it is.



Thanks.

[marius roma]

Thank you for your message.
I run B&R 9 Standard and I don't see the option you mention.
Should I enable/disable anything?
Regards
marius

[jmmarton]

This requires enterprise or enterprise plus.

https://www.veeam.com/backup-version-st ... rison.html

Joe

[marius roma]

Thank you for your clarification.
Given that we use Standard version, how can I avoid that a proxy in another site can be used as guest interaction proxy?
The only solution I found is powering down the remote proxy, but it impacts over replicas and it does not look to be a smart solution...
Regards
marius

[foggy]

Well, this is actually an already known issue, where in Standard edition the guest interaction proxy selection algorithm from higher editions is triggered, instead of just assigning this role to the backup server itself. Will be addressed in the next update. That wouldn't hurt anyway, you just get this functionality for free, however, I wonder why still the server from a different network is selected, while you have backup server in the same network where your VMs reside (do you?). That is better to be addressed to support.

[EBoucq]

Hi,

Using Veeam v9 Standard Edition, I don't understand why I see "Using guest interaction proxy <server name>..." in my jobs knowing the option isn't even available when I set them up.
When I check the services on the server <server name>, I see that "Veeam Data Mover Service" and "Veeam Installer Service" are running.

Can someone explain to me how this is possible (I didn't install Veeam) and how I can uninstall this guest interaction proxy on this machine ?

Thank you.
Eric

[Gostev]

Hi, Eric

Just remove this server from the list of Managed Servers on the Backup Infrastructure tab, this would do.

Thanks!

[foggy]

Was a known issue back in v9, see above.

[RockemSockem]

...however, I wonder why still the server from a different network is selected, while you have backup server in the same network where your VMs reside (do you?). That is better to be addressed to support.

Hey gang. I'm a long-time lurker and ProPartner who has now moved to an internal job. (I'm sure I had an old login somewhere but have no idea where it went.) Sorry to dig up an older thread, but I figured a new topic might get merged anyway. (mods, split it out if you see fit)

I'm on 9.5 U3a (Enterprise Plus) and am still seeing an interaction proxy from a different subnet selected when the master backup server is L3 adjacent to the guests and gets selected for some of the VMs in the job but not all. Support said that the remote interaction proxy was selected due to load, but the 9.5 documentation states that selection based on load is only performed *within* the same priority tier not *between/among* different priorities. Is anyone else still seeing this? Explicitly defining the guest interaction proxy for each site's respective jobs is not something I want to do when the intelligence exists in the product and I've seen it work properly before in my previous implementation life.

Case 03156465

[foggy]

Hi Phil, agree, according to the documentation this behavior is not expected, I'm checking the possible reasons for what you're seeing...

[RockemSockem]

Alex, we came across something interesting looking at the VM task logs. All of the other VMs had lines that were testing the guest IP/mask against the available managed servers' interfaces, but the symptomatic VM was missing such lines in the task log:

Local GIP selected for VMs "A" through "C"

Code: Select all

[21.08.2018 10:02:07] <68> Info     [VssProxyHelper] VSS proxy is needed: VSS is enabled
[21.08.2018 10:02:07] <68> Info         Testing vss proxy ip [10.x.y.z], netmask [255.255.255.0]
[21.08.2018 10:02:07] <68> Info             Testing vm ip [172.a.b.c]
[21.08.2018 10:02:07] <68> Info         Testing vss proxy ip [10.x.y.w], netmask [255.255.255.0]
[21.08.2018 10:02:07] <68> Info             Testing vm ip [172.a.b.c]
[21.08.2018 10:02:07] <68> Info         Testing vss proxy ip [172.a.b.d], netmask [255.255.248.0]
[21.08.2018 10:02:07] <68> Info             Testing vm ip [172.a.b.c]
[21.08.2018 10:02:07] <68> Info             Vss proxy host [<veeammaster>] - IP address [172.a.b.d] is in the same subnet as Vm IP [172.a.b.c]. Subnet mask [255.255.248.0].

Remote GIP selected for VM "D"

Code: Select all

[21.08.2018 10:18:39] <62> Info     [VssProxyHelper] VSS proxy is needed: VSS is enabled
[21.08.2018 10:18:39] <62> Info         Testing vss proxy ip [10.x.y.z], netmask [255.255.255.0]
[21.08.2018 10:18:39] <62> Info         Testing vss proxy ip [10.x.y.w], netmask [255.255.255.0]
[21.08.2018 10:18:39] <62> Info         Testing vss proxy ip [172.a.b.d], netmask [255.255.248.0]
[21.08.2018 10:18:39] <62> Info         Testing vss proxy ip [172.a.b.f], netmask [255.255.248.0]
[21.08.2018 10:18:39] <62> Info     Vss proxy host <veeammaster> and Vm are not in the same subnetwork

Quite peculiar.

I'm trying to determine where to look. Maybe DNS? Are PTR records used in this process? I do need to do some DNS cleanup on this site. I'll check to make sure they are all pointed to the local site's resolvers while I'm at it, too.

[foggy]

Hi Phil, I've confirmed the fact that guest interaction proxy selection doesn't depend on the load and proxy from the same network should be selected, if available. Please continue looking into this with the help of your support engineer. Thanks.

[RockemSockem]

So, we've determined that it's definitely an issue with what the tool stack returns as the singular primary address that is populated in guest.ipaddress. This makes it not a problem with the job engine but with the data presented by the guest tools. (In other words, not a Veeam issue. Fanfare and confetti!)

However, relying on the tool stack to pick the single proper guest IP address when:
(1) the probability of multiple guest IPs being present is high, and
(2) the probability of the tool stack correctly identifying the primary guest IP address (in the context of guest interaction) is low
is not doing any favors to the intelligence built into the job engine to actually select the proper GIP.

Perhaps an enhancement request to enumerate all the guest IPs reported in guestnicinfo is in order? I realize that would draw out the testing process for each task, but it would "round out" the GIP selection intelligence and make it self sufficient - and thus much more accurate and useful. Some IPv6 support in there couldn't hurt, either... <nudge nudge, wink wink>