V9.5 - Guest disk usage

[reiso22]

Hi,
The new feature for monitoring guest disk usage for Hyper-V guests is a great improvement. However we are not able to get this information for guests which are part of a domain. There is always no data available. For guests which are not part of a domain it works fine. We already tried local users accounts in guest OS credentials without success. Any ideas what we might do wrong?

[Vitaliy S.]

Hi reiso22,

Do you set guest OS credentials on the individual objects (containers) or use global settings in the Veeam ONE Server settings?

Thanks!

[reiso22]

Hi Vitali,

Thanks for your prompt response. We tried with global settings and also tried setting guest OS credentials on the individual guest.

Best regards
Michael

[Vitaliy S.]

Do you specify users belonging to local administrator group or regular domain users?

[reiso22]

We specified users belonging to the local administrator group.

[Vitaliy S.]

Hmm... can you please let our engineers take a look at the debug logs? To do that, please open a support ticket with our support and let me know your case ID. I will review it with the devs.

[reiso22]

Hi Vitaliy,

We tested further and it might be a problem with our domain configuration. The Veeam One server and the hyper-v guests are members of domain A, but the hyper-v hosts are members of domain B. We have now established a trust between both domains, but still it doesn't work. From the DataProvider_HyperV.log we can see following error:

"ERROR Failed to create PSDirect connection (guest1.domainA on host1.domainB) System.TimeoutException:
at LoadHelper.PSInvoker.invokeImpl(Action`1 i_CmdAdd)
at LoadHelper.WmiOverPsInvoker..ctor(ConnectionHolder i_Parent, BaseLog i_Log, String i_ServerAddress, Credentials i_ServerCreds, String i_VmDnsName, String i_VmGuid, Credentials i_VmCreds, String i_Namespace)
at LoadHelper.ConnectionHolder.GetWmiDataProvider(String i_ServerAddress, Credentials i_ServerCreds, String i_VmDnsName, String i_VmId, Credentials i_VmCreds, String i_Namespace, Boolean i_TryDirect)

We have also enabled logon auditing on guest1 and at the same time of the above error message we can see a failed logon in security event log. From that error we can see, that the Veeam One server always tries to connect to guest1 using domainA administrator account regardless of what we have entered in guest OS credentials.

Maybe that helps to identify the issue.

Thanks
Michael

[Vitaliy S.]

Oh... trusts are mandatory, didn't know that you have such a config. Can you send these logs to review to our support team to confirm the credentials issue?

[reiso22]

It works now (maybe we did not wait long enough after establishing trust), but only when entering credentials in server settings.
We have mixed guests - some of them are part of a domain and some are not part of a domain. If we enter the domain credentials in server settings the guest disk usage reports fine for domain guests, but it no longer works for guests which are not part of the domain. If we enter credentials in server settings to match a user account for the guests outside the domain, then the domain guests are no longer working, even if we enter the domain account in guest OS credentials. So it looks like the entered guest OS credentials are not used at all - it always only works with credentials entered in server settings.

[Longclaw]

I am having a similar issue.

Veeam one sits on a specific VLAN, same VLAN as my hyper-v host servers.

We have various domains that are on other VLANs. I have entered Guest Credentials on our VMs that are outside of the host servers VLAN and the Guest Disk Usage is empty. No data available, it reads it for those that are on the same VLAN as the hyper-V hosts.

Are there specific ports I would need to open to those other VLANS?

We can see CPU Usage and Memory Usage with no problems on all VMs.

[Vitaliy S.]

Let us know if that works out for you. If this doesn't help, then I would recommend contacting our technical team. As soon as you do this, please let me know your case ID for tracking. Thanks!