I have GPU compute instance it worked, I had changed some of the settings inside the container - via chown and chmod, so I wanted to reset the container using reset option - I thought it would get to the begining settings but it did not worked
Administrator created second image I did the same experiments and now I can not connect to VM so I am sure that that resetting did not got the image to the starting point.
When I run the instance from cloud shell I get
jakub_mitura@ ...... .: Permission denied (publickey).
jakub_mitura@ ..... : Permission denied (publickey).
after doing
```
--troubleshoot --tunnel-through-iap
```
I get at the end
```
You need permission to SSH to a private IP address: iap.tunnelInstances.accessViaIAP.
Help for IAP permissions: https://cloud.google.com/iap/docs/managing-access
- Your organization hasn't blocked access to external IP addresses. IAP changes the source traffic to 35.235.240.0/20 and the tunnel to https://tunnel.cloudproxy.app.
---- Checking VM boot status ----
VM boot: 0 issue(s) found.
```
But I had permissions because I was able to open instance at the beginning
Without creating new instance which is complicated in my case what can I do?
Solved! Go to Solution.
I had to read here ...
https://cloud.google.com/compute/docs/instances/stop-start-instance#resetting_an_instance
Resetting a VM is like "powering off and then powering on your PC". It is a hard reset of the physical machine but not a logical "factory reset" of your VM image. As the docs say:
> When you reset a VM, none of the VM properties change. The VM retains its ephemeral IPs, static external IPs, persistent disks, local SSDs (if any), and machine type. However, any data stored in memory is reset unless you back up the data.
If we have broken files in the file system then a VM reset isn't going to change that. It doesn't "rebuild" the content of the boot disks. You can create a new boot disk through this recipe:
https://cloud.google.com/compute/docs/disks/create-root-persistent-disks#creatingrootpdalone
and then detach your original boot disk and attach the new boot disk. This will preserve your original Compute Engine VM definition but reset/replace the bootable disk ... effectively giving you a new Compute Engine. However, if you went through an administrator to get your Compute Engine in the first place, it isn't clear to me that you will have the permissions/authority to create a NEW bootdisk yourself. If that's the case, it is questionable whether this is the easiest route or simply requesting a deletion and new creation of a new Compute Engine is warranted.