Hello,
I recently had a host go into a disconnected state due to the VCDB growing too large. I've corrected that issue and got the host reconnected. My jobs are failing because it reports the VMs as being disconnected. (Processing <vm> error: VM '<vm>' (ref: 'vm-63') is 'Disconnected')
After correcting the issue on the vSphere side I reran my jobs. They all failed again because they report the VMs as being disconnected. This is VERY frustrating. The VMs are NOT disconnected, from my point of view, because they are within the vCenter folder that is assigned to the job. If I open the job and click Virtual Machines > Recalculate the job setup detects the folder correctly and registers a value for Total Size. Yet, the job STILL fails because it says the VMs are disconnected. No, they are not.
The reason I chose to use folders instead of individually selecting VMs is so that B&R would simply backup all VMs in the folder.
Why does this happen? Why doesn't it pick up the VMs in the folder?
-
- Expert
- Posts: 231
- Liked: 18 times
- Joined: Dec 07, 2009 5:09 pm
- Full Name: Chris
- Contact:
-
- Expert
- Posts: 231
- Liked: 18 times
- Joined: Dec 07, 2009 5:09 pm
- Full Name: Chris
- Contact:
Re: Feature request: More robust VM selection
For anyone reading this later, the manual fix (that I didn't mention originally) is to remove and then re-add the vCenter folder. You don't even have to save the change before re-adding nor do you need to write down the existing exclusions because they are not wiped out. Just remove and re-add.
It seems like an oversight from Veeam to require this step after a host gets disconnected. I see the user of folders in B&R just like I do DNS. I don't care when a website changes an IP address. That's what DNS is for. Similarly, I shouldn't have to care when a VM's internal ID changes when I'm using folders. B&R should take care of that for me.
It seems like an oversight from Veeam to require this step after a host gets disconnected. I see the user of folders in B&R just like I do DNS. I don't care when a website changes an IP address. That's what DNS is for. Similarly, I shouldn't have to care when a VM's internal ID changes when I'm using folders. B&R should take care of that for me.
-- Chris
-
- Chief Product Officer
- Posts: 31816
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Feature request: More robust VM selection
Hi, Chris - wrong conclusion on your part here I am afraid if you did not save the change, then removing and readding makes no difference to the job settings, as the existing job configuration is not touched. In reality, looks like something else has happened in vCenter in parallel with your doing so, and then jobs simply started working. For example, Inventory Service may sometime take extended time to update, and until this happens - VMs will be shown as disconnected (vCenter knows they "were" there before, but no longer sure they are "still" there until they are all re-queried). Thanks!
-
- Expert
- Posts: 231
- Liked: 18 times
- Joined: Dec 07, 2009 5:09 pm
- Full Name: Chris
- Contact:
Re: Feature request: More robust VM selection
This is what I meant.
1. Edit job.
2. Remove folder.
3. Re-add folder.
4. Save.
Sounds like you thought I meant:
1. Edit job.
2. Remove folder.
3. Re-add folder.
4. Close properties without saving.
1. Edit job.
2. Remove folder.
3. Re-add folder.
4. Save.
Sounds like you thought I meant:
1. Edit job.
2. Remove folder.
3. Re-add folder.
4. Close properties without saving.
-- Chris
-
- Expert
- Posts: 231
- Liked: 18 times
- Joined: Dec 07, 2009 5:09 pm
- Full Name: Chris
- Contact:
Re: Feature request: More robust VM selection
How much time are you talking here? My environment is very small (2 hosts, ~25 VMs) and many minutes passed between fixing the issue and the start of the successful retries.Gostev wrote:For example, Inventory Service may sometime take extended time to update,...
-- Chris
Who is online
Users browsing this forum: Google [Bot] and 37 guests