Once per day getting event id 10019 with description "Hostact_iscsi_loop with id 18 is not TRUSTED. please update/initialize certificate." Doesn't seem to be anything in documentation about this error. Any way resolve?
Can you check the host certificate status, and if it is not valid, refer to the following link to restore trust in the host
I have never setup a certificate. All the host certificates say N/A in their status field on the hosts page. I am using only Compute Engine VMs with snapshots currently. Is this certificate necessary?
For GCE VM backups, it is not required to install a connector. However, for connector-based backups, the user needs to install the connector on the host. While adding the host in the management server, the user needs to provide the certificate.
Hi @llegras ,
We are getting same Event Error here.
We recently updated the Backup and DR Appliance to patch version patch-11.0.11.342. Since then, this Event Error has persisted and continues to alarm daily. Google's documentation does not offer any recommendations yet.
Have you already solve it?
Warning / Error - Event ID: 10019
Error Message: Hostact_iscsi_loop with id 18 is not TRUSTED. please update/initialize certificate.
What to do: No recomedation on Google Backup and DR.
I have not been able to solve it yet, hoping someone will be able to provide some guidance here or a new patch will fix it.
Ideally host should not be in not TRUSTED state, to over come this refer
I'm seeing the exact same error (even the specific iSCSI id 18), and this is not a host in my projects. Seems like a default reference to the backup appliance.
Same error here, backups silently stopped working on august 3rd. It is impossible to edit host (you know, impossible cause... certificate unknown), and the only possible action for the appliance is delete.
Not happy at all. I was sceptical using the console because of a rather clunky GUI, but this is clearly unacceptable.
No need to delete the application, Following steps will help to restore trust
In the management console, click the Manage drop-down menu and select Hosts.
The Hosts page appears listing known hosts, including their certificate status.
Right-click the host and select Edit.
Go to Backup and DR Agent Settings in the Edit Host page.
Open the section by clicking the label.
On the host, change directory to where the UDSagent
binary is located and run the following command:
udsagent secret --reset
Copy the output and paste it into the Secret field.
Click Save.
Thank you for your answer, but when trying to follow your instructions a certificate error prevents to access the "edit host" page:
Also, how would I know where the `udsagent` binary is installed? We never installed an agent, we are relying on disk snapshots and the base idea I got from the tutorial videos was that no action was needed on the host itself, as the system performed disk snapshots through the GCE API
GCE VM backups do not require the installation of a connector. If your cloud credentials are using JSON key, please be aware that organizational policy may enforce an expiration date on these keys. To address this, refer to the following link to replace your JSON key cloud credential with an appliance service account credential
The issue was due to the appliance being corrupted. I has to create a new appliance and re-enroll every single application.
Thank you for your help.
I have same issue, my appliance got connectivity status "stale" after 06 august.
I want to delete it and create new one. Instruction says, that I should delete backup plan before deleting Appliance:
How did you delete it? I've got Error message if I try to delete backup plan.
I can't remember exactly but I believe I just removed the appliance altogether in the DR console, which IIRC removed every object that was linked to it. It was OK on my side because we were not yet in production, so I had not a huge list of applications to re-enroll.
Thanks for help. Removing appliance solved the problem.
Hi,
We're facing the exact same error message and already reset the secret as suggested in your answer but unfortunately still receive the same error message.
We mainly use the Backup&DR appliance for backups of GCE VMs but have one VM which runs a database which we've backed up so far via the UDSAgent.
We've upgraded the Backup&DR appliance as well as the UDSAgent to the newest version.
Any further suggestions how we could fix this issue, as a redeployment of the whole Backup&DR appliance isn't an option for us.
Thank you in advance!