In EC2, shutdown_terminate is really to deal with instance-store (local) vs EBS-backed (remote volume) instances. Once an instance is stopped, all local state is cleaned so there is no way to bring back a VM whose disk is local. That's why it's terminated automatically. For EBS-backed instances, there is no local state. To start a stopped EBS instance, it will go through the scheduler to find a compute node as if we are creating a new instance.
My bet is that there are people who depend on this kind of EC2 compatibility. https://bugs.launchpad.net/nova/+bug/905270 Whether that's too much a burden to support, I'm not sure... A related problem to stopped instances is about resource management. Once the VM is stopped, it doesn't occupy resources (say memory). This will be periodically reported back to the DB by the compute manager, and the scheduler will be aware of that. However, starting the instance back goes directly to the compute node. So it's possible that you either have overcommitted resources in this case because new VMs are spawned while in shutdown mode, or simply fail to start a VM due to the lack of resources. Billing stopped instances is tricky too but it seems to be more provider specific. Personally I like the EC2 API behavior over OS API because it makes resource management simpler. But I'd be happy to go with OS API behavior if we can have a good story to the resource update problem. In any case, having a single, well defined, consistent behavior is better than what's happening now. :) Thanks, Yun On Fri, Jun 1, 2012 at 3:45 AM, Vishvananda Ishaya <[email protected]> wrote: > I did some cleanup of stop and power_off in the review here. > > https://review.openstack.org/#/c/8021/ > > I removed the weird shutdown_terminate handling. Honestly I feel like > that is compatibility we don't need. It should be up to the provider whether > a stop_instances counts as a terminate. In my mind they are two different > things. > > Comments welcome on the review. > > Vish > > On May 31, 2012, at 6:40 PM, Yun Mao wrote: > > shutdown, stop, are power_off are synonym in this discussion. They all > mean to stop the VM from running, but keep the disk image and network, > so that the VM could be started back on again. > > There are three ways to do it: 1) using EC2 stop-instance API. 2) use > OS API stop-server. 3) inside the VM, execute halt or equivalent. > However, the devil is in the details. > > In EC2 API, a shutdown_terminate flag is checked when a stop-instance > call is issued. If it's true, then stop-instances actually means > terminate instances. The flag is true by default unless there is block > device mapping provided, and it doesn't appear to be configurable by a > user. > > In OS API, it's defined in v1.1, neither the specification nor the > implementation check the shutdown_terminate flag at all. It will > always do stop instead of terminate. > > So, when shutdown_terminate is true (default), the OS API and the EC2 > API will behave differently. If we accept this, it might still be > acceptable. After all they are different APIs and could have different > behavior. But the pickle is the case where a user initiates a shutdown > inside the VM. What's the expected behavior after it's detected? > Should it respect the shutdown_terminate flag or work more like an OS > API? Right now when a shutdown in a VM is detected, the vm state is > updated to SHUTOFF and that's pretty much it.. > > To summarize, there are 3 ways of doing the same thing, each now has a > different behavior. I'd vote to patch the code to be a little more > consistent. But what should be the right behavior? > > Yun > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
