You can't just change the contents of a volume under the instance though - at the very least you need to do an unmount in the instance, and a detach is preferable, otherwise you've got data corruption issues.
At that point, the device naming problems are identical. On 11 April 2016 at 20:22, Erlon Cruz <sombra...@gmail.com> wrote: > The actual user workflow is: > > 1 - User creates a volume(s) > 2 - User attach volume to instance > 3 - User creates a snapshot > 4 - Something happens causing the need of a revert > 5 - User creates a volume(s) from the snapshot(s) > 6 - User detach old volumes > 7 - User attach new volumes (and pray so they get the same id) - Nova, > should have the ability to honor supplied device names (vdc, vdd, etc), > which not always happen[1]. But, does the volume keep the same UUID in the > system? Several application use that to boot. > > The suggested workflow would be simpler for a user POV: > > 1 - User creates a volume(s) > 2 - User attach volume to instance > 3 - User creates a snapshot > 4 - Something happens causing the need of a revert > 5 - User revert snapshot(s) > > > [1] https://goo.gl/Kusfne > > On Fri, Apr 8, 2016 at 5:07 AM, Ivan Kolodyazhny <e...@e0ne.info> wrote: > >> Hi Chenzongliang, >> >> I still don't understand what is difference between proposed feature and >> 'restore volume from snapshot'? Could you please explain it? >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang <chenzongli...@huawei.com> >> wrote: >> >>> Dear Cruz: >>> >>> >>> >>> Thanks for you kind support, I will review the previous spec >>> according to the following links. May be more user scenario we should >>> considered,such as backup,create volume from snapshot,consistency group and >>> etc,we will spend some time to gather >>> >>> the user's scenarios and determin what to do next step. >>> >>> >>> >>> Sincerely, >>> >>> zongliang chen >>> >>> >>> >>> *发件人:* Erlon Cruz [mailto:sombra...@gmail.com] >>> *发送时间:* 2016年4月5日 2:50 >>> *收件人:* OpenStack Development Mailing List (not for usage questions) >>> *抄送:* Zhangli (ISSP); Shenhong (C) >>> *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback? >>> >>> >>> >>> Hi Chen, >>> >>> >>> >>> Not sure if I got you right but I brought this topic in >>> #openstack-cinder some days ago. The idea is to be able to rollback a >>> snapshot in Cinder. Today what is possible to do is to create a volume from >>> a snapshot. From the user point of view, this is not ideal, as there are >>> several cases, if not the majority of, that the purpose of the snapshot is >>> to revert to a desired state, and not keep the original volume. For some >>> backends, keeping the original volume means space consumption. This space >>> problem becomes bold when we think about consistency groups. For >>> consistency groups, some backends might have to copy an entire filesystem >>> for each snapshot, consuming space and time. So, I think it would be >>> desired to have the ability to revert snapshots. >>> >>> >>> >>> I know there have been efforts in the past[1] to implement that, but for >>> some reason the work was stopped. If you want to retake the effort please >>> create a spec[2] sol everybody can provide feedback. >>> >>> >>> >>> Erlon >>> >>> >>> >>> >>> >>> [1] >>> https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot >>> >>> [2] https://github.com/openstack/cinder-specs >>> >>> >>> >>> On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang <chenzongli...@huawei.com> >>> wrote: >>> >>> Hi all: >>> >>> We are condering add a fucntion rollback_snapshot when we use >>> backup. In the end user's scenario. If a vm fails, we hope that we can use >>> snapshot to to recovery the volume's data. >>> >>> Beacuse it can quickly recovery our vm. But if we use the remote >>> data to recovery. We will spend more time. >>> >>> But i'm not sure if the data was recoveried from the backend. >>> whether the host need to rescan the volumes? At the same time. If a volume >>> have been extended, whether it can be roolback? >>> >>> >>> >>> I want to know whether the topic have been discussed or have other >>> recommendations to us? >>> >>> >>> >>> Thanks >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- -- Duncan Thomas
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev