I've inherited a server which is using proxmox for the virtualisation, I'd like to know what is the IP address of a VM.
I've managed to get the list of VMs available on the server by using qm list:
VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID
99001 web-dev1 running 2048 50.00 1234
99002 web-dev2 running 2048 50.00 2345
99003 web-dev3 running 2048 50.00 3456
99004 web-dev4 running 2048 50.00 4567
How can I know, without accessing directly and running a command in it, the IP address associated with each VM?
Thank you,
Fabio
Maybe the fastest way would be using arp cache :
arp -a
Then look at the MAC address of each VM :
qm config VMID
Here it is guys:
Since this came up while I was searching the problem, I would like to post the following:
1 - Make sure qemu-ga is updated in the guest : https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/ (Keep this link around you)
2 - SSH into your Host run : qm guest cmd vmid network-get-interfaces
Regards,
Alvaro Lamadrid
Related
I noticed latelty (probably after upgrading WSL kernel to 5.15.79.1) that almost every terminal command involved in domain resolution is dalayed for about 5 sec. The same behaviour is shared by ssh, telnet, ping, wget, curl, etc. What is interesting is the fact that dig and nslookup are free from that issue. The delay at resolving is easily visible with verbose versions of wget or ssh. it looks like below.
SSH example
WGET example
I must add that previously I disabled automatic resolv.conf generation with /etc/wsl.conf
I already tried changing several values for nameserver in resolv.conf (8.8.8.8, 208.67.222.222, 1.1.1.1, etc.), redirecting the DNS queries to my local dnsmasq and as a last resolve I also disabled IPv6 for Ubuntu guest with /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
None of those seem to help. Do you have any suggestions?
I am trying to use a single IP as a "floating IP" by assigning it to a secondary interface eth1 between 2 VMs. The primary interface eth0 has 2 different IPs for both VMs. Only one of the VMs will have the IP assigned to eth1 at any given time. If we have any issues with the primary VM we will unassign the IP from eth1 of the primary VM and reassign it to the secondary VM.
We are unassigning and assigning the IP using -
/sbin/ip addr ${ACTION} ${IP} dev ${INTERFACE}
However once we unassign the IP from eth1 of the primary VM and assign it to eth1 of the secondary VM I am unable to ssh to the secondary VM right away. I get a -
ssh: connect to host x.x.x.x port 22: Connection timed out
After about 15 mins some cache somewhere gets cleared and then I am able to ssh to the secondary box.
Have the following setting already updated in sshd_config and sshd has been restarted.
GSSAPIAuthentication no
UseDNS no
We are using Redhat 7.6
Any help in the troubleshooting what could be causing the delay in ssh'ing to the secondary box is much appreciated!
Thanks!
Your issue is with your network gear and the clients arp tables.
After you change the address check your arp tables with arp -a on Linux and show ip arp (Cisco gear). You will see the old MAC address maps to the old server IP.
After you change ip addresses send a gratuitous arp and that will force everything to update.
Assume your ethernet address is 10.0.10.1 and you are using eth1.
yum install arping -y
arping -A -I eth1 10.0.10.1
This very similar to what VMware does when you VMotion a VM to another host. It sends an RARP to notify the network the MAC address has moved to different a port.
EDIT: Also note, in older RHEL ver ifup-eth script used the arping tool to send a GARP. That means I might also try ip link set eth1 down and ip link set eth1 up see if that works.
This issue got resolved. We had to update the arp neihbor cache to get this to work so incorporated that into our script.
I have spent a few hours hunting for the problem here.
I have been working with Macs for years now and never had this problem, and have ssh into eC2 instances thousands of times.
I recently received at work a new MacBook Pro.
SSH runs as a service, meaning here it does not return any error that it is not found.
But no matter what server or EC2 instance I try to ssh into, as I have done a million times before I get a timeout.
Before you ask, I have looked all over for this problem. I have also looked for the normal ~/.ssh directory, which seems to be missing and therefore cannot find any config file.
The following is the Mac info:
Catalina 10.15.2
Model Name: MacBook Pro
Model Identifier: MacBookPro16,1
Processor Name: 8-Core Intel Core i9
Processor Speed: 2.3 GHz
Number of Processors: 1
Total Number of Cores: 8
L2 Cache (per Core): 256 KB
L3 Cache: 16 MB
Hyper-Threading Technology: Enabled
Memory: 16 GB
Boot ROM Version: 1037.60.58.0.0 (iBridge: 17.16.12551.0.0,0)
Serial Number (system): C02ZNMV5MD6N
Hardware UUID: 27B1EDF5-B1D2-5F86-BD12-D646F36D9D2D
Activation Lock Status: Enabled
ETA: Yes, from a Windows machine I can access the EC2 network. Yes, I have the correct PEM file. And yes, I have made sure security groups in AWS are correct. For some reason the normal ssh -i etc. picked up directly from AWS connect for the EC2 instance always times out.
Crazy question: does the ssh in Catalina demand another command, addition or some other parameter besides -i?
(I do not seem to be able to ping, telnet etc. either. So something seems to be preventing the OS from going out on ssh port 22.)
Does anyone know of or has had this problem and a fix for it? I am fairly sure it is some type of configuration in ssh or in the Network configurations.
It is driving me crazy. Any and all help would be greatly appreciated!
New Macbook Pro owner/user here. Same issue, despite all configs being identical to my Windows 10 pc and Ubuntu 20 laptop.
For some reason, this doesn't work for me on my Macbook, but does work on Windows and Ubuntu.
ssh -i path-to-keyfile.pem user#ipaddress
But creating an SSH config file and adding my AWS keyfile to my keychain works:
open ~/.ssh/config if the config file exists, or touch ~/.ssh/config if not.
Edit this config file as follows:
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa
Note: I don't know for sure, but I imagine only the 'AddKeysToAgent' and 'UseKeychain' parts are what's important. I'm using the 'IdentityFile' part for connecting to my git repos.
Save the config file and exit. Next, make sure your keyfile isn't too open, otherwise you won't be able to add it to your keychain:
chmod 600 path-to-keyfile.pem
Finally, add the keyfile to your keychain:
ssh-add -K path-to-keyfile.pem
Now on Mac, I'm able to ssh into my AWS instance without the -i flag:
ssh aws-username#aws-ipaddress
Hope this helps. I found the solution here: https://www.cloudsavvyit.com/1795/how-to-add-your-ec2-pem-file-to-your-ssh-keychain/
PS - I'm also unable to sFTP into AWS using Filezilla on Mac, so I'm looking into this as well.
Update on Filezilla: A bit bizarre and I haven't figured out how to save my settings, but for now this answer works: https://superuser.com/questions/280808/filezilla-on-mac-sftp-with-passwordless-authentication
For a project, I need to access the faculty server
Remotely through ssh after connecting the faculty VPN with my credentials.
Before,I log in quietly until recently with:
ssh my_name_user#147.163.26.244
it appeared to enter the password and entering the credentials I accessed the server (actually a virtual machine mounted on the server for me).
Now with the command above nothing happens and after waiting a bit I get:
ssh: connect to host 147.163.26.244 port 22: Connection timed out
What may have happened?
Yesterday I changed my password to access University services (mandatory after 3 months for security reasons). After doing so I had to change that new password in the VPN configurations and I was able to have access to the VPN and also to the server, until this all ok. From today at 13.00 this problem occurs.
Does anyone have any idea what this is all about?
(I'm on Ubuntu. The server(the virtual machine is a Lubuntu system))
Thanks for your attention.
Update:
The command
ping 147.163.26.244
gives me:
PING 147.163.26.244 (147.163.26.244) 56(84) bytes of data.
and
telnet 147.163.26.244 22
gives:
Trying 147.163.26.244...
and it remain running. What can I deduce?
As ssh shows connection timeout its nothing to do with your credentials. It hasn't go to the authentication level but failing before that itself.
First of all check if the IP is accessible from you machine using Ping (hoping ICMP should be allowed by the Firewall).
ping server_ip
If it shows not accessible- then make sure there is a route for the IP/IP subnet of the server IP through the vpn tunnel. You can do it by using route/netstat
example
netstat -nr | grep "147.163"
If route is not present you may have to add a route for this IP through the VPN tunnel. You can find the "route add.." or "ip route add ... " commands for this from google depending on your machine platform.
If the Ping shows the IP is pinging, we need to make sure the ssh service is running on the port 22. Just do a telnet and check
telnet <server_ip> 22
if the connection shows UP, in your case which shouldn't show UP btw :)as you got a timeout already. Then problem can be
(1) ssh service not running
(2) any firewall blocking your connection
You may have to get in touch with the ADMIN in that case.
===== Update =========
I guess your ping itself is failing.
Ping should show it is getting response.
example :
XXXXXXX$ ping 216.58.217.174
PING 216.58.217.174 (216.58.217.174): 56 data bytes
64 bytes from 216.58.217.174: icmp_seq=0 ttl=43 time=273.068 ms
64 bytes from 216.58.217.174: icmp_seq=1 ttl=43 time=317.405 ms
64 bytes from 216.58.217.174: icmp_seq=2 ttl=43 time=361.682 ms
64 bytes from 216.58.217.174: icmp_seq=3 ttl=43 time=266.436 ms
Check for the routes in your machine using route or netstat.
Possibilities :
server is down
Proper route is not present for the IP/subnet of the ssh server through VPN tunnel
I have found a partial answer to this question, and it is successfully setting the machine at the desired IP address. But the network is unreachable from inside a docker-machine created with the Hyper-V driver.
The TLDR on the answer above is to create a script, /var/lib/boot2docker/bootsync.sh:
sudo cat /var/run/udhcpc.eth0.pid | xargs sudo kill
sudo ifconfig eth0 192.168.XXX.YYY netmask 255.255.255.0 broadcast 192.168.XXX.255 up
Once I make the script, I restart the machine.
When I restart the machine, the IP is set to my desired address (expected). I can remote in at the address, so it is at least available through the host. But when I test for connections, there is no connection to the internet (unexpected).
Boot2Docker version 17.05.0-ce, build HEAD : 5ed2840 - Fri May 5 21:04:09 UTC 2017
Docker version 17.05.0-ce, build 89658be
docker#machine:~$ docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:48331->[::1]:53: read: connection refused
docker#machine:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
If I remove the script and restart again, I am reassigned a new/random IP address (expected), remote in at that new IP address, and can do network connections (expected):
docker#pm:~$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
aafe6b5e13de: Pull complete
0a2b43a72660: Pull complete
18bdd1e546d2: Pull complete
8198342c3e05: Pull complete
f56970a44fd4: Pull complete
Digest: sha256:f3a61450ae43896c4332bda5e78b453f4a93179045f20c8181043b26b5e79028
Status: Downloaded newer image for ubuntu:latest
docker#pm:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=18.424 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=27.638 ms
The accepted answer has several up votes, but it reads like this is a confirmed work around on VirtualBox. Not sure what about Hyper-V would be causing the IP assignment to cut off internet access.
I had the same problem, and I solved it by adding the following to the end of bootsync.sh:
route add default gw <address>
There was no default route to the gateway or the internet, so it must be set manually.