After a power failure of the host machine, the openstack cinder volumes have entered a state in which they can not be attached nor detached.
~$ nova volume-attach ### ###
ERROR: Invalid volume: already attached (HTTP 400) (Request-ID: req-###)
~$ nova volume-detach ### ###
ERROR: Invalid volume: already detached (HTTP 400) (Request-ID: req-###)
The status of the volume its self is listed as attached
cinder list
+-----+-----------+---------------------+------+-------------+----------+-------------+
| ID | Status | Display Name | Size | Volume Type | Bootable | Attached to |
+-----+-----------+---------------------+------+-------------+----------+-------------+
| ### | available | volume-data | 690 | Storage | false | ### |
+-----+-----------+---------------------+------+-------------+----------+-------------+
The volume is not found on the instance even though its listed as attached in the cli and in horizon (the device isnt found in /dev/ nor the mount point in /mnt/)
Related
I have connected a GSM modem to my computer. When the application sent message, getting below response. i have replaced the mobile number in log file with xxxxxxxx. Application was able to sent SMS, but this issue started all of a sudden.
2017-01-16 06:40:09,217 | INFO | PagerChannel.java |
PagerChannel::sendSMS (single message) ENTER
2017-01-16 06:40:09,217 | INFO | PagerChannel.java | Connecting on
Port:com3 with boud rate:115200
2017-01-16 06:40:19,289 | INFO | PagerChannel.java | Connected on
Port:com3 with boud rate:115200
2017-01-16 06:40:19,811 | INFO | PagerChannel.java | Sending SMS on :
xxxxxxxx using AT^SCMS=xxxxxxxx,145,1,5,16,2088
2017-01-16 06:40:19,871 | ERROR | PagerChannel.java |
PagerChannel.sendSMS Error response: for
AT^SCMS=xxxxxxxx,145,1,5,16,2088 response:
+CMS ERROR: invalid parameter
Can Anybody tell me what's the problem?
I found the issue which was causing the error, these issue started when i changed the mobile number format to just the number without country code. (from +974MobileNumber to MobileNumber)
In that scenario the Type of Destination Address value should 129 , but in my case it was using the 145.
AT^SCMS=da[toda], seq, max, ieia, ref
Type of Destination Address GSM 04.11 TP-Destination-Address
Type-of-Address octet in integer format (when first character of
is + (IRA 43) default is 145, otherwise default is 129).
I am trying to use Openstack (liberty) swift with Ceph (Jewel) using radosgw. The aim is that the objects should be stored under ceph osds. I have a working Openstack and Ceph cluster.
To use Ceph as object storage backend I installed and configured radosgw in ceph cluster . In openstack node I installed "python-swiftclient", created an object-store service and added an endpoint for that service with the URL of radosgw.
I followed the instructions given in the link below.
http://docs.ceph.com/docs/jewel/radosgw/keystone/
ceph.conf
[client.rgw.rgw]
rgw_frontends = "civetweb port=7480"
rgw enable ops log = true
rgw ops log rados = true
rgw thread pool size = 2000
rgw override bucket index max shards = 23
ms dispatch throttle bytes = 209715200
[client.radosgw.gateway]
rgw keystone url = http://controller:35357
rgw keystone admin token = ADMIN
rgw keystone accepted roles = _member_,admin
rgw keystone token cache size = 200
rgw keystone revocation interval = 60
rgw s3 auth use keystone = true
nss db path = /var/ceph/nss
Openstack endpoints
# openstack endpoint list |grep -i object
| 8efd00b48db249e69244a5f3e35356b1 | RegionOne | swift | object-store | True | internal | http://rgw:7480/swift/v1 |
| b7d1c7ccc84640138116d8e6676b28a3 | RegionOne | swift | object-store | True | admin | http://rgw:7480/swift/v1 |
| c7844842b53647a4b623905c54cc6c75 | RegionOne | swift | object-store | True | public | http://rgw:7480/swift/v1 |
Output of swift list from command line
# swift list -v
test_CONTAINER
Output of swift stat from command line
# swift stat -v
StorageURL: http://rgw:7480/swift/v1
Auth Token: AUTH_rgwtk0e00000074657374757365723a737769667431dd200c6d2136112ee6d657300feb16d05ffa8f80a2e53ce6c257b32ec5505ff396e5e8
Account: v1
Containers: 7
Objects: 12
Bytes: 168
Meta Temp-Url-Key: healthseq
X-Account-Bytes-Used-Actual: 40960
X-Timestamp: 1473615022.41820
X-Trans-Id: tx0000000000000000006b3-0057d594ae-1f5cb-default
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes
When I try to access the object store - container in openstack dashboard, I get the following error.
http://pastebin.com/ALEvYCX8
Please see the image below for the error that I get while trying to access the object store from dashboard.
just remove this line in your code
[client.radosgw.gateway] and merge the setting
I'm using Centos 6.5 x86_64 to setup Openstack Havana and all services work well. But when I've rebooted the operating system, I've founded that the nova service does not work properly, the following error triggered:
nova flavor-list
ERROR: [Errno 111] Connection refused
Reviewing the log files in / var / log / nova gives the following error:
2014-03-24 12:24:04.293 6275 INFO nova.osapi_compute.wsgi.server [-] (6275) wsgi starting up
2014-03-24 12:24:04.297 6267 CRITICAL nova [-] [Errno 98] Address already in use
2014-03-24 12:24:04.412 6275 INFO nova.openstack.common.service [-] Parent process has died unexpectedly, exiting
2014-03-24 12:24:04.412 6274 INFO nova.openstack.common.service [-] Parent process has died unexpectedly, exiting
2014-03-24 12:24:04.412 6275 INFO nova.wsgi [-] Stopping WSGI server.
2014-03-24 12:24:04.412 6274 INFO nova.wsgi [-] Stopping WSGI server.
The state of my OpenStack server
nova-manage service list
Binary Host Zone Status State Updated_At
nova-cert controller internal enabled :-) 2014-03-24 14:28:03
nova-consoleauth controller internal enabled :-) 2014-03-24 14:28:01
nova-scheduler controller internal enabled :-) 2014-03-24 14:28:00
nova-conductor controller internal enabled :-) 2014-03-24 14:27:59
nova-compute controller nova enabled :-) 2014-03-24 14:28:06
nova-network controller internal enabled :-) 2014-03-24 14:27:58
keystone service-list
+----------------------------------+----------+----------+---------------------------+
| id | name | type | description |
+----------------------------------+----------+----------+---------------------------+
| 7ce108d652ee48d7897127045a371795 | cinder | volume | Cinder Volume Service |
| 9452b875328f4763b7766eb533bd75c4 | cinderv2 | volumev2 | Cinder Volume Service V2 |
| e9607d1a308140298f8364fd2a0e62a8 | glance | image | Glance Image Service |
| b7ac07f69e2e41f684d6470c69db4781 | keystone | identity | Keystone Identity Service |
| cbdfa73329094d7d94c7464b9bf0ef7d | nova | compute | Nova Compute service |
+----------------------------------+----------+----------+---------------------------+
ps -ef | grep "nova-api"
nova 2522 1 0 11:22 ? 00:00:00 /usr/bin/python /usr/bin/nova-api-metadata --logfile /var/log/nova/metadata-api.log
root 11909 6217 0 15:11 pts/1 00:00:01 gedit nova-api.log
root 12644 3832 0 15:31 pts/0 00:00:00 grep nova-api
netstat -napo | grep 877
tcp 0 0 0.0.0.0:8775 0.0.0.0:* LISTEN 2522/python off (0.00/0/0)
Any pointers would be extremely helpful.
Thanks
firstly, i strongly recommend you to find or ask for answer on ask.openstack.org
then from what you described, it may caused by: you've enabled nova-api-metadata and nova-api service in the same time.
from the default configuration we know that: ['ec2', 'osapi_compute', 'metadata'] are enabled, see https://github.com/openstack/nova/blob/stable/havana/nova/service.py#L55
so it will start each service one by one when nova-api service is called, see https://github.com/openstack/nova/blob/stable/havana/nova/cmd/api.py#L45
since nova-api-metadata service is running, which cause the 8775 port is used, then one service launched by nova-api will die and since this exception is not caught, then the other two will die too, then you get what you see in the log
If what I've assumed is right, please cancel the nova-api-metadata service and use nova-api service only, which means 'chkconfig openstack-nova-api-metadata off; chkconfig openstack-nova-api on', i'm not sure about the specific service name on your system, but should be something like that, correct it if i'm wrong
Connection refused is a common error encountered everytime. One of the case is keystone is refusing the connection for the nova service.
make sure SERVICE_PASSWORD for nova and quantum are same while creating the keystone services.Go to quantum and nova config files and verify the SERVICE_PASSWORD are same.
Njoy!!
I have an OBIEE 11g installation in a Red Hat machine, but I'm finding problems to make it running. I can start WebLogic and its services, so I’m able to enter the WebLogic console and Enterprise Manager, but problems come when I try to start OBIEE components with opmnctl command.
The steps I’m performing are the following:
1) Start WebLogic
cd /home/Oracle/Middleware/user_projects/domains/bifoundation_domain/bin/
./startWebLogic.sh
2) Start NodeManager
cd /home/Oracle/Middleware/wlserver_10.3/server/bin/
./startNodeManager.sh
3) Start Managed WebLogic
cd /home/Oracle/Middleware/user_projects/domains/bifoundation_domain/bin/
./startManagedWebLogic.sh bi_server1
4) Set up OBIEE Components
cd /home/Oracle/Middleware/instances/instance1/bin/
./opmnctl startall
The result is:
opmnctl startall: starting opmn and all managed processes...
================================================================================
opmn id=JustiziaInf.mmmmm.mmmmm.9999
Response: 4 of 5 processes started.
ias-instance id=instance1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ias-component/process-type/process-set:
coreapplication_obisch1/OracleBISchedulerComponent/coreapplication_obisch1/
Error
--> Process (index=1,uid=1064189424,pid=4396)
failed to start a managed process after the maximum retry limit
Log:
/home/Oracle/Middleware/instances/instance1/diagnostics/logs/OracleBISchedulerComponent/
coreapplication_obisch1/console~coreapplication_obisch1~1.log
5) Check the status of components
cd /home/Oracle/Middleware/instances/instance1/bin/
./opmnctl status
Processes in Instance: instance1
---------------------------------+--------------------+---------+---------
ias-component | process-type | pid | status
---------------------------------+--------------------+---------+---------
coreapplication_obiccs1 | OracleBIClusterCo~ | 8221 | Alive
coreapplication_obisch1 | OracleBIScheduler~ | N/A | Down
coreapplication_obijh1 | OracleBIJavaHostC~ | 8726 | Alive
coreapplication_obips1 | OracleBIPresentat~ | 6921 | Alive
coreapplication_obis1 | OracleBIServerCom~ | 7348 | Alive
Read the log files from /home/Oracle/Middleware/instances/instance1/diagnostics/logs/OracleBISchedulerComponent/
coreapplication_obisch1/console~coreapplication_obisch1~1.log.
I would recommend trying the the steps in the below link as this is a common issue when upgrading OBIEE.
http://www.askjohnobiee.com/2012/11/fyi-opmnctl-failed-to-start-managed.html
Not sure, what your log says, but try these below steps and check if it works or not
Login as superuser
cd $ORACLE_HOME/Apache/Apache/bin
chmod 6750 .apachectl
logout and login as ORACLE user
opmnctl startproc process-type=OracleBIScheduler
I am having a consistent
Error: Failed to launch instance-id": Please try again later [Error: Timeout while waiting on RPC response -topic: "network", RPC method: "get_instance_nw_info" info: ""]
every time I am launching an instance in Openstack. I've tried it both using the OpenStack dashboard and via terminal (nova). Using the terminal, here's the command I ran:
nova boot --flavor "2" --image "b26c9acf-06c0-4ff8-b1c7-aca3052485c8" --num-instances "2" --security-groups "default" --meta description="test" test
When I check the list of instances, here's the output:
+--------------------------------------+-------------------------------------------+---
-----+------------+-------------+----------+
| ID | Name |
Status | Task State | Power State | Networks |
+--------------------------------------+-------------------------------------------+---
-----+------------+-------------+----------+
| a0477666-b810-4c73-94e6-2a66576bccac | test-a0477666-b810-4c73-94e6-2a66576bccac |
ERROR | None | NOSTATE | |
| c5822a6f-4270-4718-95c4-9f28fea8de82 | test-c5822a6f-4270-4718-95c4-9f28fea8de82 |
ERROR | None | NOSTATE | |
Here's a snapshot of the error I am encountering:
Am I missing a configuration entry (i.e. using dashboard) or sub-command (i.e. in using nova via terminal) during launching?
Any feedback is greatly appreciated. Thanks in advance!