I downloaded 3 official cloud ready images QCOW2 format:
- cirros -> i can ping instance | i can ssh with cirros:cubswin:) | i can ssh with keypair
- ubuntu trusty -> i can ping instance | i cannot ssh!!! | i cannot ssh with keypair
- centos7 / rhel7 -> i cannot ping instance | i cannot ssh | i cannot ssh with keypair
is a VIO problem?
PS with windows or with my own linux images i have no problems
Finally i managed to find the problem and the solution!!!
- I used guestfish to set a root password (Changing the password on the RHEL 7 kvm qcow2 download (links updated 7/2/2015) - Red Hat Customer P...) and to disable cloud-init to lock root account in /etc/cloud/cloud.cfg (invert first 2 params)
- I converted qcow2 image to vmdk with qemu-img and I created a new VM with VMware Workstation
- Now i'm be able to login with root account
- I noticed that network was down and this is the real problem, the network (ip address) was eno16777728 instead of eth0 !!!! So i changed the network script
DHCP now is working and net is UP!!
PS
- my MTU problem remains, but i resolved it at the moment setting MTU=1450 into the VM
- a cloud-init script can be made to make this change when launching centos official instance
I am assuming you have the same security groups on all the 3 VMs? That is Check
- SSH (TCP 22) ingress is allowed for all CIDR and ICMP is allowed for all CIDR for bot ubuntu and centos7.
For Ping:
If security groups are fine, then go to horizon, network topology and attach the scrn capture of network topology.
- make sure that the VMs are reachable from the machine invoking "ping" request.
For SSH Keys:
Are you able to log into the ubuntu-trusty from console using the default username and passwd for the image?
- If you are then can you check the ~/.ssh/ if the authorized keys is the same as the public key you used in your keypair used while creating the instance.
You can check similar for CentOS...
Thank you for your answer ...
This howto OpenStack Docs: OpenStack Virtual Machine Image Guide says Ubuntu, CentOS and RHEL official cloud images dont have user login enabled but onlu ssh key pair.
All instances are in the same newtwork of CirrOS instance and i follow this:
- launch instance with key pair
- ssh -i file.pem cirros@instance_ip
for the other i use centos, ubuntu and cloud-user user but nothing ....
- i try also to enable config drive
same problem, the instances are up and run (from horizon VNC) at login but no ssh with keypair
So i think all work right, during ubuntu instance strartup i can see also cloud-init
The only this that i made in VIO 2.0 is to disable guest customization with custom.yml but i dont think this is the problem. I made this change to have windows instances working right with cloudinit
This for example the CentOS image: http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud-1601.qcow2
Some one can try?
Ok I will try that CentOS image mentioned below and post back.
can you also paste the link for the ubuntu-trusty image
The ubuntu image, thanks !
https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64.ova
Ya I tried CentOS 7 from 2 different sources. One that you mentioned below and from another source. I am seeing the same problem not able to ping and of course no ssh.
I am debugging this with others. Probably will file few bugs on it internally. This might take some time to figure out.
I will try the ubuntu as well.
arvind
ok than you very much!
I am able to ssh and ping the ubuntu image without any problem.
But CentOS is a problem. Have you managed to login into the CentOS system by any chance fomr the VNC console on Horizon? perhaps by resetting the root pwd in single user mode etc? I wasn't able to do it yet but just checking if you are able to login.
ok i re-try with ubuntu ..you used config drive? can you describe me what you did?
seems that (as i read) that centos and redhat comes with firewall enabled and root ssh disabled so the only way is with keypair...:smileyconfused:
something incredible!
i created a centos minimal installation VM without cloudinit and so on, clean!
in my vmware workstation env i can ssh with root with putty without any problem
export VM and put it into glance
when i launch the instance i can ping it but NO SSH!!! putty remains busy with black screen, no errors
the secuiry group permit all types of connection, infact cirros works!
i found the solution, the problem is mtu fragmentation.
A simple test:
ifconfig
eth0 mtu 578
on target cloud vm and it work!
But real soliution is that i have to bring underlying pyhisical switches mtu to 1600 too? as nsx?
huh... could you elaborate more? You managed to log into the CentOS VM and then changing the MTU settings helped with the ping and ssh?
not with centos official but with a selfmade image...
i think that my problem is this...
for centos i believe the only way to access, after configured the mtu in the network is to use:
ssh -i file.pem centos@ip
what error do you receive when you try to login to centos image?
what was the physical switch mtu?
I don't think you need to bring down the mtu size on nsx/physical switch.
It was 1500
At the moment i didnt change mtu on the switch yet but into the vm...
as i understand the mtu of nsx underlying switch must be changed?
Finally i managed to find the problem and the solution!!!
- I used guestfish to set a root password (Changing the password on the RHEL 7 kvm qcow2 download (links updated 7/2/2015) - Red Hat Customer P...) and to disable cloud-init to lock root account in /etc/cloud/cloud.cfg (invert first 2 params)
- I converted qcow2 image to vmdk with qemu-img and I created a new VM with VMware Workstation
- Now i'm be able to login with root account
- I noticed that network was down and this is the real problem, the network (ip address) was eno16777728 instead of eth0 !!!! So i changed the network script
DHCP now is working and net is UP!!
PS
- my MTU problem remains, but i resolved it at the moment setting MTU=1450 into the VM
- a cloud-init script can be made to make this change when launching centos official instance
Yes the incorrect interface name is the problem. We came to same conclusion. We will document this at least for a KB article and also explore if something can be done to avoid such issues.
thanks for bringing quite an intricate issue to resolution. keep us posted as you further use VIO.
arvind
This is the init data for Horizon
#!/bin/bash
mv /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eno16777728
sed -i -e 's/^DEVICE=/#&/' -e '$aDEVICE=eno16777728' /etc/sysconfig/network-scripts/ifcfg-eno16777728
ifup eno16777728
service network restart
exit 0