That is correct Mike. The quoted part above was misleading, it should have been "at any given point in time *when transaction finished*" Removal of "other" or "current failed" snapshot happens at the very end of the method. The state of SR throughout time would be something like:
1) snapshot-01 (at rest) 2) snapshot-01, snapshot-02 (while taking snapshot-02 on primary storage and sending to secondary storage) 3) snapshot-02 (at rest again, after successful) OR 3) snapshot-01 (at rest again, after failure) Khosrow Moossavi Cloud Infrastructure Developer t 514.447.3456 <https://goo.gl/NYZ8KK> On Tue, Jan 9, 2018 at 4:33 PM, Tutkowski, Mike <mike.tutkow...@netapp.com> wrote: > “technically we should only have "one" on primary storage at any given > point in time” > > I just wanted to follow up on this one. > > When we are copying a delta from the previous snapshot, we should actually > have two snapshots on primary storage for a time. > > If the delta copy is successful, then we delete the older snapshot. If the > delta copy fails, then we delete the newest snapshot. > > Is that correct? > > > On Jan 9, 2018, at 11:36 AM, Khosrow Moossavi <kmooss...@cloudops.com> > wrote: > > > > "We are already deleting snapshots in the primary storage, but we always > > leave behind the last one" > > > > This issue doesn't happen only when something fails. We are not deleting > the > > snapshots from primary storage (not on XenServer 6.25+ and not since Feb > > 2017) > > > > The fix of this PR is: > > > > 1) when transferred successfully to secondary storage everything except > > "this" > > snapshot get removed (technically we should only have "one" on primary > > storage > > at any given point in time) [towards the end of try block] > > 2) when transferring to secondary storage fails, only "this" in-progress > > snapshot > > gets deleted. [finally block] > > > > > > > > On Tue, Jan 9, 2018 at 1:01 PM, Rafael Weingärtner < > > rafaelweingart...@gmail.com> wrote: > > > >> Khosrow, I have seen this issue as well. It happens when there are > problems > >> to transfer the snapshot from the primary to the secondary storage. > >> However, we need to clarify one thing. We are already deleting > snapshots in > >> the primary storage, but we always leave behind the last one. The > problem > >> is that if an error happens, during the transfer of the VHD from the > >> primary to the secondary storage. The failed snapshot VDI is left > behind in > >> primary storage (for XenServer). These failed snapshots can accumulate > with > >> time and cause the problem you described because XenServer will not be > able > >> to coalesce the VHD files of the VM. Therefore, what you are addressing > in > >> this PR are cases when an exception happens during the transfer from > >> primary to secondary storage. > >> > >> On Tue, Jan 9, 2018 at 3:25 PM, Khosrow Moossavi < > kmooss...@cloudops.com> > >> wrote: > >> > >>> Hi community > >>> > >>> We've found [1] and fixed [2] an issue in 4.10 regarding snapshots > >>> remaining on primary storage (XenServer + Swift) which causes VDI chain > >>> gets full after some time and user cannot take another snapshot. > >>> > >>> Please include this in 4.11 milestone if you see fit. > >>> > >>> [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-10222 > >>> [2]: https://github.com/apache/cloudstack/pull/2398 > >>> > >>> Thanks > >>> Khosrow > >>> > >> > >> > >> > >> -- > >> Rafael Weingärtner > >> >
