Hello everyone, I have an issue and hope you can help me. I have some virtual machines that need to undergo some OS patches. I chose to use VM Manager to handle this. I've completed all the agent configuration requirements on the VMs, but when I run the job, it returns an error at the end with a status indicating that no agent was detected.
While troubleshooting on the VMs, the agent is running.
I've gone through the entire documentation here: https://cloud.google.com/compute/docs/troubleshooting/vm-manager/verify-setup?hl=pt-br#windows_3 And the results always match the expected outcomes in the documentation.
Any solutions for this issue?
Hi @cirne,
Welcome to the Google Cloud Community!
Please run the command below so we can see the full error:
gcloud compute os-config troubleshoot {VMINSTANCE} --zone={ZONE} --verbosity debug
Change {VMINSTANCE}
to your instance name and {ZONE}
to where the instance's zone is.
One of the most common cause of issue of this is the service account connected to the instance doesn't have the necessary permissions, kindly add these roles to the service account[1].
roles/serviceusage.serviceUsageConsumer
roles/compute.osLogin
roles/osconfig.inventoryViewer
Next, check if your VM's metadata has this osconfig-disabled-features=tasks
, if it does, kindly remove it, then retry running the OS Patch job again.
If the above options don't work, you can contact Google Cloud Support to further look into your case. Thank you!
Hi, Lawrence.
This is result from troubleshooting command:
cirne@DESKTOP-MDDDJIS:~$ gcloud compute os-config troubleshoot cs-dev-bld-02 --zone=southamerica-east1-b --verbosity debug
DEBUG: Running [gcloud.compute.os-config.troubleshoot] with arguments: [--verbosity: "debug", --zone: "southamerica-east1-b", INSTANCE_NAME: "cs-dev-bld-02"]
DEBUG: Making request: POST https://oauth2.googleapis.com/token
DEBUG: Starting new HTTPS connection (1): oauth2.googleapis.com:443
DEBUG: https://oauth2.googleapis.com:443 "POST /token HTTP/1.1" 200 None
OS Config troubleshooter tool is checking if there are issues with the VM Manager setup for this VM instance.
DEBUG: Starting new HTTPS connection (1): serviceusage.googleapis.com:443
DEBUG: https://serviceusage.googleapis.com:443 "GET /v1/projects/cs-prj-dev-portal-assinaturas/services/osconfig.googleapis.com?alt=json HTTP/1.1" 200 None
> Is the OS Config API enabled? Yes
DEBUG: Starting new HTTPS connection (1): compute.googleapis.com:443
DEBUG: https://compute.googleapis.com:443 "GET /compute/v1/projects/cs-prj-dev-portal-assinaturas?alt=json HTTP/1.1" 200 None
DEBUG: Starting new HTTPS connection (1): compute.googleapis.com:443
DEBUG: https://compute.googleapis.com:443 "GET /compute/v1/projects/cs-prj-dev-portal-assinaturas/zones/southamerica-east1-b/instances/cs-dev-bld-02?alt=json HTTP/1.1" 200 None
> Is the OS Config agent enabled? Yes
DEBUG: Starting new HTTPS connection (1): osconfig.googleapis.com:443
DEBUG: https://osconfig.googleapis.com:443 "GET /v1/projects/cs-prj-dev-portal-assinaturas/locations/southamerica-east1-b/instances/cs-dev-bld-02/inventory?alt=json&view=FULL HTTP/1.1" 200 None
> Is the OS Config agent up to date? Yes
> Is a service account present on the instance? Yes
DEBUG: Starting new HTTPS connection (1): cloudresourcemanager.googleapis.com:443
DEBUG: https://cloudresourcemanager.googleapis.com:443 "POST /v1/projects/cs-prj-dev-portal-assinaturas:getIamPolicy?alt=json HTTP/1.1" 200 None
DEBUG: Starting new HTTPS connection (1): cloudresourcemanager.googleapis.com:443
DEBUG: https://cloudresourcemanager.googleapis.com:443 "GET /v1/projects/cs-prj-dev-portal-assinaturas?alt=json HTTP/1.1" 200 None
> Is the OS Config Service account present for this instance? Yes
> Does this instance have a public IP or Private Google Access? Yes
This instance has a public IP.
DEBUG: Chosen display Format:default
INFO: Display format: "default"
DEBUG: SDK update checks are disabled.
on the service account, it has the following permissions:
About the metadata, so I have enable-osconfig = TRUE.
Any other troubleshooting suggestions?
What machine types are you running? I think the minimal systems don't have enough memory to run the patch manager. You can stop the instance, bump the machine type (especially memory), save and retry.
Not ideal since leaving simple VMs configured this way can get expensive, but you'll know if that's actually the problem.