Re: [Openstack] nova-volumes problem after host reboot

2012-11-19 Thread Pádraig Brady
On 11/10/2012 03:17 PM, Ronivon Costa wrote: Hi there, I am dealing with this issue for a while, but could not figure out what is going on. After a reboot in the openstack server, I am not able to restart ANY instance that had a nova-volume attached. I tried the DR procedure here without any

Re: [Openstack] nova-volumes problem after host reboot

2012-11-18 Thread Ronivon Costa
Hello, I am still working on this issue. I can not apply the disaster recovery as describe here: http://docs.openstack.org/trunk/openstack-compute/admin/content/nova-disaster-recovery-process.html Thanks to livemoon, I can get the instances back running following his tips. By the way, I have put

Re: [Openstack] nova-volumes problem after host reboot

2012-11-18 Thread Yong Jiang
Hi Ronivon Costa, Besides updating volumes table, you should update block_device_mapping table at the same time which manages the mapping between volumes and instances. Using the below commands update these two tables and you can reboot your instances and reattach your volume as normally with

[Openstack] nova-volumes problem after host reboot

2012-11-10 Thread Ronivon Costa
Hi there, I am dealing with this issue for a while, but could not figure out what is going on. After a reboot in the openstack server, I am not able to restart ANY instance that had a nova-volume attached. I tried the DR procedure here without any improvement:

Re: [Openstack] nova-volumes problem after host reboot

2012-11-10 Thread livemoon
Hi, Ronivon Costa If you use kvm(libvirt), you can logon the compute node. use virsh list --all list all your no-running vm. For example, there is an instance name instance-0001, you cannot reboot using nova command because it attached block disk. You need do: 1. virsh undefine

Re: [Openstack] nova-volumes problem after host reboot

2012-11-10 Thread Ronivon Costa
Hi, Had some improvement with this issue. Could boot the instance using virsh, following livemoon advice with small adaptation. However the problem still is not fixed. The volume table was update: mysql -unova -p$PW nova -e update volumes set mountpoint=NULL, attach_status='detached',