Accessing cloud images

For both Fedora and Ubuntu cloud images we can access them using ssh public key generated during bootup.

Key can be obtained from a console log:

  • Horizon -> Instances -> <fedora_ubuntu_instance> -> Console -> View Full Console Log
  • sudo vim /var/lib/nova/instances/<instance_id>/console.log

SSH can be done from from a proper ip namespace on compute nodes:

Or from any different host if Public IP is associated with the instance.

Nova installation on OpenSUSE 13.1

Firewalld
  • Firewall rules can be modified from GUI:
  • Assign internal interfaces to “Internal zone”
  • Add SSH service to “External zone”
RabbitMQ

In order to allow to access rabbitmq from a remote (and local) host to rabbitmq server before starting rabbitmq-server add in /etc/rabbitmq/rabbitmq.config:

Instance creation fails with “Cannot find suitable CPU” on Debian 7

KVM by default does not work (even though vmx/smx is enabled for CPUs) – instance creation fails with “Cannot find suitable CPU”.

Solution:

  • In /etc/libvirtd/qemu.conf:
  • remove file /var/cache/libvirt/qemu/capabilities and restart host (libvirtd restart does not suffice)
  • After restart check capabilities with:

VNC and firewalld on Centos 7 compute node

By default firewalld service is enabled and may cause troubles in accessing via VNC to instances running on Centos compute node.

Solution:

By default zone=public is used, so it is enough just to add 5900/5901 ports or/and vnc-server service to this zone:

 Result:

Nova installation on Centos 7

RabbitMQ

After starting rabbitmq-server service it is not possible to change password using:

 Error:

Solution:
In file /etc/systemd/system/multi-user.target.wants/rabbitmq-server.service change

to – add sudo

And restart rabbitmq-server:

 

Nova incompatibility

Packages for nova which are downloaded with yum contain nova version which is incomaptible with that is running on controller node (Ubuntu):

Controller (Ubuntu 14.04):

Compute (Centos 7):

Problem is described here:
https://ask.openstack.org/en/question/57296/juno-centos-7-buildabortexception-build-of-instance-aborted-failed-to-allocate-the-networks-not-rescheduling/?answer=57883#post-id-57883

Solution:
Install packages from EPEL repo manually (only 3 days older):

https://repos.fedorapeople.org/repos/openstack/openstack-juno/epel-7/

Packages to install:

I had to forcefully install them using rpm -ivh –force then I restarted openstack-nova-compute service.
After this instances spawned correctly, yet I could not reach them (iptables rules missing, so I disabled iptables).

DHCP addresses got distributed to the instances correctly and I could reach internet from them via my Ubuntu-AIO which acts as a gateway to the internet as well.

Nova installation on Ubuntu 14.04

nova-cert and sometimes nova-scheduler does not start after reboot even though it is enabled as per nova-manage service list output (marked as XXX state):

Reason can be found in /var/log/nova/nova-cert.log

  • Root cause is that MySQL server is not ready.
  • MySQL is started using SysV script in /etc/init.d while Nova scripts are Upstart scripts in /etc/init/ dir
  • SysV and Upstart scripts are started asynchrounously

Solution:

In /etc/init/nova-cert.conf and /etc/init/nova-scheduler.conf add a line “start on mysql_started” and comment “start on runlevel” line

It means start a service when a custom event mysql_started is emitted.

As these nova-cert/scheduler depends on mysql to start properly add the following line in /etc/init.d/mysql as a list line of start option:

  • We don’t have to care about runlevel as it is covered by mysql init script
  • In this way we ensure that only after mysql starts then we start nova-cert and nova-scheduler
  • caveat: event should be emitted only we startup is successful so only in “ifs” telling that mysql started succcessfully, I added it as a list line in the “start” option