Minor VBR enhancement ?

[TheOnlyWizard17]

You have a Job backing up several VMs. You have enabled Guest Processing. For some VMs, you've created and setup different from the <default> credentials. Much later, you remove those VMs (with different creds) from the Job, because the VMs got decommissioned. If you then try the "Test Now", Veeam will still try to use and connect to those VMs that were removed, since the credentials are still there. Perhaps it would be handier to automatically remove the credentials used for the VMs you remove also from the credentials-list, so clicking Test Now (because you added several new VMs later) will not try to test the "old and long gone" VMs anymore... ?

[Gostev]

Normally, Test Now should only be testing VMs that are added to the job. If you don't have the VM added to a job, but Test Now functionality still attempts to connect to them, then it is really strange and we will want to take a look at what's causing this closer (please open a support case and share the log).

[TheOnlyWizard17]

"Test now" still tries those VMs, because credentials for them are still under "Credentials" button (they don't seem to get removed when you remove the VMs). Now I've deleted those aswell, "Test Now" doesn't try the removed VMs any longer... I don't know if this is only true when you have VMs setup to use different then <default> credentials, or it would be the same with them aswell... I've only seen it with "special" dedicated creds for those VMs.

[TheOnlyWizard17]

It's even more funny than that, because the tested VMs (reminder: These VMs are removed from Job, Backup, entire VBR, even the entire Hyper-V cluster that gets backed up) list in details as:
The only existing reference (afaiao) to them is the creds under "Credentials" button

√ Finding VM reference on host S2D.<domain>
√ VM reference: <guid>
X Collecting guest OS info. Error: Failed to get VM's IP addresses.
√ VM is powered on
√ IP addresses: n/a
√ Guest OS: Unknown Operating System

[Gostev]

So after multiple attempts on various V10 and V11 configuration, our QC could not reproduce this issue internally. So, they would like to see the logs next. Could you please open a support case, and let me know the case ID? Thanks!

[TheOnlyWizard17]

Hi Gostev,

It turns out we were both right
Yes, normally VBR will clean up Creds for VMs you remove from the job. In my case here though, it seems VBR gets confused when there's an invalid VM-reference in the Creds-list somehow. There was yet another VM which uses non-default Creds in the Job and on the Creds list, which I don't want to remove, but turned out to be the real problem. I started by capturing 1.1GB of logs, then set out to document the case with explanation and screenshots and re-validate my sanity In doing that, I noticed that when I deleted some VMs with non-default Creds, the Creds remained. But then adding those VMs back (because I don't REALLY want to delete them, just testing) I noticed that the VMs were added to the Creds-list, but also that this culprit VM was also added again to the Creds-list, and now was listed twice in Creds, while it was not even one of the VMs I was adding !
I solved this issue by deleting that culprit VM from the job, and manually deleting the 2 Creds from that VM, then re-adding it, setting correct Creds. Since then, I'm not able to re-produce the initial reported issue. Nevertheless, if you have Creds in the list that don't belong, and do Test Now, it still is doing the test on the VM, and even if the VM doesn't exist, it will say that the VM is powered on !
Don't know support still wants to look at it, I still have the logs captured while the issue was still present, so perhaps it could help them ? Just in that case, I opened support-case #04703311.
How the invalid VM-reference ended up in the Creds-list ? No idea. These jobs were cloned from one another, as not having to fill out those non-default Creds for several VMs over and over. Later, the culprit VM was also renamed (from Hyper-V itself), so perhaps that expains it somehow.

[Gostev]

Thanks a lot, passed the case to them.