Monthly Archives: April 2014

OpenStack Nova Upgrade & RabbitMQ

I had occasion to upgrade my Contrail cluster from 1.03 -> 1.04. While this was hampered by network issues in the lab (the witch hunt for the guilty party messing with cables is ongoing) I came out of it with a problem on one of the two compute hosts (the working one wasn’t upgraded due to the network issue).

/var/log/nova/compute.log provided this little gem:

2014-04-03 14:36:38.068 ERROR nova.openstack.common.rpc.impl_qpid [req-9becc8bb-e75a-4700-b289-a188a98a2645 None None] Unable to connect to AMQP server: client: 0-10, server: 9-1. Sleeping 60 seconds

As I understand it, RabbitMQ only supports 0-9-1 (running on the controller), but it looks like the client (vRouter side) is running 0-10-0 (QPID) – these are not compatible. Turns out on that the OpenStack side openstack-nova-compute was now configured to use QPID rather then RabbitMQ:

rpc_backend = nova.openstack.common.rpc.impl_qpid ... qpid_hostname = x.y.x.230

Edit /etc/nova/nova.conf to have:

rpc_backend = nova.openstack.common.rpc.impl_kombu ... rabbit_host = x.y.x.230

and restart the openstack-nova-compute service and we are in business.

Something else worth noting is that if you switch the RPC backend and start getting:

2014-04-04 13:26:28.659 ERROR nova.openstack.common.rpc.common [req-f0ea9acc-f6e0-46e2-81f6-1e4b23f0bd2a None None] AMQP server on localhost:5672 is unreachable: [Errno 111] ECONNREFUSED. Trying again in 15 seconds.

in your log (multi-node setup here with separate messaging server) then you have made the mistake, as I did, of assuming that the rabbit_host at the end of the file is parsed – it isn’t! Make sure your configuration is before the [keystone_authtoken] block e.g.

volume_api_class = nova.volume.cinder.API enabled_apis=ec2,osapi_compute,metadata auth_strategy=keystone #qpid_hostname = x.y.z.230 glance_host = x.y.z.230 quantum_url_timeout = 300 novncproxy_base_url = http://10.3.8.230:5999/vnc_auto.html vncserver_enabled = true vncserver_listen = x.y.z.231 vncserver_proxyclient_address = x.y.z.231 security_group_api = quantum heal_instance_info_cache_interval = 0 libvirt_cpu_mode = none rabbit_host = x.y.z.230
[keystone_authtoken] admin_tenant_name = service admin_user = nova admin_password = 154c7f845c59fe7b9a78 auth_host = x.y.z.230 auth_port = 35357 auth_protocol = http signing_dir = /tmp/keystone-signing-nova

Facebook

Twitter

Stumbleupon

Checking the current version of Nova

Raspberry Pi – Getting SMB to work

6 Replies

I just got a new Raspberry Pi Model B and am planning on playing with it as a Media Center system. Getting the basics up and running took a little more work then I expected as I didn’t have neither HDMI/DVI converter nor USB Keyboard (PS/2 rules).

I had a pre-formatted SDCard ready to roll but when I attached the network cable and power unfortunately the device didn’t connect to the network – plugging it into the TV I saw that the it was stopping at the NOOBS loader. This allows you to get the Pi up and running easily, without network access, and to select and install from a menu of Operating Systems. Kind of conflicted about how good an idea this is to the typical linux/electronics hobbiest. Effectively this acts like a recovery partition after the first install.

Plug in a mouse, select Raspbian (as I usually work on Debian) and a few mins later the install is complete. Reboot and complete the setup and it was networked. Once I found the IP I updated and upgraded all the packages and installed XRDP for remote desktop access.

At this point I wanted to check that SMB would work – it wouldn’t 🙁

pi@raspberrypi ~ $ sudo mkdir /mnt/Media pi@raspberrypi ~ $ sudo vi /etc/fstab pi@raspberrypi ~ $ mount /mnt/Media mount: only root can mount //192.168.1.8/samba on /mnt/Media pi@raspberrypi ~ $ sudo !! sudo mount /mnt/Media mount error: cifs filesystem not supported by the system mount error(19): No such device Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) pi@raspberrypi ~ $ cd /mnt pi@raspberrypi /mnt $ ls Media pi@raspberrypi /mnt $ mount -t cifs -o user=xxxx //192.168.1.8/samba /mnt/Media mount: only root can do that pi@raspberrypi /mnt $ sudo !! sudo mount -t cifs -o user=xxxx//192.168.1.8/samba /mnt/Media Password: mount error: cifs filesystem not supported by the system mount error(19): No such device Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) pi@raspberrypi /mnt $ sudo modprobe cifs libkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/3.6.11+/modules.dep.bin'

This was something of a puzzle as both cifs-utils and libsmbclient are installed. Turns out that the firmware was out of date – a quick rpi-update and reboot and problem solved!

pi@raspberrypi /mnt $ sudo rpi-update *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS *** Performing self-update % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 135 100 135 0 0 240 0 --:--:-- --:--:-- --:--:-- 323 100 7177 100 7177 0 0 7315 0 --:--:-- --:--:-- --:--:-- 7315 *** Relaunching after update *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS *** ARM/GPU split is now defined in /boot/config.txt using the gpu_mem option! *** We're running for the first time *** Setting up firmware (this may take a few minutes) Cloning into '//root/.rpi-firmware'... remote: Counting objects: 3378, done. remote: Compressing objects: 100% (2610/2610), done. Receiving objects: 100% (3378/3378), 25.96 MiB | 1.20 MiB/s, done. remote: Total 3378 (delta 1608), reused 1117 (delta 504) Resolving deltas: 100% (1608/1608), done. ...