Why is nova-compute showing XXX
Hello, I'm running Debian Wheezy and following the guide with a Neutron Per-tenant routers with private networks setup. I've tried to combine the network and management node into one controller.
When I run nova-manage service list
I see:
Binary Host Zone Status State Updated_At
nova-conductor controller internal enabled :-) 2013-11-14 14:55:51
nova-cert controller internal enabled :-) 2013-11-14 14:55:51
nova-consoleauth controller internal enabled :-) 2013-11-14 14:55:51
nova-scheduler controller internal enabled :-) 2013-11-14 14:55:51
nova-compute computenode00 nova enabled XXX 2013-11-14 06:25:14
nova-cert computenode00 internal enabled :-) 2013-11-14 14:55:52
I can get the following output from ssh root@controller date; ssh root@computenode00 date
:
Thu Nov 14 15:28:45 GMT 2013
Thu Nov 14 15:28:45 GMT 2013
So NTP seems to be working.
Config Files Controller /etc/nova.conf:
[DEFAULT]
my_ip = 10.0.0.182
sql_connection = mysql://nova-common:NovaMYSQLpass@localhost/novadb
enabled_apis = ec2,osapi_compute,metadata
log_file = nova.log
log_dir = /var/log/nova
verbose = true
state_path=/var/lib/nova
lock_path=/var/lock/nova
rootwrap_config=/etc/nova/rootwrap.conf
auth_strategy=keystone
rabbit_host = localhost
rabbit_userid = guest
rabbit_password = rabbitpass
rpc_backend = nova.openstack.common.rpc.impl_kombu
network_api_class=nova.network.neutronv2.api.API
security_group_api = neutron
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybirdOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.firewall.NoopFirewallDriver
libvirt_use_virtio_for_bridges=True
neutron_url=http://127.0.0.1:9696
neutron_auth_strategy=keystone
neutron_admin_tenant_name=admin
neutron_admin_username=admin
neutron_admin_password=adminKeystonePass
neutron_admin_auth_url=http://127.0.0.1:35357/v2.0
service_neutron_metadata_proxy=True
vnc_enabled=false
vncserver_listen=0.0.0.0
vnc_keymap="en-us"
[conductor]
[cells]
[baremetal]
[vmware]
[spice]
html5proxy_base_url=http://127.0.0.1:6082/spice_auto.html
server_listen=0.0.0.0
server_proxyclient_address=$my_ip
enabled=true
Nova configs fromt he compute note are as follows:
Compute node /etc/nova.conf
[DEFAULT]
my_ip = 10.0.0.11
sql_connection = mysql://nova-common:NovaMYSQLpass@10.0.0.182/novadb
enabled_apis = metadata
verbose=true
state_path=/var/lib/nova
lock_path=/var/lock/nova
rootwrap_config=/etc/nova/rootwrap.conf
auth_strategy=keystone
rabbit_host = 10.0.0.182
rabbit_userid = guest
rabbit_password = rabbitpass
rpc_backend = nova.openstack.common.rpc.impl_kombu
glance_host=10.0.0.182
glance_port=9292
glance_protocol=http
network_api_class=nova.network.neutronv2.api.API
security_group_api = neutron
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybirdOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.firewall.NoopFirewallDriver
libvirt_use_virtio_for_bridges=True
neutron_url=http://10.0.0.182:9696
neutron_auth_strategy=keystone
neutron_admin_tenant_name=admin
neutron_admin_username=admin
neutron_admin_password=adminKeystonePass
neutron_admin_auth_url=http://10.0.0.182:35357/v2.0
service_neutron_metadata_proxy=True
vnc_enabled=false
vncserver_listen=0.0.0.0
vnc_keymap="en-us"
[conductor]
[cells]
[baremetal]
[vmware]
[spice]
html5proxy_base_url=http://127.0.0.1:6082/spice_auto.html
server_listen=0.0.0.0
server_proxyclient_address=10.0.0.11
enabled=true
Compute node /etc/nova-compute.conf
[DEFAULT]
compute_driver=libvirt.LibvirtDriver
libvirt_type=kvm
libvirt_ovs_bridge=br-int
libvirt_vif_type=ethernet
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
libvirt_use_virtio_for_bridges=True
Log files I can't see anything odd when I restart the nova-compute service with debuging on:
2013-11-14 15:00:47.737 4583 DEBUG nova.servicegroup.api [-] ServiceGroup driver defined as an instance of db __new__ /usr/lib/python2.7/dist-packages/nova/servicegroup/api ...
So there are never any further messages in nova-compute.log after "Connected to AMQP server on 10.0.0.182:5672" ? Normally there would be resource_tracker stuff about once a minute at debug level.
Experiencing the same problem. Also debian compute node, ntp synched, nothing odd in the logs. It seems to fall apart around log rotation time, though not every day, so the natural assumption is a race condition, but restarting services doesn't bring it back. Did you ever solve this?