> functionality exactly the way it was originally implemented and if
>>>>> a user wished to change the functionality they could via a global config
>>>>> variable.
>>>>>
>>>>> Your original spec for PR 2081 in confluence states that the PR
From: Tutkowski, Mike
Sent: Saturday, May 19, 2018 8:40 PM
To: dev@cloudstack.apache.org
Subject: Re: Snapshots only on Primary Storage feature
Perhaps instead of renaming the setting, we can note in its description the
hypervisors it currently pertains to.
> On
he create template or download template features are used, use the
> primary storage as the source.
>
> Kind regards,
> Glen Baars
>
> -Original Message-
> From: Will Stevens
> Sent: Saturday, 19 May 2018 12:57 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Snap
@cloudstack.apache.org
Subject: Re: Snapshots only on Primary Storage feature
I think reverting the change in 4.11.1 is probably a good idea.
*Will Stevens*
Chief Technology Officer
c 514.826.0190
<https://goo.gl/NYZ8KK>
On Fri, May 18, 2018 at 2:52 PM ilya musayev
wrote:
> Perhaps brin
which can result in the job timeout and the User may
> > assume
> > > > > that it is already Backed up based on its state, unless it is
> > > documented.
> > > > >
> > > > > -Suresh
> > > > >
> > > > > On Fri, May 18, 201
the original PR was to optionally disable this
> > > > functionality.
> > > >
> > > > We don't expose views of the backup state to our customers (we have
> our
> > > > own customer interfaces) and it's a large waste of space for us to be
>
>
>
>
> From: Will Stevens
> Sent: Friday, May 18, 2018 6:12 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Snapshots only on Primary Storage feature
>
> Just because it does not work for VMware should not a reason to rip out the
> func
be
> > backing up tons of VM images when we have a solid primary storage
> > infrastructure that already has lots of resiliency.
> >
> >
> > I guess we're going to have to revisit this again before we can consider
> > rebasing on 4.11.
> >
> > ___
ons of VM images when we have a solid primary storage
> > infrastructure that already has lots of resiliency.
> >
> >
> > I guess we're going to have to revisit this again before we can consider
> > rebasing on 4.11.
> >
> > _____
Anaparti
> Sent: Thursday, May 17, 2018 2:21 PM
> To: dev
> Subject: Re: Snapshots only on Primary Storage feature
>
> Hi Si,
>
> No. not possible to disable the backup to secondary. It copies the volume
> snapshot to secondary in a background thread using asyncBackup param (set
;
> - Si
>
>
> From: Suresh Kumar Anaparti
> Sent: Thursday, May 17, 2018 1:37 PM
> To: dev@cloudstack.apache.org
> Cc: Nathan Johnson
> Subject: Re: Snapshots only on Primary Storage feature
>
> Hi Glen / Si,
>
> In PR# 1697, t
ouldn't even be involved in most of
> > these options, instead using the native clone features of the underlying
> > storage.
> >
> >
> > - Si
> >
> > ________________
> > From: Suresh Kumar Anaparti
> > Sent: Thursda
;
>
> From: Suresh Kumar Anaparti
> Sent: Thursday, May 17, 2018 1:37 PM
> To: dev@cloudstack.apache.org
> Cc: Nathan Johnson
> Subject: Re: Snapshots only on Primary Storage feature
>
> Hi Glen / Si,
>
> In PR# 1697, the global setting *sna
1:37 PM
To: dev@cloudstack.apache.org
Cc: Nathan Johnson
Subject: Re: Snapshots only on Primary Storage feature
Hi Glen / Si,
In PR# 1697, the global setting *snapshot.backup.rightafter* if set to
true, it'll be the default behaviour and snapshot is copied to the
secondary storage. If set to fals
From: Glen Baars
> Sent: Thursday, May 17, 2018 9:46 AM
> To: dev@cloudstack.apache.org
> Subject: Snapshots only on Primary Storage feature
>
>
> Hello Devs,
>
>
>
> I have been thinking about a feature request and want to see what people
> think about the u
.
- Si
From: Glen Baars
Sent: Thursday, May 17, 2018 9:46 AM
To: dev@cloudstack.apache.org
Subject: Snapshots only on Primary Storage feature
Hello Devs,
I have been thinking about a feature request and want to see what people think
about the use case
Hello Devs,
I have been thinking about a feature request and want to see what people think
about the use case.
We use KVM + Ceph RBD as storage.
Currently, when a client takes a snapshot, Cloudstack takes a Ceph snapshot and
then uses qemu-img to export to secondary storage. This creates
17 matches
Mail list logo
