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
<[email protected] <mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
