Open Stack

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



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/a9a84712/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/a9a84712/attachment.jpg>