Thank you for your feedback How many fields does the “fixed_ips” contain? what’s the size of the database? You can check rabbitmq log to see if there’s anything suspicious
On 6 Nov 2013 at 06:28:16, Antonio Messina ([email protected]) wrote: On Wed, Nov 6, 2013 at 3:06 PM, Razique Mahroua <[email protected]> wrote: > I can do some consulting if you want :p This may be interesting, but totally off topic :) > Which mail are you referring to? This one: http://lists.openstack.org/pipermail/openstack/2013-November/002623.html subject: "Instances fail during/after networking" > and what do you mean by “crazy”? Performance-wise or did you have some bugs > due to your inconsistent database? nova-network is spinning at 80-90% of cpu for minutes, giving IP addresses only after a few *minutes*, so that the creation of the VM goes in timeout and thus is failing. Similarly when deleting a VM, it takes ages and sometimes I have to terminate them twice in order to have them killed. .a. > > -- > Razique > > On 6 Nov 2013 at 06:06:47, Antonio Messina ([email protected]) > wrote: > > On Wed, Nov 6, 2013 at 12:46 PM, Razique Mahroua > <[email protected]> wrote: >> I’d say it’s risky since it’s possible that you end up with inconsistent >> states, especially with the security_groups and keypairs tables. >> >> You should probably dump the whole database and restore it if needed > > I cannot. > The reason why I need to do it is because the current database is > already in a state which is driving nova-network crazy. > > I have sent an email a few days ago about the problem we are having > with our installation. After some more checking, it seems that the > problem is caused by the *data* currently stored in the database; we > tried with an empty one and everything was working smoothly: instances > are started within one minute and deleted as needed, while going back > to the original database brings back the issue. > > So, we guess it's something on the database, but we don't have either > the time nor the competence nor the need to further debug the issue, > since we are planning to move Havana soon and we have to keep the > cloud up&running ASAP. > > Therefore we decided to clean up the database and remove more or less > everything, but as I said, we would like to keep the information > mentioned before. > > .a. > >> >> >> Razique >> >> -- >> Razique >> >> On 6 Nov 2013 at 03:46:02, Antonio Messina ([email protected]) >> wrote: >> >> Hi all, >> >> We need to backup and then recover some information from the nova >> database, specifically: >> >> * flavors >> * quotas >> * keypairs >> * security groups >> >> I would like to know which tables I am supposed to back up and >> recover, I guess the following: >> >> * quotas >> * security_groups >> * security_group_rules >> * instance_types >> >> are enough? Can I just dump them with mysqldump and recover them with >> mysql < backupfile? >> >> .a. >> >> -- br/>antonio.s.messina@@gmail.com >> [email protected] +41 (0)44 635 42 22 >> GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ >> University of Zurich >> Winterthurerstrasse 190 >> CH-8057 Zurich Switzerland >> >> _______________________________________________ >> Mailing list: >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >> Post to : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > -- br/>antonio.s.messina@@gmail.com > [email protected] +41 (0)44 635 42 22 > GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ > University of Zurich > Winterthurerstrasse 190 > CH-8057 Zurich Switzerland -- [email protected] [email protected] +41 (0)44 635 42 22 GC3: Grid Computing Competence Center http://www.gc3.uzh.ch/ University of Zurich Winterthurerstrasse 190 CH-8057 Zurich Switzerland
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
