Open Stack

I've also noticed that if you don't want to deal with extra pain, make sure you don't mount directly the volume within the instances when it starts (I'm thinking about the fstab file that would mount a volume exposed by nova-volume)
If you need for specific reason to have it mounted, rely more on labeling rather than /dev/path.
I'm myself managing the volume mounting after I made sure the hypervisor has it's iscsi sessions working.

Nuage & Co - Razique Mahroua 
razique.mahroua at gmail.com



Le 12 mars 2012 à 16:00, Razique Mahroua a écrit :

> I explained in the doc how I deal with disasters - basically, a magic solution doesn't exist- nova not being environment-aware.
> http://docs.openstack.org/trunk/openstack-compute/admin/content/nova-disaster-recovery-process.html
> Regarding the flag, you can safely use it when your instances usage doesn't imply the nova-volume usage, that one making every hypervisor dependant to the iscsi sessions. Which are quite a pain, but necessary in that current implementation.
> 
> 
> Nuage & Co - Razique Mahroua 
> razique.mahroua at gmail.com
> 
> <NUAGECO-LOGO-Fblan_petit.jpg>
> 
> Le 12 mars 2012 à 15:38, David Kranz a écrit :
> 
>> A while back I saw a comment about this in
>> http://mirantis.blogspot.com/2011/06/openstack-nova-basic-disaster-recovery.html
>> which suggests that setting these flags may not always be a good idea.
>> If this is what should be done, why are these flags false by default?
>> Perhaps a nova expert can comment.
>> 
>> More generally, I haven't seen much documentation in nova about how to
>> deal with various failure scenarios. There is a lot more information
>> about this for Swift and there were some sessions at the last design
>> summit that provided a lot of useful information about the mechanics of
>> operating a real Swift cluster. I think such a session for nova at the
>> upcoming summit would be very useful as well.
>> 
>> -David
>> 
>> 
>> 
>> On 3/12/2012 10:14 AM, Christian Wittwer wrote:
>>> You can let nova-compute start the instances after a host reboot.
>>> 
>>> --start_guests_on_host_boot
>>> --resume_guests_state_on_host_boot
>>> 
>>> 2012/3/10 Vishvananda Ishaya <vishvananda at gmail.com>:
>>>> I think that this branch should make reboot work:
>>>> 
>>>> https://review.openstack.org/#change,5177
>>>> 
>>>> It looks like we should also make sync_power_states run more frequently.  It
>>>> currently runs every 6 minutes by default.
>>>> 
>>>> On Mar 8, 2012, at 6:27 PM, DeadSun wrote:
>>>> 
>>>> As we all know, if host reboot since of some failure or hardware problem,
>>>> the vms will actually shutoff. But after host up, info in nova db show vm
>>>> state are "active", and using "nova list" return the same.
>>>> 
>>>> Now how to start the vms. In Daiblo, I always just using "nova reboot", it
>>>> works.But in essex version, it seems cannot use "nova reboot" in an inactive
>>>> domain. I see there is "nova host-action" command, but it not always make vm
>>>> start.
>>>> 
>>>> Another way, I can use "virsh start" a domain, but if the vm attach a
>>>> volume, it doesn't work. "nova volume-detach" cannot detach a volume in an
>>>> inactive domain.
>>>> 
>>>> Is there a normal way to resolve this case?
>>>> 
>>>> --
>>>> 非淡薄无以明志，非宁静无以致远
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120312/be6126ca/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NUAGECO-LOGO-Fblan_petit.jpg
Type: image/jpeg
Size: 10122 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120312/be6126ca/attachment.jpg>