Open Stack

If you are interested in manually mucking around with local virsh domain 
states, and you don't want nova to interfere, you can just stop the 
local nova-compute service and it won't be doing any syncing. Once you 
get those instances back into their desired state, you can restart 
nova-compute and it won't be any wiser.

You can obviously shoot yourself in the foot using this method, but I 
can understand in some cases that large hammers and manual virsh 
commands are necessary.

Cheers!

On 2016-11-16 17:32, Mohammed Naser wrote:
> Typically, you should not be managing your VMs by virsh. After a power 
> outage, I would recommend sending a start API call to instances that 
> are housed on that specific hypervisor
>
> Sent from my iPhone
>
> On Nov 16, 2016, at 4:26 PM, Gustavo Randich 
> <gustavo.randich at gmail.com <mailto:gustavo.randich at gmail.com>> wrote:
>
>> When a VM is shutdown without using nova API (kvm process down, 
>> libvirt failed to start instance on host boot, etc.), Openstack 
>> "freezes" the shutdown power state in the DB, and then re-applies it 
>> if the VM is not started via API, e.g.:
>>
>>     # virsh shutdown <domain>
>>
>>     [ sync power states -> stop instance via API ], because
>>     hypervisor rules ("power_state is always updated from hypervisor
>>     to db")
>>
>>     # virsh startup <domain>
>>
>>     [ sync power states -> stop instance via API ], because database
>>     rules
>>
>>
>>
>> I understand this behaviour is "by design", but I'm confused about 
>> the asymmetry: if VM is shutdown without using nova API, should I not 
>> be able to start it up again without nova API?
>>
>> This is a common scenario in power outages or failures external to 
>> Openstack, when VMs fail to start and we need to start them up again 
>> using virsh.
>>
>> Thanks!
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org 
>> <mailto:OpenStack-operators at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20161117/9642a12c/attachment.html>