Comprehensive data protection for all workloads
Post Reply
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Understanding proxy selection logic

Post by jimmyroot »

Hi all, apologies if I should be raising this as a support case first; It's just that I'm not sure whether this is a failing on my part or related to some part of proxy selection logic that I'm missing. I guess I'm seeking clarification on what SHOULD be happening in this case.

I have a strange inconsistency with proxy selection at a client's site. The setup is as follows.

vCenter with 3 x ESXi hosts running the majority of the client's VMs, 1 x standalone ESXi host with 3 smaller VMs;
Single node iSCSI Virtual SAN, to which all 4 ESXi hosts are connected
2 x proxy VMs (used mainly for replication jobs)
1 x physical proxy PC facilitating the backup repository in the form of a local disk (this PC is also attached to the iSCSI SAN)

I have the physical proxy configured for Direct SAN access with Fail-over to network mode enabled. I have restricted the job to just that single Physical proxy for the sake of troubleshooting this issue. Now for the weird bit...I cannot backup any VMs in vCenter with that physical proxy. The VMs fail with [ no proxy available ]. Now, remember I said there was a standalone ESXi server with a few odd VMs on it? Those VMs are in the same backup job, having been added through that standalone host as opposed to the other VMs which were added through their parent vCenter. The non vCenter jobs backup fine; the physical proxy is able to retrieve the data via Direct SAN access and it backs up those VMs as you would expect.

But the vCenter VMs fail. If I also tick one of the virtual proxies, or the Veeam Console Proxy (VMware Backup Proxy), in that job, then it will run, using network mode from the virtual proxy to backup the VMs (vCenter & Standalone ESXi). However, I need that physical PC to backup all VMs using Direct SAN access mode, but it looks like there is something preventing that job from assigning the physical proxy to process the VMs that are a part of vCenter.

Any suggestions? Or should I have just raised a support ticket straight away :mrgreen:
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot »

Raising a case then :) if anyone is interested I'll post the findings when resolved. Thanks for reading anyway.
foggy
Veeam Software
Posts: 21070
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Understanding proxy selection logic

Post by foggy »

Jimmy, are you saying that the job does not fail over to network mode (despite it is enabled in the proxy settings) but rather just fails?

Do you see VMFS volume in the Disk Management snap-in on the backup proxy server? Did you try to perform storage rescan in Veeam B&R console? Are you able to select VMFS datastore manually in the backup proxy server properties?
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot »

Foggy, thanks for the reply.

To the first question, yes the job does not fail over, but rather just fails with "Unable to create VM Processing task. Error: No proxy available". This happens for each VM that is connected to vCenter.

I leave the Virtual Disk Service (VDS) switched off on all my backup proxies as standard practice. This is to avoid the "Initialize Volume?" popup box that appears when connecting to an iSCSI target, so I'm unable to check Disk Management HOWEVER I can confirm that other VMs on the same storage can backup using Direct SAN via the proxy in question - the only difference is that they are on a host which is not joined to vCenter.

I can confirm that I've tried to select the datastore(s) manually in the proxy properties, and while I am able to select the datastore(s), it has no effect on the job :(

I have performed a storage re-scan, and performed volume discovery for vCenter and for the backup proxy in question. I can also confirm that the iSCSI session has been established, the target shows it's status as "connected" in the MS iSCSI Initiator properties, and the storage management interface shows the proxy as being actively logged into an iSCSI session.

I apologise if I'm explaining this in a complicated manner. I'm trying to be as concise as possible, I promise!
foggy
Veeam Software
Posts: 21070
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Understanding proxy selection logic

Post by foggy »

jimmyroot wrote:To the first question, yes the job does not fail over, but rather just fails with "Unable to create VM Processing task. Error: No proxy available". This happens for each VM that is connected to vCenter.
That means that network mode is also not available for some reason, so I suggest contacting support to verify your setup. I suspect some kind of configuration issue.
jimmyroot wrote:I leave the Virtual Disk Service (VDS) switched off on all my backup proxies as standard practice. This is to avoid the "Initialize Volume?" popup box that appears when connecting to an iSCSI target, so I'm unable to check Disk Management
This is not actually required since Veeam B&R automatically sets SAN Policy to Offline and disables disk automount during installation of the proxy server to prevent disks from being initialized.
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot »

This is not actually required since Veeam B&R automatically sets SAN Policy to Offline and disables disk automount during installation of the proxy server to prevent disks from being initialized.
Useful to know, thank you.

I've raised a support case. I suspect I may have missed something however I have several other clients running with an identical set up without issue. I'll post back when I figure out what's gone awry. Thank's for your input.
foggy
Veeam Software
Posts: 21070
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Understanding proxy selection logic

Post by foggy »

jimmyroot wrote:I'll post back when I figure out what's gone awry.
That would be much appreciated indeed. Btw, what is your support case ID?
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot »

Case ID is #00666107 :)
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot » 1 person likes this post

As promised, here is the answer...

It was, indeed, as mediocre and as much my fault as I suspected - after 40 minutes on the phone with a support engineer, we discovered that I had deployed a 32-bit Windows 7 proxy as opposed to 64, which is why the proxy was being ignored for jobs running from vCenter 5.5 (which now requires that proxy services be deployed on a 64-bit OS as a matter of course).

Thanks for the assistance everyone. I'll read the manual next time :)
foggy
Veeam Software
Posts: 21070
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Understanding proxy selection logic

Post by foggy »

Thanks for getting back with this. Glad you were able to get to the bottom of the issue.
jimmyroot
Influencer
Posts: 11
Liked: 1 time
Joined: Jul 04, 2013 11:36 am
Full Name: Jimmy Newman
Contact:

Re: Understanding proxy selection logic

Post by jimmyroot »

No problem, hope this is able to help someone else if they per chance encounter the same issue.
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 127 guests