Comprehensive data protection for all workloads
Post Reply
ekisner
Expert
Posts: 202
Liked: 34 times
Joined: Jul 26, 2012 8:04 pm
Full Name: Erik Kisner
Contact:

Feature Request - Automatic Host Targeting

Post by ekisner »

I'm not sure how much of a role vCenter plays in Veeam's way of doing things, but in the event that it's not a linchpin, it would be very interesting for jobs to be able to downgrade from targeting vcenter to enumerating the running VMs on the individual hosts and sourcing from the hosts when vCenter is unavailable. In that regard if "something" happens, you could still maintain a good level of operation. Certain things like tags wouldn't work, of course, but if you downgrade to hosts you could also look at the job history to find a list of "most recent" VMs in the backup.

I would imagine that it would involve recursively adding the hosts when you add the vCenter (and on subsequent rescans). Then when a job is running if it's unable to connect to vCenter for whatever reason, it could "faildown" to looking for the VMs on the hosts. One could certainly optimize it to store the current locations of the VMs, as they won't be moving around without vCenter, and such an operation would not be time consuming or intensive.

Would be an option to enable on the job.
foggy
Veeam Software
Posts: 21069
Liked: 2115 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Feature Request - Automatic Host Targeting

Post by foggy »

Thanks, Erik. The main question that comes to mind thinking of this is how VMs tracking should be done, since Veeam B&R tracks VMs based on their IDs, which are different in case of being registered in vCenter and directly on host.
ekisner
Expert
Posts: 202
Liked: 34 times
Joined: Jul 26, 2012 8:04 pm
Full Name: Erik Kisner
Contact:

Re: Feature Request - Automatic Host Targeting

Post by ekisner »

Ah yes, and that is where my knowledge of just how important vCenter is to the process is lacking - I honestly didn't know they had different IDs. I guess in theory you could just keep track of the VMX file and correlate it to the VM in the job; with the VMX file being locked by the host that runs it, it should be unique information.

For example, if said process were to occur, it would know that "vm01" has its vmx located in /vmfs/volumes/123-guid-123/vm01/vm01.vmx. All it would need to do then is connect to hosts, enumerate the running VMs and find the one with that VMX on it.

Edit:
Nope, that wouldn't work because that's only running VMs. Hmm.
Edit 2:
Well.. a deeper look into it shows that vim-cmd /vmsvc/getallvms will show all registered VMs. It didn't show any that weren't registered to other hosts. I'm not sure how it would behave if DRS was trying to re-register/restart VMs on different hosts.
Post Reply

Who is online

Users browsing this forum: sergiosergio and 268 guests