Hi, Yes, the page http://openstack.redhat.com/Workarounds#nova:_instances_started_in_error_state helped me. Even after installing icehouse from scratch I got instances started in error state. Only correcting /etc/nova/nova.conf to
vif_plugging_is_fatal: false vif_plugging_timeout: 0 helped me. > Hi, Anatoly, > Does that page help for you? > Well, I also had problem of launching VM after to Icehouse from Havana. > I am not sure if that is what you are suffering, but in my case, it's > because I forgot that there are new options needed to be configured in > neutron.conf for Icehouse, if we upgrade neutron from Havana to Icehouse > we will need to add them by hand, e.g.: > > [DEFAULT] > notify_nova_port_status_change=true > notify_nova_on_port_data_changes=true > nova_url=http://<nova api endpoint>:<port>/v2 > nova_admin_username=<nova admin user> > nova_admin_password=<nova admin password> > nova_admin_tenant_id=<nova admin uuid> > nova_admin_auth_url=http://<keystone endpoint>:<port>/v2.0 > > > This information is also in rdo page: > http://openstack.redhat.com/Upgrading_RDO_To_Icehouse > > > > Best regards, > Felix Lee ~ > > > > On 2014年06月11日 13:06, Anatoly Oreshkin wrote: >> Hi, Felix >> >> Thank you for reply. I've encountered the same problems as you. >> After much googling I've managed to modify database and to find out how to >> modify >> db_migration script. However after upgrading openstack instances have not >> launched >> successfully so I've decided to install IceHouse from scratch. >> This was easy for me because my openstack setup consists of 2 nodes. >> >> Later I've found the page >> http://openstack.redhat.com/Workarounds#nova:_instances_started_in_error >> which explains what to do in case when "instances started in error state" >> >> >>> Hi, Anatoly, >>> I am not sure if you solved this problem already, but I suffered the >>> similar problem as yours when I upgraded openstack from havana to >>> icehouse today. >>> >>> There were two problems I suffered, and both related to msyql table >>> character set. >>> >>> Simply check, if you run: keystone-manage db_version, and the version >>> stays at 37, you probably failed at db_sync as I did. >>> >>> >>> In my case, while I did keystone-manage db_sync, there was an error in >>> /var/log/keystone/keystone.log: >>> 2014-06-09 21:23:12.732 53481 CRITICAL keystone [-] ValueError: Tables >>> "region" have non utf8 collation, please make sure all tables are >>> CHARSET=utf8 >>> >>> >>> So, the workaround was to go to mysql and change the CHARSET to utf8 for >>> table: "region", for example, run following sql command in mysql: >>> >>> use keystone ; >>> alter table region CHARACTER SET utf8 COLLATE utf8_general_ci; >>> >>> >>> And, the second problem was actually a bug of db_migration script which >>> was already reported and fixed, but, unfortunately, it is not yet >>> available in rdo release, so, you will have to apply patch by hand, >>> please see detail: >>> >>> https://git.openstack.org/cgit/openstack/keystone/commit/?id=4408625031bc9804fa4bd4a72988bf31375b7787 >>> >>> >>> I hope this can be helpful, if you have not yet solved this problem. >>> >>> >>> Best regards, >>> Felix Lee ~ >>> >>> >>> On 2014撟�05��29�� 13:44, Anatoly Oreshkin wrote: >>>> >>>> >>>> Hello, >>>> >>>> I've upgraded Havana to IceHouse on Scientific Linux 6.5 following these >>>> steps: >>>> >>>> yum install >>>> http://rdo.fedorapeople.org/openstack-havana/rdo-release-havana.rpm >>>> >>>> yum -y update >>>> >>>> nova-manage db sync >>>> cinder-manage db sync >>>> glance-manage db_sync >>>> keystone-manage db_sync >>>> >>>> When I run command keystone tenenat-list >>>> I get >>>> uthorization Failed: An unexpected error prevented the server from >>>> fulfilling >>>> your >>>> request. (HTTP 500) >>>> >>>> /var/log/keystone shows >>>> >>>> 2014-05-29 15:42:58.782 10638 TRACE keystone.common.wsgi ProgrammingError: >>>> (ProgrammingError) (1146, "Table 'keystone.assignment' doesn't exist") >>>> 'SELECT >>>> assignment.type AS assignment_type, assignment.actor_id AS >>>> assignment_actor_id, >>>> assignment.target_id AS assignment_target_id, assignment.role_id AS >>>> assignment_role_id, assignment.inherited AS assignment_inherited \nFROM >>>> assignment >>>> \nWHERE assignment.actor_id = %s AND assignment.target_id = %s' >>>> ('9436d6868f314fae81166cedf1769bed', '71d30105c083454398c9617cd15a9e4d') >>>> 2014-05-29 15:42:58.782 10638 TRACE keystone.common.wsgi >>>> >>>> >>>> Can anybody help me ? >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>>> Post to : openstack@lists.openstack.org >>>> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >>>> >>> >>> >>> -- >>> Felix H.T Lee Academia Sinica Grid & Cloud. >>> Tel: +886-2-27898308 >>> Office: Room P111, Institute of Physics, 128 Academia Road, Section 2, >>> Nankang, Taipei 115, Taiwan >>> >> > > > -- > Felix H.T Lee Academia Sinica Grid & Cloud. > Tel: +886-2-27898308 > Office: Room P111, Institute of Physics, 128 Academia Road, Section 2, > Nankang, Taipei 115, Taiwan > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
