As a follow up on this. You can configure the host to shutdown and start up in a way that all the VM’s are shutdown and started up automatically.
To do this you need to do a few things: 1.) Ensure that nova-compute is configured to stopped before libvirt-guests. Make sure libvirt-guests is enabled. 2.) Allow libvirt-guests to shutdown the vm’s that are running (I recommend avoiding suspending the vm’s. As this will lead to in vm clock sync issues): ON_SHUTDOWN=shutdown 3.) Ensure that libvirt-guests is configure with: ON_BOOT=ignore 4.) Set [DEFAULT] resume_guests_state_on_host_boot=true in nova.conf This config will gracefully shutdown the running vm’s via a normal host shutdown, preserving the running state in nova. This will then cause nova to bring the vm’s online when nova-compute starts on host start up. This also works with ungraceful power downs. The key is that nova needs to be the one that starts the VM’s. Because libvirt-guests will not be able to successfully start the vm’s, because neutron eeds to plug the vifs for the vms. As long as the state of the VM is “running” inside the DB, this config will work. NB: if you do chassis swaps and for some reason the OS comes up in a config that no longer works, all of the VM’s will go to error. You will need to fix whatever issue prevented the vm’s from starting and manually reset the state and start the vms. Some examples that we have seen: vtx extensions disabled on new server. Replacement server has different cpu’s and no longer matches either the numa config or the new processors do not have the same cpu extensions as the old processors. ___________________________________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy From: Adam Thurlow <[email protected]> Date: Wednesday, November 16, 2016 at 9:58 PM To: "[email protected]" <[email protected]> Subject: Re: [Openstack-operators] sync power states and externally shut off VMs 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]<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
