I am very new to Google Cloud Platform and was trying to restart my VM instance. I entered $ sudo poweroff into my SSH console, as suggested by https://cloud.google.com/compute/docs/instances/stopping-or-deleting-an-instance#stop_an_instance
and the console did not return anything. Afterwords I started the VM instance again and the SSH console started returning the message "We are unable to connect to the VM on port 22.".
I have a snapshot of my root disk, but I would really like my instance to be running properly again.
When you run either sudo poweroff or sudo shutdown -h now, your VM will shutdown right away. This involves flushing any in-memory buffers for disks back to the disks so that you do not lose any unflushed data.
Since you're initiating this command over a ssh session, you will not be able to look at any shutdown messages over ssh while the instance is shutting down (since the network service on the VM will also be brought down).
You can use gcloud compute instances list or gcloud compute instances describe VM_NAME commands to find out the status of the VM.
If it says RUNNING, it means the instance is running and you will be able to ssh to the VM. If it says TERMINATED, it means the instance was shutdown/terminated and you will not be billed for this instance.
Related
I have installed Redis GUI redis-commander by using https://github.com/joeferner/redis-commander
Redis running on localhost:6379 as a container at docker.
This says if I run redis on localhost:6379, all I need to get started is;
docker run --rm --name redis-commander -d -p 8081:8081 ghcr.io/joeferner/redis-commander:latest
But I encountered with this problem... Is there anyone who got this error and found a solution for this ??
There are some things you have to take into account.
Redis commander is running inside a container so localhost no longer points to your laptop/desktop/developing machine/server. It points to the container itself where no redis is running. So it will never connect. You need to point to the other container.
For this, you should be using some-redis (the name of the container) instead of localhost. In Redis Commander click more and add server to add a new connection
But this will not work unless both containers are running inside the same network.
You need to create first a new docker network
docker network create redis
And then run your containers using this parameter --network=redis
More about docker network here
More about docker run with networks here
GCP VM instance: OS: Ubuntu (18.04 bionic) Disk size: 10GB. Later added another disk of 10 GB.
While working on the GCP VM instance, I was facing the issue for 'no-disk space left'. Then, I created another disk of 10 GB and added to this GCP VM instance as referred in https://cloud.google.com/compute/docs/disks/add-persistent-disk?&_ga=2.217520662.-1058595688.1590395241#formatting
Now, I exited the GCP VM instance and stopped it.
Later on, when I restarted the GCP VM instance, I am unable to connect. I tried to connect using the SSH connection option available on GCP, putty, WinSCP and telnet, but I am unable to connect now.
My understanding to this is that it might be possible that some services might have stopped on the GCP VM instance. Is there a way to check whether the services are running or not on the GCP VM instances. If yes,then how?
If you think, there is some other issue for connecting to the GCP VM instance then please let me know.
There may be several reasons;
Firewall rules - check them to be sure nothing blocks SSH traffic to your machine.
Have a look at the serial console output - you can do it via console gui or gcloud compute instances get-serial-port-output instance_name --zone=my_zone.
If your drive gets full you may not be able to login (no matter how).
Adding another persistend disk won't help if the first one is full.
You can increase it's size though - also via console or gcloud compute disks resize example-disk-1 --size=11GB - this will add 1GB more and if it's the matter of disk space it should allow you to log in.
If you're still not able to log in try enabling interaction with serial console gcloud compute instances add-metadata instance-name --metadata serial-port-enable=TRUE and connect to it gcloud compute connect-to-serial-port instance-name since this is the most full-proof method if everything else fails.
If you're able to connect via serial console check if the SSH service is listening:
sudo service ssh status - if not start it with sudo service ssh start and watch for any errors.
Similar case was also discussed here.
A compute instance I had running stopped working and I am no longer able to ssh to it from the browser. When I try it hangs forever and eventually I get the error message:
You cannot connect to the VM instance because of an unexpected error.
Wait a few moments and then try again. (#13)
I looked here for common issues. I made a snapshot and tried recreating with a larger disk, in a different region and with a bigger compute instance but I was still unable to connect. When other users try to connect they have the same problem. I'm using a standard container so I expect the google daemon should be running.
This instance was collecting tweets and writing output to GCS regularly. Since ssh stopped working the instance has also stopped writing output.
Does anyone have any idea what could have gone wrong?
I would also suggest checking the Serial Console of the machine to see if there are any messages which provide any clues. For example, if the boot disk has run out of space (which can prevent SSH connectivity), there will be some messages displayed in the Serial Console implying this.
You could also try connecting to the machine via the Serial Console to troubleshoot the issue by following the advice here.
When you try to SSH into the instance from the Cloud Shell for example, using the following command, the output should provide some clues as to why you cannot SSH into the machine:
$ gcloud compute ssh INSTANCE_NAME --zone ZONE
If you are on a VPC network, try to check the applicable network TAG that allows the instance to use SSH and provide that tag to your instance. Because it could be the Firewall rules that are blocking your instance from creating the ssh connection.
I'm using google cloud instance for one of my long duration job and using : gcloud compute ssh 'instance name' to connect from one of my ubuntu PC terminal.
All goes well. But as the job takes few hours to complete and when my PC is out of network the shell gets killed and hence the job also.
I'm wondering if there is a way by which the job can continue on google cloud when the 'SSH terminal' from my PC gets killed because on network unavailability?
Thanks
The best answer here is to use mosh to connect to your instance. In order to do this, you will need to first install mosh on your instance via the normal method for your distribution. Second you will need to modify the firewall that Google runs to allow for the required UDP port to reach:
you#local-pc:~$ gcloud compute firewall-rules create default-allow-mosh --allow=udp:60001
In this case we use the name 'default-allow-mosh' following the nomenclature used in the rest of the firewall rules of network-action-what and telling it to allow the UDP port that mosh says it must have allowed through.
I've got a VMware ESXi server that I connected to via SSH to run a process. (I was running "vmkfstools --punchzero myVirtualDrive.vmdk" to reclaim space on a virtual disk). The SSH client connection was disconnected when the process was only 70% complete (with several hours of estimated time remaining).
Was the process terminated when the SSH client dropped its connection to the ESXi host?
Is there any way to tell if the process is still running?
I did a quick ps|grep to find it, but didn't see anything that looked like vmkfstools.
On most standard linux machines, I use "screen" to avoid SSH client disconnection issues, but since the ESXi shell is purposely a very stripped down environment, I just ran the command straight away.
Thoughts?
The command was killed when you disconnected.
What you can do to prevent this in the future is to run the command with nohup. This will run your command in the background, continuing even when your shell "hangs up".
What I usually do when I expect a command to run long:
I ssh to a Linux machine that runs 24/7
start screen
ssh to the ESXi host
start the command
This way I don't have to worry about disconnects, I can just detach screen and go home after work and reattach screen the next morning to check the status of the command.
This was exactly what I was looking for, thanks all. I attempted to unmap unused block on LUNs which is vmfs 5 file system. I run this cmd esxcli storage vmfs unmap -l [LUN-NAME] I wonder that what will happen if I close remote SSH connection while this cmd process still running.