[openstack-dev] [nova] expose quiesce unquiesce api

joehuang joehuang at huawei.com
Thu Oct 15 04:23:46 UTC 2015


Currently the Nova provides VM snapshot API, which will take a consistency snapshot of a VM and regarding volumes, and will quiesce/unquiesce VM automatily with guest agent support.

We learned that the exposure of quiesce/unquiesce api in Nova was "abandoned" in the history. Now we have these requirement from OPNFV(https://wiki.opnfv.org/) multisite project for different use case from NFV area:

In NFV scenario, a VNF (telecom application) often is consisted of a group of VMs. To make it be able to restore in another site for catastrophic failures happened, this group of VMs snapshot/backup/restore should be done in a transaction way to guarantee the application level consistency but not only on single VM level : for example, quiesce VM1, quiesce VM2, quiesce VM3, snapshot VM1's volumes, snapshot VM2's volumes, snapshot VM3's volumes, unquiesce VM3, unquiesce VM2, unquiesce VM1. For some telecom application, the order is very important for a group of VMs with strong relationship.

Therefore the OPNFV multsite project expects Nova to provide atomic quiesce / unquiesce API, to make consistency snapshot of a group of VMs in a transaction way is possible (but not only one single VM instead).

If there is no great different opinion, we would like to submit spec for this BP, and hope it could be implemented in M release.

Refer to https://gerrit.opnfv.org/gerrit/#/c/1438/3/multisite-vnf-gr-requirement.rst for more detail description

The use case consensus is agreed in the meeting of OPNFV multisite project: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-09-03-08.02.html

OPNFV multisite project: https://wiki.opnfv.org/multisite

Best Regards
Chaoyi Huang ( Joe Huang )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151015/338674ca/attachment.html>

More information about the OpenStack-dev mailing list