Re: [Openstack] heat-watch problem
As Steven told me on IRC, the problem was that the user associated with
my EC2 creds had the heat_stack_user role in keystone.
This role is intended to be used only for the in-instance users, created
as part of the stack, not real human users. This is described in policy.json
thanks Steven,
btw: any idea about the first problem?
m.
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
Le 03/07/2013 16:21, Michaël Van de Borne a écrit :
Hello Steven,
I'm mikemowgli from IRC. As requested, here are the logs.
1. First, here's a stack trace I*get in my shell periodically (once
per minute approximately), but not in the logs: *
http://pastebin.com/kPswnGNL
(this might not be related to cloudwatch as I got this permanently)
2. Then, here is the error I get when I perform a heat-watch command.
The logs of engine and cloudwatch are in attachment. In order to
minimize their size, I launched and killed the daemons for this single
heat-watch command.
It seems that my AWS creds are accepted, but that the user does have
enough permissions. However, in keystone, the heat user is admin of
the service tenant. The config files of engine, cloudwatch and boto
(2.9.0) are also in attachment.
grizzly@leonard:~$ heat-watch -d describe
DEBUG:Debug level logging enabled
INFO:No AlarmName passed, getting results for ALL alarms
DEBUG:Using access key found in config file.
DEBUG:Using secret key found in config file.
DEBUG:Got CW connection object OK
DEBUG:Method: GET
DEBUG:Path: /v1/
DEBUG:Data:
DEBUG:Headers: {}
DEBUG:Host: 192.168.202.103:8003
DEBUG:Params: {'Action': 'DescribeAlarms', 'Version': '2010-08-01',
'AlarmNames.member.1': None}
DEBUG:establishing HTTP connection: kwargs={'timeout': 70}
DEBUG:Token: None
DEBUG:using _calc_signature_2
DEBUG:query string:
AWSAccessKeyId=88da7b10ddbe4f4cad198477352ef9fcAction=DescribeAlarmsAlarmNames.member.1=NoneSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2013-07-03T14%3A08%3A54ZVersion=2010-08-01
DEBUG:string_to_sign: GET
192.168.202.103:8003
/v1/
AWSAccessKeyId=88da7b10ddbe4f4cad198477352ef9fcAction=DescribeAlarmsAlarmNames.member.1=NoneSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2013-07-03T14%3A08%3A54ZVersion=2010-08-01
DEBUG:len(b64)=44
DEBUG:base64 encoded digest: UaFV/v+FEOEIStrQR7BAH2ci0uGjlWP+p1TwLO8FVM0=
DEBUG:query_string:
AWSAccessKeyId=88da7b10ddbe4f4cad198477352ef9fcAction=DescribeAlarmsAlarmNames.member.1=NoneSignatureMethod=HmacSHA256SignatureVersion=2Timestamp=2013-07-03T14%3A08%3A54ZVersion=2010-08-01
Signature: UaFV/v+FEOEIStrQR7BAH2ci0uGjlWP+p1TwLO8FVM0=
DEBUG:ErrorResponseErrorMessageUser is not authorized to perform
action:Action DescribeAlarms not allowed for
user/MessageCodeAccessDenied/CodeTypeSender/Type/Error/ErrorResponse
ERROR:403 AccessDenied
ERROR:ErrorResponseErrorMessageUser is not authorized to perform
action:Action DescribeAlarms not allowed for
user/MessageCodeAccessDenied/CodeTypeSender/Type/Error/ErrorResponse
Traceback (most recent call last):
File /usr/local/bin/heat-watch, line 281, in module
main()
File /usr/local/bin/heat-watch, line 268, in main
result = cmd(opts, args)
File
/usr/local/lib/python2.7/dist-packages/heat/cfn_client/utils.py,
line 32, in wrapper
ret = func(*arguments, **kwargs)
File /usr/local/bin/heat-watch, line 65, in alarm_describe
result = c.describe_alarm(**parameters)
File
/usr/local/lib/python2.7/dist-packages/heat/cfn_client/boto_client_cloudwatch.py,
line 57, in describe_alarm
alarm_names=[name])
File
/usr/local/lib/python2.7/dist-packages/boto/ec2/cloudwatch/__init__.py,
line 393, in describe_alarms
[('MetricAlarms', MetricAlarms)])
File /usr/local/lib/python2.7/dist-packages/boto/connection.py,
line 1049, in get_list
raise self.ResponseError(response.status, response.reason, body)
boto.exception.BotoServerError: BotoServerError: 403 AccessDenied
ErrorResponseErrorMessageUser is not authorized to perform
action:Action DescribeAlarms not allowed for
user/MessageCodeAccessDenied/CodeTypeSender/Type/Error/ErrorResponse
thank you for your help,
michaël
--
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] VMs can't access internet if floating ip associated
no idea? Le 30/04/2013 02:15, Michaël Van de Borne a écrit : Hi there, I'm running Grizzly on Ubuntu 12.04 in this topology: http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html and using the per-tenant routers with private networks. I just found out that my VMs (except just one) can't access internet if I associate them a floating ip. As soon as I disassociate the floating ip, the VM can ping 8.8.8.8 Did anyone experienced this? Here is the iptables-save of the virtual router (configured thanks to the l3 agent): (the VMs floating IPs are 192.168.202.X. The even wierdest thing is that only the VM using the 192.168.202.4 floating ip can access the internet). thanks for your help... root@rajesh:~# ip netns exec qrouter-e75c9ae7-c814-42c3-bd9e-9002c025aa95 iptables-save # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *mangle :PREROUTING ACCEPT [103801:72619178] :INPUT ACCEPT [29779:8190400] :FORWARD ACCEPT [73997:64361803] :OUTPUT ACCEPT [3336:330688] :POSTROUTING ACCEPT [77333:64692491] COMMIT # Completed on Tue Apr 30 01:52:01 2013 # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *nat :PREROUTING ACCEPT [1:84] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :quantum-l3-agent-OUTPUT - [0:0] :quantum-l3-agent-POSTROUTING - [0:0] :quantum-l3-agent-PREROUTING - [0:0] :quantum-l3-agent-float-snat - [0:0] :quantum-l3-agent-snat - [0:0] :quantum-postrouting-bottom - [0:0] -A PREROUTING -j quantum-l3-agent-PREROUTING -A OUTPUT -j quantum-l3-agent-OUTPUT -A POSTROUTING -j quantum-l3-agent-POSTROUTING -A POSTROUTING -j quantum-postrouting-bottom -A quantum-l3-agent-OUTPUT -d 192.168.202.4/32 -j DNAT --to-destination 10.0.0.4 -A quantum-l3-agent-OUTPUT -d 192.168.202.3/32 -j DNAT --to-destination 10.0.0.2 -A quantum-l3-agent-OUTPUT -d 192.168.202.6/32 -j DNAT --to-destination 10.0.0.5 -A quantum-l3-agent-POSTROUTING ! -i qg-53c422b7-8a ! -o qg-53c422b7-8a -m conntrack ! --ctstate DNAT -j ACCEPT -A quantum-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697 -A quantum-l3-agent-PREROUTING -d 192.168.202.4/32 -j DNAT --to-destination 10.0.0.4 -A quantum-l3-agent-PREROUTING -d 192.168.202.3/32 -j DNAT --to-destination 10.0.0.2 -A quantum-l3-agent-PREROUTING -d 192.168.202.6/32 -j DNAT --to-destination 10.0.0.5 -A quantum-l3-agent-float-snat -s 10.0.0.4/32 -j SNAT --to-source 192.168.202.4 -A quantum-l3-agent-float-snat -s 10.0.0.2/32 -j SNAT --to-source 192.168.202.3 -A quantum-l3-agent-float-snat -s 10.0.0.5/32 -j SNAT --to-source 192.168.202.6 -A quantum-l3-agent-snat -j quantum-l3-agent-float-snat -A quantum-l3-agent-snat -s 10.0.0.0/24 -j SNAT --to-source 192.168.202.2 -A quantum-postrouting-bottom -j quantum-l3-agent-snat COMMIT # Completed on Tue Apr 30 01:52:01 2013 # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [23:2028] :OUTPUT ACCEPT [0:0] :quantum-filter-top - [0:0] :quantum-l3-agent-FORWARD - [0:0] :quantum-l3-agent-INPUT - [0:0] :quantum-l3-agent-OUTPUT - [0:0] :quantum-l3-agent-local - [0:0] -A INPUT -j quantum-l3-agent-INPUT -A FORWARD -j quantum-filter-top -A FORWARD -j quantum-l3-agent-FORWARD -A OUTPUT -j quantum-filter-top -A OUTPUT -j quantum-l3-agent-OUTPUT -A quantum-filter-top -j quantum-l3-agent-local -A quantum-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j ACCEPT COMMIT # Completed on Tue Apr 30 01:52:01 2013 michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Grizzly] VMs can't access internet if floating ip associated
Hi there, I'm running Grizzly on Ubuntu 12.04 in this topology: http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html and using the per-tenant routers with private networks. I just found out that my VMs (except just one) can't access internet if I associate them a floating ip. As soon as I disassociate the floating ip, the VM can ping 8.8.8.8 Did anyone experienced this? Here is the iptables-save of the virtual router (configured thanks to the l3 agent): (the VMs floating IPs are 192.168.202.X. The even wierdest thing is that only the VM using the 192.168.202.4 floating ip can access the internet). thanks for your help... root@rajesh:~# ip netns exec qrouter-e75c9ae7-c814-42c3-bd9e-9002c025aa95 iptables-save # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *mangle :PREROUTING ACCEPT [103801:72619178] :INPUT ACCEPT [29779:8190400] :FORWARD ACCEPT [73997:64361803] :OUTPUT ACCEPT [3336:330688] :POSTROUTING ACCEPT [77333:64692491] COMMIT # Completed on Tue Apr 30 01:52:01 2013 # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *nat :PREROUTING ACCEPT [1:84] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :quantum-l3-agent-OUTPUT - [0:0] :quantum-l3-agent-POSTROUTING - [0:0] :quantum-l3-agent-PREROUTING - [0:0] :quantum-l3-agent-float-snat - [0:0] :quantum-l3-agent-snat - [0:0] :quantum-postrouting-bottom - [0:0] -A PREROUTING -j quantum-l3-agent-PREROUTING -A OUTPUT -j quantum-l3-agent-OUTPUT -A POSTROUTING -j quantum-l3-agent-POSTROUTING -A POSTROUTING -j quantum-postrouting-bottom -A quantum-l3-agent-OUTPUT -d 192.168.202.4/32 -j DNAT --to-destination 10.0.0.4 -A quantum-l3-agent-OUTPUT -d 192.168.202.3/32 -j DNAT --to-destination 10.0.0.2 -A quantum-l3-agent-OUTPUT -d 192.168.202.6/32 -j DNAT --to-destination 10.0.0.5 -A quantum-l3-agent-POSTROUTING ! -i qg-53c422b7-8a ! -o qg-53c422b7-8a -m conntrack ! --ctstate DNAT -j ACCEPT -A quantum-l3-agent-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697 -A quantum-l3-agent-PREROUTING -d 192.168.202.4/32 -j DNAT --to-destination 10.0.0.4 -A quantum-l3-agent-PREROUTING -d 192.168.202.3/32 -j DNAT --to-destination 10.0.0.2 -A quantum-l3-agent-PREROUTING -d 192.168.202.6/32 -j DNAT --to-destination 10.0.0.5 -A quantum-l3-agent-float-snat -s 10.0.0.4/32 -j SNAT --to-source 192.168.202.4 -A quantum-l3-agent-float-snat -s 10.0.0.2/32 -j SNAT --to-source 192.168.202.3 -A quantum-l3-agent-float-snat -s 10.0.0.5/32 -j SNAT --to-source 192.168.202.6 -A quantum-l3-agent-snat -j quantum-l3-agent-float-snat -A quantum-l3-agent-snat -s 10.0.0.0/24 -j SNAT --to-source 192.168.202.2 -A quantum-postrouting-bottom -j quantum-l3-agent-snat COMMIT # Completed on Tue Apr 30 01:52:01 2013 # Generated by iptables-save v1.4.12 on Tue Apr 30 01:52:01 2013 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [23:2028] :OUTPUT ACCEPT [0:0] :quantum-filter-top - [0:0] :quantum-l3-agent-FORWARD - [0:0] :quantum-l3-agent-INPUT - [0:0] :quantum-l3-agent-OUTPUT - [0:0] :quantum-l3-agent-local - [0:0] -A INPUT -j quantum-l3-agent-INPUT -A FORWARD -j quantum-filter-top -A FORWARD -j quantum-l3-agent-FORWARD -A OUTPUT -j quantum-filter-top -A OUTPUT -j quantum-l3-agent-OUTPUT -A quantum-filter-top -j quantum-l3-agent-local -A quantum-l3-agent-INPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 9697 -j ACCEPT COMMIT # Completed on Tue Apr 30 01:52:01 2013 michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] VMs not authorized by metadata server
Hi,
1. yes.
2. yes. Moreover, I have to kill it manually and delete the pid file and
then restart l3-agent, cause otherwise it stays alive. No error in its
log file.
3. yes. Here are the corresponding keys for this shared secret:
# on the controller node
root@leonard:~# cat /etc/nova/nova.conf | grep secret
quantum_metadata_proxy_shared_secret=grizzly
# on the network node
root@rajesh:/var/log/quantum# cat /etc/quantum/metadata_agent.ini | grep
secret
metadata_proxy_shared_secret=grizzly
By the way, I tried to mismatch the secret, and I got an error saying
that the secrets did not match. So I guess the error (unauthorized) I'm
getting isn't related to the secret.
any other idea?
thanks
Le 28/04/2013 07:28, Gary Kotton a écrit :
On 04/27/2013 12:44 PM, Michaël Van de Borne wrote:
Anybody has an idea about why the nova metadata server rejects the VM
requests?
Hi,
Just a few questions:-
1. Can you please check /etc/quantum/metadata_agent.ini to see that
you have the correct quantum keystone credential configured?
2. Can you please make sure that you are running the quantum metadata
proxy.
3. In nova.conf can you please see that
service_quantum_metadata_proxy = True is set.
Thanks
Gary
Le 26/04/2013 15:58, Michaël Van de Borne a écrit :
Hi there,
I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).
Namespaces are ON
Overlapping IPs are ON
When booting, my VMs can reach the metadata server (on the
controller node), but it responds a 500 Internal Server Error
*Here is the error from the log of nova-api:*
2013-04-26 15:35:28.149 19902 INFO nova.metadata.wsgi.server [-]
(19902) accepted ('192.168.202.105', 54871)
2013-04-26 15:35:28.346 ERROR nova.network.quantumv2
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None]
_get_auth_token() failed
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 Traceback
(most recent call last):
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 40, in _get_auth_token
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
httpclient.authenticate()
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
193, in authenticate
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
content_type=application/json)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
131, in _cs_request
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 raise
exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Unauthorized: {error: {message: The request you have made
requires authentication., code: 401, title: Not Authorized}}
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
2013-04-26 15:35:28.347 ERROR nova.api.metadata.handler
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] Failed to get
metadata for instance id: 05141f81-04cc-4493-86da-d2c05fd8a2f9
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Traceback (most recent call last):
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py,
line 179, in _handle_instance_id_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
remote_address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py,
line 90, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
instance_id, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line
417, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
return InstanceMetadata(instance, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line
143, in __init__
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
conductor_api=capi)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py,
line 359, in get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
result = self._get_instance_nw_info(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py,
line 367, in _get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
nw_info = self._build_network_info_model(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py
Re: [Openstack] [Grizzly] VMs not authorized by metadata server
I think I'm getting closer here. Whenever a VM requests metadata, the
quantum-metadata-agent tries to authenticate to keystone.
correct credentials for my config are
admin_tenant_name = service
admin_user = quantum
admin_password = grizzly
*BUT*
in the keystone log, I can see this
2013-04-28 19:36:33DEBUG [keystone.common.wsgi]
REQUEST BODY
2013-04-28 19:36:33DEBUG [keystone.common.wsgi] {auth:
{tenantName: service, passwordCredentials: {username: quantum,
password: *password*}}}
2013-04-28 19:36:33DEBUG [keystone.common.wsgi]
2013-04-28 19:36:33DEBUG [keystone.common.wsgi] arg_dict: {}
2013-04-28 19:36:33 WARNING [keystone.common.wsgi] Authorization
failed. Invalid user / password from 192.168.203.103
Means that whatever the password I configured in
/etc/quantum/metadata_agent.ini, the one that is sent to keystone is
password.
How can it be? is it a bug? has it been stored persistently in the DB?
and how can I change that?
thanks,
m.
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
Le 28/04/2013 10:35, Michaël Van de Borne a écrit :
Hi,
1. yes.
2. yes. Moreover, I have to kill it manually and delete the pid file
and then restart l3-agent, cause otherwise it stays alive. No error in
its log file.
3. yes. Here are the corresponding keys for this shared secret:
# on the controller node
root@leonard:~# cat /etc/nova/nova.conf | grep secret
quantum_metadata_proxy_shared_secret=grizzly
# on the network node
root@rajesh:/var/log/quantum# cat /etc/quantum/metadata_agent.ini |
grep secret
metadata_proxy_shared_secret=grizzly
By the way, I tried to mismatch the secret, and I got an error saying
that the secrets did not match. So I guess the error (unauthorized)
I'm getting isn't related to the secret.
any other idea?
thanks
Le 28/04/2013 07:28, Gary Kotton a écrit :
On 04/27/2013 12:44 PM, Michaël Van de Borne wrote:
Anybody has an idea about why the nova metadata server rejects the
VM requests?
Hi,
Just a few questions:-
1. Can you please check /etc/quantum/metadata_agent.ini to see that
you have the correct quantum keystone credential configured?
2. Can you please make sure that you are running the quantum metadata
proxy.
3. In nova.conf can you please see that
service_quantum_metadata_proxy = True is set.
Thanks
Gary
Le 26/04/2013 15:58, Michaël Van de Borne a écrit :
Hi there,
I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).
Namespaces are ON
Overlapping IPs are ON
When booting, my VMs can reach the metadata server (on the
controller node), but it responds a 500 Internal Server Error
*Here is the error from the log of nova-api:*
2013-04-26 15:35:28.149 19902 INFO nova.metadata.wsgi.server [-]
(19902) accepted ('192.168.202.105', 54871)
2013-04-26 15:35:28.346 ERROR nova.network.quantumv2
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None]
_get_auth_token() failed
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Traceback (most recent call last):
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 40, in _get_auth_token
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
httpclient.authenticate()
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
193, in authenticate
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
content_type=application/json)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
131, in _cs_request
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
raise exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Unauthorized: {error: {message: The request you have made
requires authentication., code: 401, title: Not Authorized}}
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
2013-04-26 15:35:28.347 ERROR nova.api.metadata.handler
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] Failed to get
metadata for instance id: 05141f81-04cc-4493-86da-d2c05fd8a2f9
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Traceback (most recent call last):
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py,
line 179, in _handle_instance_id_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
remote_address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py,
line 90, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Re: [Openstack] [Grizzly] [SOLVED] VMs not authorized by metadata server
ok, nailed it. My bad.
I had misconfigured the quantum_admin_password key in the nova.conf file
of the controller.
thanks all.
(this made me search for a week...)
Le 28/04/2013 19:45, Michaël Van de Borne a écrit :
I think I'm getting closer here. Whenever a VM requests metadata, the
quantum-metadata-agent tries to authenticate to keystone.
correct credentials for my config are
admin_tenant_name = service
admin_user = quantum
admin_password = grizzly
*BUT*
in the keystone log, I can see this
2013-04-28 19:36:33DEBUG [keystone.common.wsgi]
REQUEST BODY
2013-04-28 19:36:33DEBUG [keystone.common.wsgi] {auth:
{tenantName: service, passwordCredentials: {username:
quantum, password: *password*}}}
2013-04-28 19:36:33DEBUG [keystone.common.wsgi]
2013-04-28 19:36:33DEBUG [keystone.common.wsgi] arg_dict: {}
2013-04-28 19:36:33 WARNING [keystone.common.wsgi] Authorization
failed. Invalid user / password from 192.168.203.103
Means that whatever the password I configured in
/etc/quantum/metadata_agent.ini, the one that is sent to keystone is
password.
How can it be? is it a bug? has it been stored persistently in the DB?
and how can I change that?
thanks,
m.
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
Le 28/04/2013 10:35, Michaël Van de Borne a écrit :
Hi,
1. yes.
2. yes. Moreover, I have to kill it manually and delete the pid file
and then restart l3-agent, cause otherwise it stays alive. No error
in its log file.
3. yes. Here are the corresponding keys for this shared secret:
# on the controller node
root@leonard:~# cat /etc/nova/nova.conf | grep secret
quantum_metadata_proxy_shared_secret=grizzly
# on the network node
root@rajesh:/var/log/quantum# cat /etc/quantum/metadata_agent.ini |
grep secret
metadata_proxy_shared_secret=grizzly
By the way, I tried to mismatch the secret, and I got an error saying
that the secrets did not match. So I guess the error (unauthorized)
I'm getting isn't related to the secret.
any other idea?
thanks
Le 28/04/2013 07:28, Gary Kotton a écrit :
On 04/27/2013 12:44 PM, Michaël Van de Borne wrote:
Anybody has an idea about why the nova metadata server rejects the
VM requests?
Hi,
Just a few questions:-
1. Can you please check /etc/quantum/metadata_agent.ini to see that
you have the correct quantum keystone credential configured?
2. Can you please make sure that you are running the quantum
metadata proxy.
3. In nova.conf can you please see that
service_quantum_metadata_proxy = True is set.
Thanks
Gary
Le 26/04/2013 15:58, Michaël Van de Borne a écrit :
Hi there,
I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).
Namespaces are ON
Overlapping IPs are ON
When booting, my VMs can reach the metadata server (on the
controller node), but it responds a 500 Internal Server Error
*Here is the error from the log of nova-api:*
2013-04-26 15:35:28.149 19902 INFO nova.metadata.wsgi.server [-]
(19902) accepted ('192.168.202.105', 54871)
2013-04-26 15:35:28.346 ERROR nova.network.quantumv2
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None]
_get_auth_token() failed
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Traceback (most recent call last):
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 40, in _get_auth_token
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
httpclient.authenticate()
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
193, in authenticate
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
content_type=application/json)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line
131, in _cs_request
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
raise exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Unauthorized: {error: {message: The request you have made
requires authentication., code: 401, title: Not Authorized}}
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
2013-04-26 15:35:28.347 ERROR nova.api.metadata.handler
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] Failed to get
metadata for instance id: 05141f81-04cc-4493-86da-d2c05fd8a2f9
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Traceback (most recent call last):
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py,
line 179, in _handle_instance_id_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
remote_address)
2013-04-26 15:35
Re: [Openstack] ceilometer and heat tutorial
thank you steve. Would you please keep posted as soon as a tutorial is available. I'm looking forward to test Heat. Anybody has a good tutorial about ceilometer? m. Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 26/04/2013 20:28, Steven Hardy a écrit : On Fri, Apr 26, 2013 at 05:02:54PM +0200, Michaël Van de Borne wrote: Hi all, I'm looking for install and usage tutorials for ceilometer and heat. The best I could find so far are these: - ceilometer: http://docs.openstack.org/developer/ceilometer/install.html - heat: https://wiki.openstack.org/wiki/Heat/GettingStartedUsingMasterOnUbuntu Unfortunately, they seem to be intended for developers. Still have to git clone the softwares. I'm looking for tutorials like this one: http://docs.openstack.org/trunk/basic-install/content/ (using apt-get, telling how to configure everything on every node, and finishing with a simple use case to validate the installation). Does anyone have something like this? For Heat, the we don't yet have this sort of package-orientated documentation, for Ubuntu this is because heat is not yet packaged for Ubuntu, it is now in Debian Experimental though: https://launchpad.net/debian/experimental/+source/heat/2013.1-1 Heat is packaged for Fedora, there are some instructions here: http://fedoraproject.org/wiki/Test_Day:2012-09-18_OpenStack HTH, Steve ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] cannot attach volume to instance due to wrong iscsi target
No I'm running just one iscsi target service: root@leonard:~# netstat -antp | grep 3260 tcp0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 8927/tgtd tcp6 0 0 :::3260 :::*LISTEN 8927/tgtd Here is my cinder.conf: root@leonard:~# cat /etc/cinder/cinder.conf [DEFAULT] rootwrap_config = /etc/cinder/rootwrap.conf api_paste_confg = /etc/cinder/api-paste.ini iscsi_helper = tgtadm volume_name_template = volume-%s volume_group = cinder-volumes verbose = True auth_strategy = keystone state_path = /var/lib/cinder lock_path = /var/lock/cinder volumes_dir = /var/lib/cinder/volumes sql_connection = mysql://cinder:grizzly@leonard/cinder rabbit_password = grizzly iscsi_ip_address=192.168.203.103 So how can the compute node try to reach the public interface of the controller? How can it possibly even know this IP? Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 26/04/2013 20:22, K, Shanthakumar a écrit : I believe you are using both iscsitarget and tgt in your configuration, that's why you are getting this issue. Stop any one target and mark the current target in cinder.conf iscsihelper=targetname Example : iscsi_helper=tgtadm Then restart the all the services, hopefully this will work. Thanks Shanthakumar K *From:*Openstack [mailto:openstack-bounces+sk13=hp@lists.launchpad.net] *On Behalf Of *Michaël Van de Borne *Sent:* Friday, April 26, 2013 8:11 PM *To:* openstack@lists.launchpad.net *Subject:* [Openstack] [Grizzly] cannot attach volume to instance due to wrong iscsi target Hi all, I installed three nodes like this topology: http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html Here are my subnets: management: 192.168.203.X/24 data: 192.168.201.X/24 external API: 192.168.202.X/24 I'm running ubuntu 12.04. When I try to attach a volume to a VM, I get the following error in nova-compute.log: 2013-04-26 16:27:59.439 WARNING nova.virt.libvirt.volume [req-f5b4e121-a3ac-456d-b5cb-ba389c7fb409 6d72da42f39648c48d3dfb4cd190107d 93a48de7ef674f07a96e169383c34399] ISCSI volume not yet found at: vdr. Will rescan retry. Try number: 0 2013-04-26 16:27:59.490 ERROR nova.compute.manager [req-f5b4e121-a3ac-456d-b5cb-ba389c7fb409 6d72da42f39648c48d3dfb4cd190107d 93a48de7ef674f07a96e169383c34399] [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Failed to attach volume d9424219-33f6-40c8-88d9-ecba4c8aa6be at /dev/vdr 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Traceback (most recent call last): 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2859, in _attach_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] mountpoint) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 957, in attach_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] disk_info) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 943, in volume_driver_method 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] return method(connection_info, *args, **kwargs) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py, line 242, in inner 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] retval = f(*args, **kwargs) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py, line 245, in connect_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] self._run_iscsiadm(iscsi_properties, (--rescan,)) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py, line 179, in _run_iscsiadm 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] check_exit_code=check_exit_code) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/utils.py, line 239, in execute 2013
Re: [Openstack] [Grizzly] cannot attach volume to instance due to wrong iscsi target
I set that key in both controller and compute still no luck Le 26/04/2013 18:26, Darragh O'Reilly a écrit : its not really obvious, but I believe the iscsi_ip_address needs to be set in the nova.conf on the **controller** - just want to check you did it there. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] VMs not authorized by metadata server
Anybody has an idea about why the nova metadata server rejects the VM
requests?
Le 26/04/2013 15:58, Michaël Van de Borne a écrit :
Hi there,
I've installed Grizzly on 3 servers:
compute (howard)
controller (leonard)
network (rajesh)).
Namespaces are ON
Overlapping IPs are ON
When booting, my VMs can reach the metadata server (on the controller
node), but it responds a 500 Internal Server Error
*Here is the error from the log of nova-api:*
2013-04-26 15:35:28.149 19902 INFO nova.metadata.wsgi.server [-]
(19902) accepted ('192.168.202.105', 54871)
2013-04-26 15:35:28.346 ERROR nova.network.quantumv2
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] _get_auth_token()
failed
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 Traceback
(most recent call last):
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 40, in _get_auth_token
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
httpclient.authenticate()
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 193,
in authenticate
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
content_type=application/json)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 131,
in _cs_request
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2 raise
exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
Unauthorized: {error: {message: The request you have made
requires authentication., code: 401, title: Not Authorized}}
2013-04-26 15:35:28.346 19902 TRACE nova.network.quantumv2
2013-04-26 15:35:28.347 ERROR nova.api.metadata.handler
[req-52ffc3ae-a15e-4bf4-813c-6596618eb430 None None] Failed to get
metadata for instance id: 05141f81-04cc-4493-86da-d2c05fd8a2f9
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Traceback (most recent call last):
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py, line
179, in _handle_instance_id_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
remote_address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/handler.py, line
90, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
instance_id, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line
417, in get_metadata_by_instance_id
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler return
InstanceMetadata(instance, address)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py, line
143, in __init__
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
conductor_api=capi)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, line
359, in get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler result =
self._get_instance_nw_info(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, line
367, in _get_instance_nw_info
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler nw_info
= self._build_network_info_model(context, instance, networks)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/api.py, line
777, in _build_network_info_model
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler client =
quantumv2.get_client(context, admin=True)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 67, in get_client
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler return
_get_client(token=token)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 49, in _get_client
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler token =
_get_auth_token()
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/nova/network/quantumv2/__init__.py,
line 43, in _get_auth_token
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
LOG.exception(_(_get_auth_token() failed))
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/contextlib.py, line 24, in __exit__
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
self.gen.next()
2013-04-26 15:35:28.347 19902 TRACE
Re: [Openstack] [Grizzly] cannot attach volume to instance due to wrong iscsi target
yes it was already. Le 27/04/2013 14:08, Darragh O'Reilly a écrit : is nova configured to use cinder? in nova.conf volume_api_class=nova.volume.cinder.API ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Grizzly] [SOLVED] cannot attach volume to instance due to wrong iscsi target
Man, this is awesome! that did it! thank you very much. Le 27/04/2013 17:13, Darragh O'Reilly a écrit : it seems the ips for the targets are set at the time they were created $ mysqlmysql use cinder; mysql select provider_location from volumes; Try creating a new volume - does it get the new iscsi_ip_address ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [Grizzly] VMs not authorized by metadata server
, in _get_auth_token
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
httpclient.authenticate()
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 193, in
authenticate
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
content_type=application/json)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler File
/usr/lib/python2.7/dist-packages/quantumclient/client.py, line 131, in
_cs_request
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler raise
exceptions.Unauthorized(message=body)
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
Unauthorized: {error: {message: The request you have made requires
authentication., code: 401, title: Not Authorized}}
2013-04-26 15:35:28.347 19902 TRACE nova.api.metadata.handler
2013-04-26 15:35:28.349 19902 INFO nova.api.ec2 [-] 0.198106s
192.168.202.105 GET /2009-04-04/meta-data/instance-id None:None 500
[Python-httplib2/0.7.2 (gzip)] text/plain text/plain
2013-04-26 15:35:28.349 19902 INFO nova.metadata.wsgi.server [-]
10.0.0.4,192.168.202.105 GET /2009-04-04/meta-data/instance-id
HTTP/1.1 status: 500 len: 229 time: 0.1988521
*On the network node, here is the config file for metadata agent:*
root@rajesh:/var/log/quantum# cat /etc/quantum/metadata_agent.ini
[DEFAULT]
debug = True
auth_url = http://192.168.203.103:35357/v2.0
auth_region = RegionOne
admin_tenant_name = service
admin_user = quantum
admin_password = grizzly
nova_metadata_ip = 192.168.202.103
nova_metadata_port = 8775
metadata_proxy_shared_secret = grizzly
*Here are the metadata keys from the nova.conf of the controller node:*
service_quantum_metadata_proxy=true
quantum_metadata_proxy_shared_secret=grizzly
*I tried to curl the controller node like this:*
root@leonard:~# curl -H x-instance-id:
05141f81-04cc-4493-86da-d2c05fd8a2f9 -H x-instance-id-signature:
1de544a5fc4c1b8d5fb37441bf4c1360ab63336b58dfb3f4b78d290c5268b4e5
http://192.168.202.103:8775/2009-04-04/meta-data/instance-id
html
head
title500 Internal Server Error/title
/head
body
h1500 Internal Server Error/h1
An unknown error has occurred. Please try your request again.br /br /
*I should add that the quantum-ns-proxy log file on the network node
remains empty.*
*Here is the metadata **agent log:*
2013-04-26 15:37:16 WARNING [quantum.agent.metadata.agent] Remote
metadata server experienced an internal server error.
any clue why the request to metadata server cannot be authorized?
thanks,
yours,
mike
--
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] [Grizzly] cannot attach volume to instance due to wrong iscsi target
Hi all, I installed three nodes like this topology: http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html Here are my subnets: management: 192.168.203.X/24 data: 192.168.201.X/24 external API: 192.168.202.X/24 I'm running ubuntu 12.04. When I try to attach a volume to a VM, I get the following error in nova-compute.log: 2013-04-26 16:27:59.439 WARNING nova.virt.libvirt.volume [req-f5b4e121-a3ac-456d-b5cb-ba389c7fb409 6d72da42f39648c48d3dfb4cd190107d 93a48de7ef674f07a96e169383c34399] ISCSI volume not yet found at: vdr. Will rescan retry. Try number: 0 2013-04-26 16:27:59.490 ERROR nova.compute.manager [req-f5b4e121-a3ac-456d-b5cb-ba389c7fb409 6d72da42f39648c48d3dfb4cd190107d 93a48de7ef674f07a96e169383c34399] [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Failed to attach volume d9424219-33f6-40c8-88d9-ecba4c8aa6be at /dev/vdr 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Traceback (most recent call last): 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2859, in _attach_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] mountpoint) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 957, in attach_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] disk_info) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 943, in volume_driver_method 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] return method(connection_info, *args, **kwargs) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/openstack/common/lockutils.py, line 242, in inner 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] retval = f(*args, **kwargs) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py, line 245, in connect_volume 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] self._run_iscsiadm(iscsi_properties, (--rescan,)) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/volume.py, line 179, in _run_iscsiadm 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] check_exit_code=check_exit_code) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] File /usr/lib/python2.7/dist-packages/nova/utils.py, line 239, in execute 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] cmd=' '.join(cmd)) 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] ProcessExecutionError: Unexpected error while running command. 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Command: sudo nova-rootwrap /etc/nova/rootwrap.conf iscsiadm -m node -T iqn.2010-10.org.openstack:volume-d9424219-33f6-40c8-88d9-ecba4c8aa6be -p _/*192.168.202.103*/_:3260 --rescan 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Exit code: 255 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Stdout: '' 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] Stderr: 'iscsiadm: No portal found.\n' 2013-04-26 16:27:59.490 30092 TRACE nova.compute.manager [instance: 05141f81-04cc-4493-86da-d2c05fd8a2f9] 2013-04-26 16:27:59.849 ERROR nova.openstack.common.rpc.amqp [req-f5b4e121-a3ac-456d-b5cb-ba389c7fb409 6d72da42f39648c48d3dfb4cd190107d 93a48de7ef674f07a96e169383c34399] Exception during message handling As we can see, the compute node tries to reach the API interface (192.168.202.103) of the controller node. Of course, it cannot, since the compute node only knows the data and the management subnets. Is this the default behaviour and I'm missing a parameter somewhere? I set this key in nova.conf: iscsi_ip_address=192.168.203.103 but still no luck any clue? yours, michaël -- Michaël Van de Borne RD
[Openstack] ceilometer and heat tutorial
Hi all, I'm looking for install and usage tutorials for ceilometer and heat. The best I could find so far are these: - ceilometer: http://docs.openstack.org/developer/ceilometer/install.html - heat: https://wiki.openstack.org/wiki/Heat/GettingStartedUsingMasterOnUbuntu Unfortunately, they seem to be intended for developers. Still have to git clone the softwares. I'm looking for tutorials like this one: http://docs.openstack.org/trunk/basic-install/content/ (using apt-get, telling how to configure everything on every node, and finishing with a simple use case to validate the installation). Does anyone have something like this? thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon Keystone Endpoint Issue
192.168.202.103 = public controller iface
192.168.203.103 = private controller iface
anyway, I still get the login problem using any of those values
Le 20/02/2013 06:59, Kieran Spear a écrit :
On 20 February 2013 03:40, Michaël Van de Borne
michael.vandebo...@cetic.be mailto:michael.vandebo...@cetic.be wrote:
Same problem here. Running Grizzly. Dashboard keeps prompting me
for my credentials. Pretty sure dashboard sends wrong tenant name
to keystone.
Here's the relevant section in
/etc/openstack-dashboard/local-settings.py:
OPENSTACK_HOST = 192.168.202.103
OPENSTACK_KEYSTONE_URL = http://%s:5000/v2.0;
http://%s:5000/v2.0 % OPENSTACK_HOST
#OPENSTACK_KEYSTONE_DEFAULT_ROLE = Member
OPENSTACK_KEYSTONE_DEFAULT_ROLE = admin
Is that 202 a typo? You used 192.168.203.103 later.
Cheers,
Kieran
michaël
Le 13/02/2013 16:13, Razique Mahroua a écrit :
Is the dash configured to talk with the Keystone backend?
can you run something like $ keystone endoint-list
thanks
*Razique Mahroua** - **Nuage Co*
razique.mahr...@gmail.com mailto:razique.mahr...@gmail.com
Tel : +33 9 72 37 94 15 tel:%2B33%209%2072%2037%2094%2015
Le 12 févr. 2013 à 16:54, Logan McNaughton lo...@bacoosta.com
mailto:lo...@bacoosta.com a écrit :
I've had this problem before, in my experience it's not a
problem with keystone, it's a problem with nova (by the looks of
the traceback). I believe it's a bug in Horizon because you'll
find a lot of people with this issue if you Google it. I don't
have an answer on how to fix it, other than don't fixate on the
EndpointNotFound, look to your nova configs for a solution.
On Tue, Feb 12, 2013 at 5:03 AM, Trinath Somanchi
trinath.soman...@gmail.com mailto:trinath.soman...@gmail.com
wrote:
Hi Stackers-
I have successfully installed folsom in my test setup.
But when I browse Horison, with admin/password as
credentials, I get this error.
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error] unable to
retrieve service catalog with token
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error] Traceback
(most recent call last):
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error] File
/usr/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py,
line 132, in _extract_service_catalog
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error]
endpoint_type='adminURL')
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error] File
/usr/lib/python2.7/dist-packages/keystoneclient/service_catalog.py,
line 62, in url_for
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error] raise
exceptions.EndpointNotFound('Endpoint not found.')
[Tue Feb 12 10:03:16 2013 tel:16%202013] [error]
EndpointNotFound: Endpoint not found.
[Tue Feb 12 10:03:17 2013] [error] \x1b[31;1mUnauthorized:
n/a (HTTP 401)\x1b[0m
[Tue Feb 12 10:03:17 2013] [error] Traceback (most recent
call last):
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/horizon/usage/base.py,
line 93, in summarize
[Tue Feb 12 10:03:17 2013] [error] self.usage_list =
self.get_usage_list(start, end)
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/horizon/usage/base.py,
line 128, in get_usage_list
[Tue Feb 12 10:03:17 2013] [error] return
api.usage_list(self.request, start, end)
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/horizon/api/nova.py, line
418, in usage_list
[Tue Feb 12 10:03:17 2013] [error] return [Usage(u) for
u in novaclient(request).usage.list(start, end, True)]
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/novaclient/v1_1/usage.py,
line 35, in list
[Tue Feb 12 10:03:17 2013] [error] tenant_usages)
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/novaclient/base.py, line
62, in _list
[Tue Feb 12 10:03:17 2013] [error] _resp, body =
self.api.client.get(url)
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/novaclient/client.py,
line 239, in get
[Tue Feb 12 10:03:17 2013] [error] return
self._cs_request(url, 'GET', **kwargs)
[Tue Feb 12 10:03:17 2013] [error] File
/usr/lib/python2.7/dist-packages/novaclient/client.py,
line 236, in _cs_request
[Tue Feb 12 10:03:17 2013] [error] raise ex
[Tue Feb 12 10:03:17 2013] [error] Unauthorized: n/a (HTTP 401)
It says , I missed some End point Configuration.
But then, I have configured it correctly.
Can any one guide me resolving this issue.
Thanks
Re: [Openstack] Horizon Keystone Endpoint Issue
Same problem here. Running Grizzly. Dashboard keeps prompting me for my credentials. Pretty sure dashboard sends wrong tenant name to keystone. Here is the keystone.log entry: 2013-02-19 16:55:06 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 192.168.203.103 here are the endpoints: grizzly@leonard:/etc/init.d$ keystone endpoint-list WARNING: Bypassing authentication using a token endpoint (authentication credentials are being ignored). +--+--+---+---+--+--+ | id | region | publicurl | internalurl | adminurl | service_id | +--+--+---+---+--+--+ | 0f9dbbb5ac764e0794464abcb46047a2 | myregion | http://192.168.203.103:9292 | http://192.168.203.103:9292 | http://192.168.203.103:9292 | 0ad102dc14eb4866af351358e372cb23 | | 1c45042b6bb64fd7b6f56d7348e86103 | myregion | http://192.168.202.103:5000/v2.0 | http://192.168.203.103:5000/v2.0 | http://192.168.203.103:35357/v2.0 | 37059fcb24d345f293d4add7202504bb | | 61c1c0305ffa4254b8271a2045489d9a | myregion | http://192.168.202.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | 99f1d14e769046099e85d010ed4c29da | | 9248f20cf38b4dbaa3f85abc1ee1f94d | myregion | http://192.168.202.103:8773/services/Cloud | http://192.168.203.103:8773/services/Cloud | http://192.168.203.103:8773/services/Admin | c22a33b56e67445a9550643a276a2f87 | | bdb68ba018c34cad95acb24f3ad92645 | myregion | http://192.168.202.103:9696/v2 | http://192.168.203.103:9696/v2 | http://192.168.203.103:9696/v2 | d21a72e559934837901574dfb3bc6a6c | | beaf4c028cc24068a2068ea16489eb94 | myregion | http://192.168.202.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1 | 7fc69365d1b64eb58e7ac6fcf8369ff2 | | c4f3ea0477ac428b958f5bcee2fb14e1 | myregion | http://192.168.202.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | 192.168.203.103:8776/v1/%(tenant_id)s | 19b1f3c4fa5843a295e538aab1f4cd40 | | fe82e5a1b6344c5784eb89be0d04b10b | myregion | http://192.168.202.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | ef7714abcdc04c06aa9f1ef2bdc29a3a | +--+--+---+---+--+--+ (by the way, I cannot get rid of the WARNING, but that's not the point here) Here's the relevant section in /etc/openstack-dashboard/local-settings.py: OPENSTACK_HOST = "192.168.202.103" OPENSTACK_KEYSTONE_URL = "http://%s:5000/v2.0" % OPENSTACK_HOST #OPENSTACK_KEYSTONE_DEFAULT_ROLE = "Member" OPENSTACK_KEYSTONE_DEFAULT_ROLE = "admin" I tried switching from Member to admin role, but still no luck. Nova seems properly configured: grizzly@leonard:~$ nova list grizzly@leonard:~$ echo $? 0 Any idea how to make horizon and keystone talking together? michal Le 13/02/2013 16:13, Razique Mahroua a crit: Is the dash configured to talk with the Keystone backend? can you run something like $ keystone endoint-list thanks Razique Mahroua-Nuage Co razique.mahr...@gmail.com Tel: +33 9 72 37 94 15 Le 12 fvr. 2013 16:54, Logan McNaughton lo...@bacoosta.com a crit : I've had this problem before, in my experience it's not a problem with keystone, it's a problem with nova (by the looks of the traceback). I believe it's a bug in Horizon because you'll find a lot of people with this issue if you Google it. I don't have an answer on how to fix it, other than don't fixate on the "EndpointNotFound", look to your nova
Re: [Openstack] Horizon Keystone Endpoint Issue
I checked /etc/nova/api-paste.ini. Here's the relevant section in it: [filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory auth_host = 192.168.203.103 auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = nova admin_password = openstack signing_dir = /tmp/keystone-signing-nova I played with the tenant name (admin, service), the port (35357, 5000) and the user (nova, admin) and various combination of all those. I also changed keystone by keystoneclient in the 'paste.filter_factory' line (as I saw both in doc) still no luck. any clue? Le 19/02/2013 17:40, Michal Van de Borne a crit: Same problem here. Running Grizzly. Dashboard keeps prompting me for my credentials. Pretty sure dashboard sends wrong tenant name to keystone. Here is the keystone.log entry: 2013-02-19 16:55:06 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 192.168.203.103 here are the endpoints: grizzly@leonard:/etc/init.d$ keystone endpoint-list WARNING: Bypassing authentication using a token endpoint (authentication credentials are being ignored). +--+--+---+---+--+--+ | id | region | publicurl | internalurl | adminurl | service_id | +--+--+---+---+--+--+ | 0f9dbbb5ac764e0794464abcb46047a2 | myregion | http://192.168.203.103:9292 | http://192.168.203.103:9292 | http://192.168.203.103:9292 | 0ad102dc14eb4866af351358e372cb23 | | 1c45042b6bb64fd7b6f56d7348e86103 | myregion | http://192.168.202.103:5000/v2.0 | http://192.168.203.103:5000/v2.0 | http://192.168.203.103:35357/v2.0 | 37059fcb24d345f293d4add7202504bb | | 61c1c0305ffa4254b8271a2045489d9a | myregion | http://192.168.202.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | 99f1d14e769046099e85d010ed4c29da | | 9248f20cf38b4dbaa3f85abc1ee1f94d | myregion | http://192.168.202.103:8773/services/Cloud | http://192.168.203.103:8773/services/Cloud | http://192.168.203.103:8773/services/Admin | c22a33b56e67445a9550643a276a2f87 | | bdb68ba018c34cad95acb24f3ad92645 | myregion | http://192.168.202.103:9696/v2 | http://192.168.203.103:9696/v2 | http://192.168.203.103:9696/v2 | d21a72e559934837901574dfb3bc6a6c | | beaf4c028cc24068a2068ea16489eb94 | myregion | http://192.168.202.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1 | 7fc69365d1b64eb58e7ac6fcf8369ff2 | | c4f3ea0477ac428b958f5bcee2fb14e1 | myregion | http://192.168.202.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | 192.168.203.103:8776/v1/%(tenant_id)s | 19b1f3c4fa5843a295e538aab1f4cd40 | | fe82e5a1b6344c5784eb89be0d04b10b | myregion | http://192.168.202.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | ef7714abcdc04c06aa9f1ef2bdc29a3a | +--+--+---+---+--+--+ (by the way, I cannot get rid of the WARNING, but that's not the point here) Here's the relevant section in /etc/openstack-dashboard/local-settings.py: OPENSTACK_HOST = "192.168.202.103" OPENSTACK_KEYSTONE_URL = "http://%s:5000/v2.0" % OPENSTACK_HOST #OPENSTACK_KEYSTONE_DEFAULT_ROLE = "Member" OPENSTACK_KEYSTONE_DEFAULT_ROLE = "admin" I tried switching from Member to admin role, but still no luck. Nova seems properly configured: grizzly@leonard:~$ nova list grizzly@leonard:~$ echo $? 0 Any idea how to make horizon and keystone talking together? michal Le 13/02/2013
Re: [Openstack] Horizon Keystone Endpoint Issue
Moreover (sorry for spamming), this command works fine: root@leonard:/etc/init.d# keystone --os-username nova --os-password openstack --os-tenant-name service --os-auth-url http://192.168.203.103:5000/v2.0/ token-get +---+--+ | Property | Value | +---+--+ | expires | 2013-02-20T17:19:25Z | | id | 0eb9d38144604ced8e9fc5def623f9ca | | tenant_id | a9f86bcd83e94fbdba61862bce42e717 | | user_id | a933854b05e04921a78684368e89c47d | +---+--+ this works as well: nova --os-username nova --os-password openstack --os-tenant-name service --os-auth-url http://192.168.203.103:5000/v2.0/ list So this makes me think that users, roles, services, tenants and endpoints are configured properly in keystone. But I can be wrong... Le 19/02/2013 18:09, Michal Van de Borne a crit: I checked /etc/nova/api-paste.ini. Here's the relevant section in it: [filter:authtoken] paste.filter_factory = keystone.middleware.auth_token:filter_factory auth_host = 192.168.203.103 auth_port = 35357 auth_protocol = http admin_tenant_name = service admin_user = nova admin_password = openstack signing_dir = /tmp/keystone-signing-nova I played with the tenant name (admin, service), the port (35357, 5000) and the user (nova, admin) and various combination of all those. I also changed keystone by keystoneclient in the 'paste.filter_factory' line (as I saw both in doc) still no luck. any clue? Le 19/02/2013 17:40, Michal Van de Borne a crit: Same problem here. Running Grizzly. Dashboard keeps prompting me for my credentials. Pretty sure dashboard sends wrong tenant name to keystone. Here is the keystone.log entry: 2013-02-19 16:55:06 WARNING [keystone.common.wsgi] Authorization failed. The request you have made requires authentication. from 192.168.203.103 here are the endpoints: grizzly@leonard:/etc/init.d$ keystone endpoint-list WARNING: Bypassing authentication using a token endpoint (authentication credentials are being ignored). +--+--+---+---+--+--+ | id | region | publicurl | internalurl | adminurl | service_id | +--+--+---+---+--+--+ | 0f9dbbb5ac764e0794464abcb46047a2 | myregion | http://192.168.203.103:9292 | http://192.168.203.103:9292 | http://192.168.203.103:9292 | 0ad102dc14eb4866af351358e372cb23 | | 1c45042b6bb64fd7b6f56d7348e86103 | myregion | http://192.168.202.103:5000/v2.0 | http://192.168.203.103:5000/v2.0 | http://192.168.203.103:35357/v2.0 | 37059fcb24d345f293d4add7202504bb | | 61c1c0305ffa4254b8271a2045489d9a | myregion | http://192.168.202.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | http://192.168.203.103:8774/v2/%(tenant_id)s | 99f1d14e769046099e85d010ed4c29da | | 9248f20cf38b4dbaa3f85abc1ee1f94d | myregion | http://192.168.202.103:8773/services/Cloud | http://192.168.203.103:8773/services/Cloud | http://192.168.203.103:8773/services/Admin | c22a33b56e67445a9550643a276a2f87 | | bdb68ba018c34cad95acb24f3ad92645 | myregion | http://192.168.202.103:9696/v2 | http://192.168.203.103:9696/v2 | http://192.168.203.103:9696/v2 | d21a72e559934837901574dfb3bc6a6c | | beaf4c028cc24068a2068ea16489eb94 | myregion | http://192.168.202.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1/AUTH_%(tenant_id)s | http://192.168.203.103:8080/v1 | 7fc69365d1b64eb58e7ac6fcf8369ff2 | | c4f3ea0477ac428b958f5bcee2fb14e1 | myregion | http://192.168.202.103:8776/v1/%(tenant_id)s | http://192.168.203.103:8776/v1/%(tenant_id)s | 192.168.203.103:8776/v1/%(tenant_id)s | 19b1f3c4fa5843a295e538aab1f4cd40 | | fe82e5a1b6344c5784eb89be0d04b10b | myregion |
[Openstack] Using EC2 through OpenStack
Hi all, This might be obvious, but I can't find the answer. Is there a way to control EC2 instances using OpenStack? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Using EC2 through OpenStack
Thank you. I know about euca2ools. What I wanted to know is whether, besides being an EC2-at-home facility, OpenStack also acts on a higher level, being able to manage third-party instances (such as Scalextreme for instance). But it seems it isn't its role. thanks, michaël Le 02/10/2012 15:30, Jonathan Proulx a écrit : On Tue, Oct 02, 2012 at 12:19:45PM +0200, Michaël Van de Borne wrote: :Hi all, : :This might be obvious, but I can't find the answer. Is there a way to :control EC2 instances using OpenStack? OpenStack provides the same facility as EC2 but on your own hardware, so they don't really touch. Glance (the image store componet of OpenStack) can use S3 for storage, but I don't think it's a good idea unless you have a a really fast pipe to Amazon and deep pockets to pay transfer fees. Perhaps others have different opinions on that point (caveat: I haven't actually tried impeneting this that way) You can use some of the same tools to manage instances on both since OpenStack provides an EC2 compatible API (I've used euca2ools and hybridfox with both). -Jon ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] automate nova-volume backups
Hi all, On this very useful page http://docs.openstack.org/trunk/openstack-compute/admin/content/managing-volumes.html#d6e5059, one can find a link https://github.com/Razique/Bash-stuff/blob/master/SCR_5005_V01_NUAC-OPENSTACK-EBS-volumes-backup.sh to a script that automates the volumes backups (in section 6). Unfortunately, this link is dead. Can anyone repost it, please? By the way, is there anything similar to automate instance snapshots? thank you, yours, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Accessing VMs in Flat DHCP mode with multiple host
Hi again, So the problem is now solved. I hereby post the solution for people from the future. 1. the ping between the compute and the controller was using an IP route. So the ping wasn't using only layer 2. This means that there was no DHCP request arriving to the network controller. 2. the hosts and the VMs should be in the same subnet 3. we needed to killall dnsmasq and restart nova-network tcpdump on br100 is useful to track dhcp requests. ARP tables are useful as well in order to be sure each host sees the other on layer 2. thank you all, yours, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 10/05/2012 15:31, Yong Sheng Gong a écrit : HI, First you have to make sure the network between your control node's br100 and your compute node's br100 are connected. and then can you show the output on control node: ps -ef | grep dnsmasq brctl show ifconfig 2. can you login to your vm by vnc to see the eth0 configuration and then try to run udhcpc? Thanks -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: - To: openstack@lists.launchpad.net openstack@lists.launchpad.net From: Michaël Van de Borne michael.vandebo...@cetic.be Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net Date: 05/10/2012 09:03PM Subject: [Openstack] Accessing VMs in Flat DHCP mode with multiple host Hello, I'm running into troubles accessing my instances. I have 3 nodes: 1. proxmox that virtualizes in KVM my controller node 1.1 the controller node (10.10.200.50) runs keystone, nova-api, network, scheduler, vncproxy and volumes but NOT compute as it is already a VM 2. glance in a physical node 3. compute in a physical node my nova.conf network config is: --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=/usr/bin/nova-dhcpbridge --routing_source_ip=10.10.200.50 --libvirt_use_virtio_for_bridges=true --network_manager=nova.network.manager.FlatDHCPManager --public_interface=eth0 --flat_interface=eth1 --flat_network_bridge=br100 --fixed_range=192.168.200.0/24 --floating_range=10.10.200.0/24 --network_size=256 --flat_network_dhcp_start=192.168.200.5 --flat_injected=False --force_dhcp_release --network_host=10.10.200.50 I even explicitly allows icmp and tcp port 22 traffic like this: euca-authorize -P icmp -t -1:-1 default euca-authorize -P tcp -p 22 default before setting these rules, I was getting 'Operation not permitted' when pinging the VM from the compute node. After setting these, I just get no output at all (not even 'Destination Host Unreachable') The network was created like this: nova-manage network create private --fixed_range_v4=192.168.200.0/24 --bridge=br100 --bridge_interface=eth1 --num_networks=1 --network_size=256 However I cannot ping or ssh my instances once they're active. I have already set up such an Essex environment but the controller node was physical. Morevover, every examples in the doc presents a controller node that runs nova-compute. So I'm wondering if either: - having the controller in a VM - or not running compute on the controller would prevent things to work properly. What can I check? iptables? is dnsmasq unable to give the VM an address? I'm running out of ideas. Any suggestion would be highly appreciated. Thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Accessing VMs in Flat DHCP mode with multiple host
Hello, I'm running into troubles accessing my instances. I have 3 nodes: 1. proxmox that virtualizes in KVM my controller node 1.1 the controller node (10.10.200.50) runs keystone, nova-api, network, scheduler, vncproxy and volumes but NOT compute as it is already a VM 2. glance in a physical node 3. compute in a physical node my nova.conf network config is: --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=/usr/bin/nova-dhcpbridge --routing_source_ip=10.10.200.50 --libvirt_use_virtio_for_bridges=true --network_manager=nova.network.manager.FlatDHCPManager --public_interface=eth0 --flat_interface=eth1 --flat_network_bridge=br100 --fixed_range=192.168.200.0/24 --floating_range=10.10.200.0/24 --network_size=256 --flat_network_dhcp_start=192.168.200.5 --flat_injected=False --force_dhcp_release --network_host=10.10.200.50 I even explicitly allows icmp and tcp port 22 traffic like this: euca-authorize -P icmp -t -1:-1 default euca-authorize -P tcp -p 22 default before setting these rules, I was getting 'Operation not permitted' when pinging the VM from the compute node. After setting these, I just get no output at all (not even 'Destination Host Unreachable') The network was created like this: nova-manage network create private --fixed_range_v4=192.168.200.0/24 --bridge=br100 --bridge_interface=eth1 --num_networks=1 --network_size=256 However I cannot ping or ssh my instances once they're active. I have already set up such an Essex environment but the controller node was physical. Morevover, every examples in the doc presents a controller node that runs nova-compute. So I'm wondering if either: - having the controller in a VM - or not running compute on the controller would prevent things to work properly. What can I check? iptables? is dnsmasq unable to give the VM an address? I'm running out of ideas. Any suggestion would be highly appreciated. Thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Accessing VMs in Flat DHCP mode with multiple host
ok I'm gonna check this and I'll keep you posted. By the way, how could I check the network between the control node's br100 and the compute node's br100? I guess I can do this by checking that each bridge knows the other in the ARP table. Or did you have another idea? Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 10/05/2012 15:31, Yong Sheng Gong a écrit : HI, First you have to make sure the network between your control node's br100 and your compute node's br100 are connected. and then can you show the output on control node: ps -ef | grep dnsmasq brctl show ifconfig 2. can you login to your vm by vnc to see the eth0 configuration and then try to run udhcpc? Thanks -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: - To: openstack@lists.launchpad.net openstack@lists.launchpad.net From: Michaël Van de Borne michael.vandebo...@cetic.be Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net Date: 05/10/2012 09:03PM Subject: [Openstack] Accessing VMs in Flat DHCP mode with multiple host Hello, I'm running into troubles accessing my instances. I have 3 nodes: 1. proxmox that virtualizes in KVM my controller node 1.1 the controller node (10.10.200.50) runs keystone, nova-api, network, scheduler, vncproxy and volumes but NOT compute as it is already a VM 2. glance in a physical node 3. compute in a physical node my nova.conf network config is: --dhcpbridge_flagfile=/etc/nova/nova.conf --dhcpbridge=/usr/bin/nova-dhcpbridge --routing_source_ip=10.10.200.50 --libvirt_use_virtio_for_bridges=true --network_manager=nova.network.manager.FlatDHCPManager --public_interface=eth0 --flat_interface=eth1 --flat_network_bridge=br100 --fixed_range=192.168.200.0/24 --floating_range=10.10.200.0/24 --network_size=256 --flat_network_dhcp_start=192.168.200.5 --flat_injected=False --force_dhcp_release --network_host=10.10.200.50 I even explicitly allows icmp and tcp port 22 traffic like this: euca-authorize -P icmp -t -1:-1 default euca-authorize -P tcp -p 22 default before setting these rules, I was getting 'Operation not permitted' when pinging the VM from the compute node. After setting these, I just get no output at all (not even 'Destination Host Unreachable') The network was created like this: nova-manage network create private --fixed_range_v4=192.168.200.0/24 --bridge=br100 --bridge_interface=eth1 --num_networks=1 --network_size=256 However I cannot ping or ssh my instances once they're active. I have already set up such an Essex environment but the controller node was physical. Morevover, every examples in the doc presents a controller node that runs nova-compute. So I'm wondering if either: - having the controller in a VM - or not running compute on the controller would prevent things to work properly. What can I check? iptables? is dnsmasq unable to give the VM an address? I'm running out of ideas. Any suggestion would be highly appreciated. Thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova-manage network documentation
Hi all, I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand. The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/runnova/nova.manage.html any ideas? thanks, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova-manage network documentation
ok, done here: https://bugs.launchpad.net/openstack-manuals/+bug/996970 cheers, michal Michal Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frres Wright, 29/3, B-6041 Charleroi Le 09/05/2012 09:50, Razique Mahroua a crit: Hi Michal, would you please fill a bug here https://bugs.launchpad.net/openstack-manuals So the team could check/ update the doc Regards, Razique Nuage Co - Razique Mahroua razique.mahr...@gmail.com Le 9 mai 2012 09:40, Michal Van de Borne a crit : Hi all, I might be missing something, but I can't find any comprehensive documentation of the 'nova-manage network' subcommand. The only doc entries I find about this are examples, but no list of flags, neither in 'man nova-manage', nor in 'nova-manage --help' nor in http://nova.openstack.org/runnova/nova.manage.html any ideas? thanks, michal -- Michal Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frres Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack immaturity
I'm about to install OpenStack for a customer in a few days. It's an SME and their first production cloud would be limited to a few hosts and about 60 VMs. Do you feel it'd be worth getting their feedback about deployment and usage? yours, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 06/04/12 02:28, Michael March a écrit : I've been giving this thread some thought and it dawned on my that we need to expand this page: http://openstack.org/user-stories/ Pretty much everyone featured on that page are 'big' organizations and there really isn't any detail on their experiences of trying to deploy (and maintain) Openstack. There's definitely not stories that a mid-range sized IT shop could related to. This lack of antidotal user experiences I think contributes the perceived immaturity of OpenStack. -- Michael F. March - mma...@gmail.com mailto:mma...@gmail.com Ph: (415) 894-9269 Fax: (602)296-0400 Twitter: cowmix -- Skype: Cowmix ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard VNC Console failed to connect to server
I've got the same problem. When I try to connect to the instance using VNC through the dashboard, I've got this error. I then went in /var/log/nova/nova-xvpvncproxy.log and it contains nothing related to any attempt to get connected to any instance. It seems this nova-xvpvncproxy process doesn't notice anything. When I try to connect using VNC through virt-manager, it works. Le 30/03/12 15:50, Guilherme Birk a écrit : Thanks for the reply. I've added the flags that you mentioned on my nova.conf file. I'm using a all in one installation, the flags are configured this way. --vncserver_listen=127.0.0.1 --vncserver_proxyclient_address=127.0.0.1 --novncproxy_base_url=http://192.168.100.142:6080/vnc_auto.html The public IP of the machine with the OpenStack installation is 192.168.100.142. I've tried to access via browser the address http://192.168.100.142:6080/vnc_auto.html from another machine, but I got nothing. I can ping and ssh my instances from the OpenStack machine but can't use VNC tab at dashboard page from another machine. The details and other pages from dashboard are fine. Should I associate a public address for my instances? I'm using just the private address at them (10.0.0.2, 10.0.0.3, ...). I've restarted all the services and created new instances after changing the nova.conf, but nothing has changed. The error is a 404 not found. (*Error: *Unable to get VNC console for instance 7376e17b-e329-4b8b-b5fc-076e8a80c058.) The log from dashboards page looks like this: - Page Not Found (404) - Requested method: GET - Requested URL: *http://192.168.100.142/nova/instances_and_volumes/instances/7376e17b-e329-4b8b-b5fc-076e8a80c058/None* This is the nova-api.log relative to the VNC atempt: http://pastebin.com/wSuyctrg Thanks for your time. Guilherme Birk. Date: Thu, 29 Mar 2012 13:06:37 -0700 Subject: Re: [Openstack] Dashboard VNC Console failed to connect to server From: sleepsonthefl...@gmail.com To: guib...@hotmail.com CC: openstack@lists.launchpad.net How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com mailto:guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com mailto:luciantho...@hotmail.com To: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? *Lucian Thomaz * ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More
Re: [Openstack] Dashboard VNC Console failed to connect to server
I'm getting forward here. I installed nova-consoleauth apt-get install nova-consoleauth and I get these settings in nova.conf: --vnc_enabled=true --vncproxy_url=http://172.22.22.1:6080 --vnc_console_proxy_url=http://172.22.22.1:6080 --vncserver_listen=10.18.9.1 --novncproxy_base_url=http://172.22.22.1:6080/vnc_auto.html --xvpvncproxy_base_url=http://172.22.22.1:6081/console --xvpvncproxy_host=172.22.22.1 --xvpvncproxy_port=6081 172.22.22.1 being the 'public' NIC, and 10.18.9.1 being the private one (for VM deployements) Now, the command nova get-vnc-console servername xvpvnc gives me the url. The error in the dashboard has changed. It now says it cannot establish connection to 172.22.22.1:6080 (which is the noVNC port whereas I'm using xvpvnc). So I guess I need to tell the dashboard to try on 6081. Which setting is that? Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 30/03/12 16:36, Michaël Van de Borne a écrit : I've got the same problem. When I try to connect to the instance using VNC through the dashboard, I've got this error. I then went in /var/log/nova/nova-xvpvncproxy.log and it contains nothing related to any attempt to get connected to any instance. It seems this nova-xvpvncproxy process doesn't notice anything. When I try to connect using VNC through virt-manager, it works. Le 30/03/12 15:50, Guilherme Birk a écrit : Thanks for the reply. I've added the flags that you mentioned on my nova.conf file. I'm using a all in one installation, the flags are configured this way. --vncserver_listen=127.0.0.1 --vncserver_proxyclient_address=127.0.0.1 --novncproxy_base_url=http://192.168.100.142:6080/vnc_auto.html The public IP of the machine with the OpenStack installation is 192.168.100.142. I've tried to access via browser the address http://192.168.100.142:6080/vnc_auto.html from another machine, but I got nothing. I can ping and ssh my instances from the OpenStack machine but can't use VNC tab at dashboard page from another machine. The details and other pages from dashboard are fine. Should I associate a public address for my instances? I'm using just the private address at them (10.0.0.2, 10.0.0.3, ...). I've restarted all the services and created new instances after changing the nova.conf, but nothing has changed. The error is a 404 not found. (*Error: *Unable to get VNC console for instance 7376e17b-e329-4b8b-b5fc-076e8a80c058.) The log from dashboards page looks like this: - Page Not Found (404) - Requested method: GET - Requested URL: *http://192.168.100.142/nova/instances_and_volumes/instances/7376e17b-e329-4b8b-b5fc-076e8a80c058/None* This is the nova-api.log relative to the VNC atempt: http://pastebin.com/wSuyctrg Thanks for your time. Guilherme Birk. Date: Thu, 29 Mar 2012 13:06:37 -0700 Subject: Re: [Openstack] Dashboard VNC Console failed to connect to server From: sleepsonthefl...@gmail.com To: guib...@hotmail.com CC: openstack@lists.launchpad.net How are you generating this link: http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None ? It looks like if horizon is behaving nicely the link would look like http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/vnc http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Also, could you pastie your nova-api.log somewhere? A On Thu, Mar 29, 2012 at 11:52 AM, Guilherme Birk guib...@hotmail.com mailto:guib...@hotmail.com wrote: I'm having problems with it too. I'm trying to connect on my instances in the VNC tab at the dashboard, but I'm getting a 404 not found in the URL http://192.168.100.142/nova/instances_and_volumes/instances/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/None Here is my nova-api.log. Looks like nova is having problems with the POST at http://localhost:8774/v1.1/db742491018d467690ba7d3a7bb383a5/servers/5307a5c5-249b-4eda-b6e4-5b17d349e8ee/action. Any suggestions ? From: luciantho...@hotmail.com mailto:luciantho...@hotmail.com To: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Date: Thu, 29 Mar 2012 18:07:59 + Subject: [Openstack] Dashboard VNC Console failed to connect to server Hey guys, I'm using Dashboard with a nova-compute installed in another machine, but when I try access VNC Console I get the error failed to connect to server. Here is the log - http://pastebin.com/5DZMfiNE Anyone already saw this trouble? *Lucian Thomaz * ___ Mailing list: https
Re: [Openstack] Dashboard VNC Console failed to connect to server
Thank you. I installed the package. Now I've got this error when I paste the vnc url (which I got with nova get-vnc-console) in firefox: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/eventlet/wsgi.py, line 347, in handle_one_response for data in result: TypeError: 'NoneType' object is not iterable and the nova-xvpvncproxy.log looks like this: 2012-03-30 18:06:48 AUDIT nova.vnc.xvp_proxy [-] Request: GET /console?token=e77c1d12-c375-4b42-a165-f3d937bf2c41 HTTP/1.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3 Connection: keep-alive Content-Type: text/plain Cookie: csrftoken=4a9047c0e8eccd8a86da788412550c46; sessionid=fad912a6dbe83526e861546b3cf7ee68 Host: 172.22.22.1:6081 User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 2012-03-30 18:06:48 DEBUG nova.rpc.amqp [req-22f145a1-7834-4483-a1bf-f94ae9e53c1d None None] Making asynchronous call on consoleauth ... from (pid=16674) multicall /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:321 2012-03-30 18:06:48 DEBUG nova.rpc.amqp [req-22f145a1-7834-4483-a1bf-f94ae9e53c1d None None] MSG_ID is c90d93874b33438ca4e8ffca54ee48d8 from (pid=16674) multicall /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:324 2012-03-30 18:06:48 DEBUG nova.rpc.amqp [req-22f145a1-7834-4483-a1bf-f94ae9e53c1d None None] Pool creating new connection from (pid=16674) create /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:59 2012-03-30 18:06:48 INFO nova.rpc.common [req-22f145a1-7834-4483-a1bf-f94ae9e53c1d None None] Connected to AMQP server on 172.22.22.1:5672 2012-03-30 18:06:48 AUDIT nova.vnc.xvp_proxy [req-22f145a1-7834-4483-a1bf-f94ae9e53c1d None None] Unexpected error: [Errno 111] ECONNREFUSED any help appreciated, thank you Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 30/03/12 17:51, Guilherme Birk a écrit : Michael, try to install nova-consoleauth, like Anthony said. The old error was fixed when I installed it, now I'm having another issue, but now I think it's related to my network. Date: Fri, 30 Mar 2012 16:36:14 +0200 From: michael.vandebo...@cetic.be To: openstack@lists.launchpad.net Subject: Re: [Openstack] Dashboard VNC Console failed to connect to server I've got the same problem. When I try to connect to the instance using VNC through the dashboard, I've got this error. I then went in /var/log/nova/nova-xvpvncproxy.log and it contains nothing related to any attempt to get connected to any instance. It seems this nova-xvpvncproxy process doesn't notice anything. When I try to connect using VNC through virt-manager, it works. Le 30/03/12 15:50, Guilherme Birk a écrit : Thanks for the reply. I've added the flags that you mentioned on my nova.conf file. I'm using a all in one installation, the flags are configured this way. --vncserver_listen=127.0.0.1 --vncserver_proxyclient_address=127.0.0.1 --novncproxy_base_url=http://192.168.100.142:6080/vnc_auto.html The public IP of the machine with the OpenStack installation is 192.168.100.142. I've tried to access via browser the address http://192.168.100.142:6080/vnc_auto.html from another machine, but I got nothing. I can ping and ssh my instances from the OpenStack machine but can't use VNC tab at dashboard page from another machine. The details and other pages from dashboard are fine. Should I associate a public address for my instances? I'm using just the private address at them (10.0.0.2, 10.0.0.3, ...). I've restarted all the services and created new instances after changing the nova.conf, but nothing has changed. The error is a 404 not found. (*Error: *Unable to get VNC console for instance 7376e17b-e329-4b8b-b5fc-076e8a80c058.) The log from dashboards page looks like this: - Page Not Found (404) - Requested method: GET - Requested URL: *http://192.168.100.142/nova/instances_and_volumes/instances/7376e17b-e329-4b8b-b5fc-076e8a80c058/None* This is the nova-api.log relative to the VNC atempt: http://pastebin.com/wSuyctrg Thanks for your time. Guilherme Birk. Date: Thu, 29 Mar 2012 13:06:37 -0700 Subject: Re: [Openstack] Dashboard VNC Console failed to connect to server From: sleepsonthefl...@gmail.com mailto:sleepsonthefl...@gmail.com To: guib...@hotmail.com mailto:guib...@hotmail.com CC: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net How are you generating this link: http://192.168.100.142/nova/instances_and_volumes
Re: [Openstack] boot from ISO
Does the ISO you prepared contain the XenServer tools? I wonder whether ejecting the CD from your kickstart tool would do the job. -- no. The ISO is just a netinstall.iso from fedora 16 that I bundled myself, and which includes a kickstart file. I'll see if kickstart can manage to eject the CD. Thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 30/03/12 18:27, Armando Migliaccio a écrit : On Thu, Mar 29, 2012 at 3:30 PM, Michaël Van de Borne michael.vandebo...@cetic.be mailto:michael.vandebo...@cetic.be wrote: Hi Donal, Still about this good old 'Boot From ISO' feature inside the XenAPI: I packaged a custom netinstall.iso image which boots and installs the OS with kickstart. So that everything is custom and in 5minutes, I've got a complete running brand new machine freshly installed that has booted from the CDROM. But then at the end of install process, I ask kickstart to reboot the machine so that I can enjoy the new install. But the ISO image remains attached and the VM reboots again on the ISO. So, my question: Is it possible to automatically (using the API) empty CD drive every time a VM that's been booted from ISO reboots? If not, is it possible to change boot order when rebooting? To the best of my knowledge OSAPI does not have a 'eject-media-from-mv' call. Does the ISO you prepared contain the XenServer tools? I wonder whether ejecting the CD from your kickstart tool would do the job. thanks Le 02/12/11 11:44, Donal Lafferty a écrit : The background is that having provided a sample implementation, developers targeting libvirt would offer the same functionality. DL *From:*Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] *Sent:* 01 December 2011 16:34 *To:* Anne Gentle *Cc:* Donal Lafferty; openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO That's right, it's a Xen*Server* only feature. I insist on XenServer because it's been implemented only inside the xenapi. If you wish to manage VMs using KVM or Xen hypervisor (the community hypervisor packaged in Linux distributions), this will utilize the libvirt API, and not XenAPI. So, one needs to use XenServer (btw, openstack works great with XenServer 6.0 even if documentation claims that the supported release is 5.5 http://docs.openstack.org/diablo/openstack-compute/admin/content/hypervisors.html) in order for the XenAPI to be used. I made use of this documentation http://wiki.openstack.org/XenServerDevelopment in order to set up the environement. What is missing is that, in order to activate the Boot From ISO http://wiki.openstack.org/bootFromISO feature, the SR elements on XenServer host must be configured that way: 1. create an ISO-typed SR, such as an NFS ISO library, for instance. For this, using XenCenter is pretty easy. You need to export an NFS volume from a remote NFS server. Make sure it is exported in RW mode. 2. on the host, find the uuid of this ISO SR: # xe host-list write the uuid down 3. # xe sr-list content-type=iso locate the uuid of the NFS ISO library 4. # xe sr-param-set uuid=iso sr uuid other-config:i18n-key=local-storage-iso Even if an NFS mount point isn't local storage, you must specify local-storage-iso. 5. # xe pbd-list sr-uuid=iso sr uuid make sure the host-uuid from xe pbd-list equals the uuid of the host you found at step 2 then apply the rest of the tutorial http://wiki.openstack.org/XenServerDevelopment#Configure_SR_storage and publish an ISO image this way: glance add name=fedora_iso disk_format=iso container_format=bare Fedora-16-x86_64-netinst.iso nova boot test_iso --flavor flavor ID --image image ID I've posted this in the bug you filed, Anne. By the way, I'm going to work on porting this feature on libvirt API and VMWare API (if nobody works on it yet). Is the config drive yet available for Diablo?? cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone:+32 (0)71 49 07 45 tel:%2B32%20%280%2971%2049%2007%2045 Mobile:+32 (0)472 69 57 16 tel:%2B32%20%280%29472%2069%2057%2016, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 01/12/11 16:29, Anne Gentle a écrit : Thanks for the info! I've logged bug 898682 [1] to ensure it gets added to the documentation. Based on this note, is this a solution for Xen only? Is this the same as using a config drive? I had heard a config drive works on KVM but not Xen. If someone who's familiar with this area could work on the docs
Re: [Openstack] wrong IP given by flat network dhcp
Well, I changed /etc/network/interfaces accordingly (see below) and
didn't make any change in nova.conf, but the problem still remains. New
VM are given IPs from 10.18.9.2 (and not 10.18.9.33). What else can I check?
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 172.22.22.1
gateway 172.22.0.1
netmask 255.255.0.0
network 172.22.0.0
broadcast 172.22.255.255
auto eth1
iface eth1 inet static
address 10.18.9.1
netmask 255.255.255.224
network 10.18.9.0
broadcast 10.18.9.31
Here's the output of ifconfig:
localadmin@openstack1:~$ ifconfig
br100 Link encap:Ethernet HWaddr 5c:f3:fc:1d:4a:42
inet addr:10.18.9.1 Bcast:10.18.9.31 Mask:255.255.255.224
inet6 addr: fe80::bc06:73ff:fe85:2081/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:189404 errors:0 dropped:1001 overruns:0 frame:0
TX packets:6063 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12010565 (12.0 MB) TX bytes:1100566 (1.1 MB)
eth0 Link encap:Ethernet HWaddr 5c:f3:fc:1d:4a:40
inet addr:172.22.22.1 Bcast:172.22.255.255 Mask:255.255.0.0
inet6 addr: fe80::5ef3:fcff:fe1d:4a40/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:473034 errors:0 dropped:1133 overruns:0 frame:0
TX packets:168957 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:321962311 (321.9 MB) TX bytes:14763893 (14.7 MB)
Interrupt:30 Memory:fa00-fa012800
eth1 Link encap:Ethernet HWaddr 5c:f3:fc:1d:4a:42
inet6 addr: fe80::5ef3:fcff:fe1d:4a42/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:890 errors:0 dropped:132 overruns:0 frame:0
TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69871 (69.8 KB) TX bytes:1980 (1.9 KB)
Interrupt:37 Memory:9200-92012800
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:572149 errors:0 dropped:0 overruns:0 frame:0
TX packets:572149 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:817303115 (817.3 MB) TX bytes:817303115 (817.3 MB)
virbr0Link encap:Ethernet HWaddr 8a:ae:91:b4:11:6b
inet addr:192.168.122.1 Bcast:192.168.122.255
Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
vnet0 Link encap:Ethernet HWaddr fe:16:3e:63:b4:35
inet6 addr: fe80::fc16:3eff:fe63:b435/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:150 errors:0 dropped:0 overruns:0 frame:0
TX packets:792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:15341 (15.3 KB) TX bytes:61254 (61.2 KB)
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
Le 28/03/12 18:50, Vishvananda Ishaya a écrit :
You have to create your network with the same range
it looks like you created with something like 10.18.9.0/24
On Mar 28, 2012, at 8:33 AM, Michaël Van de Borne wrote:
Hello,
I installed Essex on Ubuntu 12.04 Server, and I had a problem with VM IP.
The IP given to the VM (10.18.9.2) isn't in the fixed_range. Here's a portion
of nova.conf:
# cat /etc/nova/nova.conf
[...]
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0
--flat_interface=eth1
--flat_network_bridge=br100
--fixed_range=10.18.9.32/27
--floating_range=172.22.22.32/27
--network_size=32
--flat_network_dhcp_start=10.18.9.33
and here's the host network config:
# cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 172.22.22.1
gateway 172.22.0.1
netmask 255.255.0.0
network 172.22.0.0
broadcast 172.22.255.255
auto eth1
iface eth1 inet static
address 10.18.9.1
netmask 255.255.0.0
network 10.18.0.0
broadcast 10.18.255.255
Then I deployed another VM, and I was given IP 10.18.9.3. Here's an excerpt of
/var/log/nova/nova-network.log when I deployed this machine:
2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'admin'], u'_context_request_id':
u'req-aa77b53c-be43
Re: [Openstack] boot from ISO
Hi Donal, Still about this good old 'Boot From ISO' feature inside the XenAPI: I packaged a custom netinstall.iso image which boots and installs the OS with kickstart. So that everything is custom and in 5minutes, I've got a complete running brand new machine freshly installed that has booted from the CDROM. But then at the end of install process, I ask kickstart to reboot the machine so that I can enjoy the new install. But the ISO image remains attached and the VM reboots again on the ISO. So, my question: Is it possible to automatically (using the API) empty CD drive every time a VM that's been booted from ISO reboots? If not, is it possible to change boot order when rebooting? thanks Le 02/12/11 11:44, Donal Lafferty a écrit : The background is that having provided a sample implementation, developers targeting libvirt would offer the same functionality. DL *From:*Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] *Sent:* 01 December 2011 16:34 *To:* Anne Gentle *Cc:* Donal Lafferty; openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO That's right, it's a Xen*Server* only feature. I insist on XenServer because it's been implemented only inside the xenapi. If you wish to manage VMs using KVM or Xen hypervisor (the community hypervisor packaged in Linux distributions), this will utilize the libvirt API, and not XenAPI. So, one needs to use XenServer (btw, openstack works great with XenServer 6.0 even if documentation claims that the supported release is 5.5 http://docs.openstack.org/diablo/openstack-compute/admin/content/hypervisors.html) in order for the XenAPI to be used. I made use of this documentation http://wiki.openstack.org/XenServerDevelopment in order to set up the environement. What is missing is that, in order to activate the Boot From ISO http://wiki.openstack.org/bootFromISO feature, the SR elements on XenServer host must be configured that way: 1. create an ISO-typed SR, such as an NFS ISO library, for instance. For this, using XenCenter is pretty easy. You need to export an NFS volume from a remote NFS server. Make sure it is exported in RW mode. 2. on the host, find the uuid of this ISO SR: # xe host-list write the uuid down 3. # xe sr-list content-type=iso locate the uuid of the NFS ISO library 4. # xe sr-param-set uuid=iso sr uuid other-config:i18n-key=local-storage-iso Even if an NFS mount point isn't local storage, you must specify local-storage-iso. 5. # xe pbd-list sr-uuid=iso sr uuid make sure the host-uuid from xe pbd-list equals the uuid of the host you found at step 2 then apply the rest of the tutorial http://wiki.openstack.org/XenServerDevelopment#Configure_SR_storage and publish an ISO image this way: glance add name=fedora_iso disk_format=iso container_format=bare Fedora-16-x86_64-netinst.iso nova boot test_iso --flavor flavor ID --image image ID I've posted this in the bug you filed, Anne. By the way, I'm going to work on porting this feature on libvirt API and VMWare API (if nobody works on it yet). Is the config drive yet available for Diablo?? cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 01/12/11 16:29, Anne Gentle a écrit : Thanks for the info! I've logged bug 898682 [1] to ensure it gets added to the documentation. Based on this note, is this a solution for Xen only? Is this the same as using a config drive? I had heard a config drive works on KVM but not Xen. If someone who's familiar with this area could work on the docs that would be great. Thanks, Anne [1]https://bugs.launchpad.net/openstack-manuals/+bug/898682 On Thu, Dec 1, 2011 at 9:14 AM, Michaël Van de Borne michael.vandebo...@cetic.be mailto:michael.vandebo...@cetic.be wrote: It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I'd look to see if the compute node can see that ISO SR. DL From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] Sent: 29 November 2011 18:15
[Openstack] wrong IP given by flat network dhcp
Hello,
I installed Essex on Ubuntu 12.04 Server, and I had a problem with VM IP.
The IP given to the VM (10.18.9.2) isn't in the fixed_range. Here's a
portion of nova.conf:
# cat /etc/nova/nova.conf
[...]
--network_manager=nova.network.manager.FlatDHCPManager
--public_interface=eth0
--flat_interface=eth1
--flat_network_bridge=br100
--fixed_range=10.18.9.32/27
--floating_range=172.22.22.32/27
--network_size=32
--flat_network_dhcp_start=10.18.9.33
and here's the host network config:
# cat /etc/network/interfaces
auto eth0
iface eth0 inet static
address 172.22.22.1
gateway 172.22.0.1
netmask 255.255.0.0
network 172.22.0.0
broadcast 172.22.255.255
auto eth1
iface eth1 inet static
address 10.18.9.1
netmask 255.255.0.0
network 10.18.0.0
broadcast 10.18.255.255
Then I deployed another VM, and I was given IP 10.18.9.3. Here's an
excerpt of /var/log/nova/nova-network.log when I deployed this machine:
2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'admin'], u'_context_request_id':
u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', u'_context_read_deleted':
u'no', u'args': {u'address': u'10.18.9.3'}, u'_context_auth_token':
None, u'_context_is_admin': True, u'_context_project_id': None,
u'_context_timestamp': u'2012-03-28T15:29:16.569136',
u'_context_user_id': None, u'method': u'lease_fixed_ip',
u'_context_remote_address': None} from (pid=17249) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
2012-03-28 17:29:16 DEBUG nova.rpc.amqp
[req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] unpacked context:
{'request_id': u'req-aa77b53c-be43-4b4e-bf82-98f62bff7f52', 'user_id':
None, 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.569136',
'is_admin': True, 'auth_token': None, 'project_id': None,
'remote_address': None, 'read_deleted': u'no'} from (pid=17249)
unpack_context /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
2012-03-28 17:29:16 DEBUG nova.network.manager
[req-aa77b53c-be43-4b4e-bf82-98f62bff7f52 None None] Leased IP
|10.18.9.3| from (pid=17249) lease_fixed_ip
/usr/lib/python2.7/dist-packages/nova/network/manager.py:1222
2012-03-28 17:29:16 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'admin'], u'_msg_id': u'ba410b9f98c04023b68f6ea6e95d775e',
u'_context_read_deleted': u'no', u'_context_request_id':
u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', u'args': {u'address':
u'10.18.9.3'}, u'_context_auth_token': None, u'_context_is_admin': True,
u'_context_project_id': None, u'_context_timestamp':
u'2012-03-28T15:29:16.820602', u'_context_user_id': None, u'method':
u'get_fixed_ip_by_address', u'_context_remote_address': None} from
(pid=17249) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
2012-03-28 17:29:16 DEBUG nova.rpc.amqp
[req-11a728d5-d7f5-4c65-a2ce-6d958585e574 None None] unpacked context:
{'request_id': u'req-11a728d5-d7f5-4c65-a2ce-6d958585e574', 'user_id':
None, 'roles': [u'admin'], 'timestamp': '2012-03-28T15:29:16.820602',
'is_admin': True, 'auth_token': None, 'project_id': None,
'remote_address': None, 'read_deleted': u'no'} from (pid=17249)
unpack_context /usr/lib/python2.7/dist-packages/nova/rpc/amqp.py:188
2012-03-28 17:29:40 DEBUG nova.rpc.amqp [-] received {u'_context_roles':
[u'admin'], u'_msg_id': u'50999ff995cd4f7e8e441885d3ada543',
u'_context_read_deleted': u'no', u'_context_request_id':
u'req-563547e8-6f6f-43b1-9449-681ff43dad33', u'args': {u'instance_id':
3, u'instance_uuid': u'b7ec8623-e002-4682-a37b-50e1d047c134', u'host':
u'openstack1', u'project_id': u'0a9e24ccc1ac46eea75154c85bb4052e',
u'rxtx_factor': 1.0}, u'_context_auth_token': None,
u'_context_is_admin': True, u'_context_project_id': None,
u'_context_timestamp': u'2012-03-28T15:29:31.151885',
u'_context_user_id': None, u'method': u'get_instance_nw_info',
u'_context_remote_address': None} from (pid=17249) _safe_log
/usr/lib/python2.7/dist-packages/nova/rpc/common.py:144
what am I doing wrong?
--
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Swift: NAS or DAS?
Hi all, on the very useful www.referencearchitecture.org website, and in every piece of documentation on Swift, I never found anything like a NAS attached to a storage node. It was all about DAS solution. Is there a specific reason why a NAS wouldn't be a good choice to build a swift infrastructure? thank you -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] understanding ephemeral and persistant volumes
is it too complicated or too simple to be answered on the ML? Le 23/02/12 16:46, Michaël Van de Borne a écrit : Hi all, I'd like to understand how things go with ephemeral and persistant volumes. For instance, say that my gold images are stored in a Swift storage network, connected to Glance. When I ask Nova to boot the VM, - will the disk image stay in Swift storage? - will the physical compute node copy the image from Swift to its local filesystem? - will ephemeral volumes be stored on local compute node filesystem whereas persistant drives be stored in Swift? According to these answers, I'll know if the compute nodes of my cloud should have disks attached or if no data will ever be stored on these nodes even when VMs are running. maybe this is documented somewhere, but I didn't find clear information about ephemeral and persistant volume management? thank you, Michaël ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] understanding ephemeral and persistant volumes
Hi all, I'd like to understand how things go with ephemeral and persistant volumes. For instance, say that my gold images are stored in a Swift storage network, connected to Glance. When I ask Nova to boot the VM, - will the disk image stay in Swift storage? - will the physical compute node copy the image from Swift to its local filesystem? - will ephemeral volumes be stored on local compute node filesystem whereas persistant drives be stored in Swift? According to these answers, I'll know if the compute nodes of my cloud should have disks attached or if no data will ever be stored on these nodes even when VMs are running. maybe this is documented somewhere, but I didn't find clear information about ephemeral and persistant volume management? thank you, Michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I'd look to see if the compute node can see that ISO SR. DL *From:*Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] *Sent:* 29 November 2011 18:15 *To:* Donal Lafferty; openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using nova list but not using glance index. The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit : Hi Michaël, Boot from ISO should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows' images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution. However, I wrote it for XenAPI, so we need someone to duplicate the work for KVM and VMWare. DL *From:*openstack-bounces+donal.lafferty=citrix@lists.launchpad.net mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net [mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net] *On Behalf Of *Michaël Van de Borne *Sent:* 21 November 2011 17:28 *To:* openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net *Subject:* Re: [Openstack] boot from ISO up? anybody? Le 14/11/11 14:44, Michaël Van de Borne a écrit : Hi all, I'm very interested in the Boot From ISO feature described here: http://wiki.openstack.org/bootFromISO In a few words, it's about the ability to boot a VM from the CDROM with an ISO image attached. A blank hard disk being attached to install the OS files in it. I've got some questions about this: 1. Is the feature available today using a standard Diablo install? I've seen the code about this feature is stored under nova/tests and glance/tests. Does this mean it isn't finished yet and could only be tested under specific conditions? Which ones? 2. the spec tells about a Windows use case. Why just Windows? What should I do to test with a Linux distribution? 3. I can see here http://bazaar.launchpad.net/%7Ehudson-openstack/nova/trunk/revision/1433?start_revid=1433 that the Xen hypervisor only has been impacted by the source code changes. Are KVM and VMWare planned to be supported in the future? May I help/be helped to develop KVM and VMWare support for this 'Boot From Iso' feature? Any help appreaciated thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list:https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack Post to :openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net Unsubscribe :https://launchpad.net/~openstack https://launchpad.net/%7Eopenstack More help :https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
That's right, it's a Xen*Server* only feature. I insist on XenServer because it's been implemented only inside the xenapi. If you wish to manage VMs using KVM or Xen hypervisor (the community hypervisor packaged in Linux distributions), this will utilize the libvirt API, and not XenAPI. So, one needs to use XenServer (btw, openstack works great with XenServer 6.0 even if documentation claims that the supported release is 5.5 http://docs.openstack.org/diablo/openstack-compute/admin/content/hypervisors.html) in order for the XenAPI to be used. I made use of this documentation http://wiki.openstack.org/XenServerDevelopment in order to set up the environement. What is missing is that, in order to activate the Boot From ISO http://wiki.openstack.org/bootFromISO feature, the SR elements on XenServer host must be configured that way: 1. create an ISO-typed SR, such as an NFS ISO library, for instance. For this, using XenCenter is pretty easy. You need to export an NFS volume from a remote NFS server. Make sure it is exported in RW mode. 2. on the host, find the uuid of this ISO SR: # xe host-list write the uuid down 3. # xe sr-list content-type=iso locate the uuid of the NFS ISO library 4. # xe sr-param-set uuid=iso sr uuid other-config:i18n-key=local-storage-iso Even if an NFS mount point isn't local storage, you must specify local-storage-iso. 5. # xe pbd-list sr-uuid=iso sr uuid make sure the host-uuid from xe pbd-list equals the uuid of the host you found at step 2 then apply the rest of the tutorial http://wiki.openstack.org/XenServerDevelopment#Configure_SR_storage and publish an ISO image this way: glance add name=fedora_iso disk_format=iso container_format=bare Fedora-16-x86_64-netinst.iso nova boot test_iso --flavor flavor ID --image image ID I've posted this in the bug you filed, Anne. By the way, I'm going to work on porting this feature on libvirt API and VMWare API (if nobody works on it yet). Is the config drive yet available for Diablo?? cheers, michaël http://wiki.openstack.org/XenServerDevelopment Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 01/12/11 16:29, Anne Gentle a écrit : Thanks for the info! I've logged bug 898682 [1] to ensure it gets added to the documentation. Based on this note, is this a solution for Xen only? Is this the same as using a config drive? I had heard a config drive works on KVM but not Xen. If someone who's familiar with this area could work on the docs that would be great. Thanks, Anne [1] https://bugs.launchpad.net/openstack-manuals/+bug/898682 On Thu, Dec 1, 2011 at 9:14 AM, Michaël Van de Borne michael.vandebo...@cetic.be wrote: It finally works. The problem was the flag checks while looking for the ISO SR. inside the find_iso_sr method (in nova/virt/xenapi/vm_utils.py), I found that the ISO SR must have these settings: content type: iso other-config:i18n-key=local-storage-iso As far as I know, this wasn't documented anywhere. Hope this can be useful for people from the future. cheers, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 29/11/11 23:10, Donal Lafferty a écrit : Off the top of my head, I’d look to see if the compute node can see that ISO SR. DL From: Michaël Van de Borne [mailto:michael.vandebo...@cetic.be] Sent: 29 November 2011 18:15 To: Donal Lafferty; openstack@lists.launchpad.net Subject: Re: [Openstack] boot from ISO Hi Donal, hi all, I'm trying to test the Boot From ISO feature. So I've set a XenServer host and installed a Ubuntu 11.10 PV DomU in it. Then I used the following commands but, as you can see in the attached nova-compute log excerpt, there was a problem. glance add name=fedora_iso disk_format=iso ../Fedora-16-x86_64-Live-LXDE.iso ID: 4 nova boot test_iso --flavor 2 --image 4 I can see the ISO images using nova list but not using glance index. The error seems to be: 'Cannot find SR of content-type ISO'. However, I've set a NFS ISO Library using XenCenter, so that there is an actual ISO content-typed SR. How to tell OpenStack to use this SR for the ISO images I post using glance? Any clue? I feel I'm rather close to make it work. thanks, michaël Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi Le 22/11/11 00:18, Donal Lafferty a écrit : Hi Michaël, “Boot from ISO” should be ISO image agnostic. The feature overcomes restrictions placed on the distribution of modified Windows’ images. People can use their ISO instead, but they may still need to use dedicated hardware. You should have no problem with a Linux distribution
Re: [Openstack] boot from ISO
Hi Donal, hi all,
I'm trying to test the Boot From ISO feature. So I've set a XenServer
host and installed a Ubuntu 11.10 PV DomU in it.
Then I used the following commands but, as you can see in the attached
nova-compute log excerpt, there was a problem.
glance add name=fedora_iso disk_format=iso
../Fedora-16-x86_64-Live-LXDE.iso
ID: 4
nova boot test_iso --flavor 2 --image 4
I can see the ISO images using nova list but not using glance index.
The error seems to be: 'Cannot find SR of content-type ISO'. However,
I've set a NFS ISO Library using XenCenter, so that there is an actual
ISO content-typed SR. How to tell OpenStack to use this SR for the ISO
images I post using glance?
Any clue? I feel I'm rather close to make it work.
thanks,
michaël
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi
Le 22/11/11 00:18, Donal Lafferty a écrit :
Hi Michaël,
Boot from ISO should be ISO image agnostic. The feature overcomes
restrictions placed on the distribution of modified Windows' images.
People can use their ISO instead, but they may still need to use
dedicated hardware.
You should have no problem with a Linux distribution.
However, I wrote it for XenAPI, so we need someone to duplicate the
work for KVM and VMWare.
DL
*From:*openstack-bounces+donal.lafferty=citrix@lists.launchpad.net
[mailto:openstack-bounces+donal.lafferty=citrix@lists.launchpad.net]
*On Behalf Of *Michaël Van de Borne
*Sent:* 21 November 2011 17:28
*To:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] boot from ISO
up? anybody?
Le 14/11/11 14:44, Michaël Van de Borne a écrit :
Hi all,
I'm very interested in the Boot From ISO feature described here:
http://wiki.openstack.org/bootFromISO
In a few words, it's about the ability to boot a VM from the CDROM
with an ISO image attached. A blank hard disk being attached to
install the OS files in it.
I've got some questions about this:
1. Is the feature available today using a standard Diablo install?
I've seen the code about this feature is stored under nova/tests and
glance/tests. Does this mean it isn't finished yet and could only be
tested under specific conditions? Which ones?
2. the spec tells about a Windows use case. Why just Windows? What
should I do to test with a Linux distribution?
3. I can see here
http://bazaar.launchpad.net/%7Ehudson-openstack/nova/trunk/revision/1433?start_revid=1433
that the Xen hypervisor only has been impacted by the source code
changes. Are KVM and VMWare planned to be supported in the future? May
I help/be helped to develop KVM and VMWare support for this 'Boot From
Iso' feature?
Any help appreaciated
thank you,
michaël
--
Michaël Van de Borne
RD Engineer, SOA team, CETIC
Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli
www.cetic.be http://www.cetic.be, rue des Frères Wright, 29/3, B-6041
Charleroi
___
Mailing list:https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
Post to :openstack@lists.launchpad.net
mailto:openstack@lists.launchpad.net
Unsubscribe :https://launchpad.net/~openstack
https://launchpad.net/%7Eopenstack
More help :https://help.launchpad.net/ListHelp
2011-11-29 18:11:41,970 DEBUG nova.rpc [-] received {u'_context_roles': [], u'_context_request_id': u'180d772e-f33d-4d9d-b1bc-e8cf2235cf1d', u'_context_read_deleted': False, u'args': {u'request_spec': {u'num_instances': 1, u'image': {u'status': u'active', u'name': u'fedora_iso', u'deleted': False, u'container_format': u'ovf', u'created_at': u'2011-11-29 17:10:27.140409', u'disk_format': u'iso', u'updated_at': u'2011-11-29 17:10:47.737498', u'properties': {u'min_disk': u'0', u'owner': None, u'min_ram': u'0'}, u'location': u'file:///var/lib/glance/images/4', u'checksum': u'20c39452cac6b1e6966f6b7edc704236', u'is_public': False, u'deleted_at': None, u'id': 4, u'size': 567279616}, u'filter': None, u'instance_type': {u'rxtx_quota': 0, u'flavorid': 2, u'name': u'm1.small', u'deleted': False, u'created_at': None, u'updated_at': None, u'memory_mb': 2048, u'vcpus': 1, u'rxtx_cap': 0, u'extra_specs': {}, u'swap': 0, u'deleted_at': None, u'id': 5, u'local_gb': 20}, u'blob': None, u'instance_properties': {u'vm_state': u'building', u'availability_zone': None, u'ramdisk_id': u'', u'instance_type_id': 5, u'user_data': u'', u'vm_mode': None, u'reservation_id': u'r-40470cnx', u'user_id': u'mb', u'display_description': u'test_iso', u'key_data': None, u'power_state': 0, u'project_id': u'openstack', u'metadata': {}, u'access_ip_v6': None, u'access_ip_v4': None, u'kernel_id': u'', u'key_name': None, u'display_name': u'test_iso', u'config_drive_id': u'', u'local_gb': 20, u'architecture': None, u'locked': False, u'launch_time': u'2011-11-29T17:11:41Z', u'memory_mb': 2048, u'vcpus': 1, u'image_ref': 4
[Openstack] Xen and openstack
Hi all, On this page http://docs.openstack.org/diablo/openstack-compute/admin/content/selecting-a-hypervisor.html, one can see that XenServer 5.6 and XCP are supported. Is there any chance to run xen VMs using just the 'xen hypervisor' package from linux distributions? This means: bare metal - Fedora 16 - nova-compute - VM is the page: http://wiki.openstack.org/XenServerDevelopment still valid for this configuration? If yes, I get an error when testing the connection: sudo nova-manage shell python import XenAPI import nova.virt.xenapi_conn nova.virt.xenapi_conn.XenAPI = XenAPI x = nova.virt.xenapi_conn.XenAPIConnection(http://localhost;, , ) Traceback (most recent call last): File console, line 1, in module File /usr/lib/python2.7/site-packages/nova/virt/xenapi_conn.py, line 162, in __init__ self._session = XenAPISession(url, user, pw) File /usr/lib/python2.7/site-packages/nova/virt/xenapi_conn.py, line 362, in __init__ self._session.login_with_password(user, pw) File /usr/lib/python2.7/site-packages/XenAPI.py, line 182, in lambda return lambda *params: self._login(name, params) File /usr/lib/python2.7/site-packages/XenAPI.py, line 148, in _login result = _parse_result(getattr(self, 'session.%s' % method)(*params)) File /usr/lib64/python2.7/xmlrpclib.py, line 1224, in __call__ return self.__send(self.__name, args) File /usr/lib64/python2.7/xmlrpclib.py, line 1575, in __request verbose=self.__verbose File /usr/lib64/python2.7/xmlrpclib.py, line 1264, in request return self.single_request(host, handler, request_body, verbose) File /usr/lib64/python2.7/xmlrpclib.py, line 1292, in single_request self.send_content(h, request_body) File /usr/lib64/python2.7/xmlrpclib.py, line 1439, in send_content connection.endheaders(request_body) File /usr/lib64/python2.7/httplib.py, line 951, in endheaders self._send_output(message_body) File /usr/lib64/python2.7/httplib.py, line 811, in _send_output self.send(msg) File /usr/lib64/python2.7/httplib.py, line 773, in send self.connect() File /usr/lib64/python2.7/httplib.py, line 754, in connect self.timeout, self.source_address) File /usr/lib/python2.7/site-packages/eventlet/green/socket.py, line 59, in create_connection raise error, msg error: [Errno 111] ECONNREFUSED thank you michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] boot from ISO
up? anybody? Le 14/11/11 14:44, Michaël Van de Borne a écrit : Hi all, I'm very interested in the Boot From ISO feature described here: http://wiki.openstack.org/bootFromISO In a few words, it's about the ability to boot a VM from the CDROM with an ISO image attached. A blank hard disk being attached to install the OS files in it. I've got some questions about this: 1. Is the feature available today using a standard Diablo install? I've seen the code about this feature is stored under nova/tests and glance/tests. Does this mean it isn't finished yet and could only be tested under specific conditions? Which ones? 2. the spec tells about a Windows use case. Why just Windows? What should I do to test with a Linux distribution? 3. I can see here http://bazaar.launchpad.net/%7Ehudson-openstack/nova/trunk/revision/1433?start_revid=1433 that the Xen hypervisor only has been impacted by the source code changes. Are KVM and VMWare planned to be supported in the future? May I help/be helped to develop KVM and VMWare support for this 'Boot From Iso' feature? Any help appreaciated thank you, michaël -- Michaël Van de Borne RD Engineer, SOA team, CETIC Phone: +32 (0)71 49 07 45 Mobile: +32 (0)472 69 57 16, Skype: mikemowgli www.cetic.be, rue des Frères Wright, 29/3, B-6041 Charleroi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
