-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Understanding proxy selection logic
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
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
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
Raising a case then if anyone is interested I'll post the findings when resolved. Thanks for reading anyway.
-
- Veeam Software
- Posts: 21138
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Understanding proxy selection logic
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?
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?
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
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!
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!
-
- Veeam Software
- Posts: 21138
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Understanding proxy selection logic
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: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.
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 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
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
Useful to know, thank you.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.
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.
-
- Veeam Software
- Posts: 21138
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Understanding proxy selection logic
That would be much appreciated indeed. Btw, what is your support case ID?jimmyroot wrote:I'll post back when I figure out what's gone awry.
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
Case ID is #00666107
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
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
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
-
- Veeam Software
- Posts: 21138
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Understanding proxy selection logic
Thanks for getting back with this. Glad you were able to get to the bottom of the issue.
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Jul 04, 2013 11:36 am
- Full Name: Jimmy Newman
- Contact:
Re: Understanding proxy selection logic
No problem, hope this is able to help someone else if they per chance encounter the same issue.
Who is online
Users browsing this forum: Bing [Bot], Google [Bot], Semrush [Bot] and 129 guests