Sent: Monday, 16 February, 2015 9:17:26 PM
Subject: Re: Your thoughts on using Primary Storage for keeping
snapshots
Well...count me in on the general-purpose part (I'm already working
on that
and have much of it working).
If someone is interested in implementing the RBD part, he/she c
e community?
> > >
> > > Andrei
> > >
> > > - Original Message -
> > >
> > > > From: "Mike Tutkowski"
> > > > To: dev@cloudstack.apache.org
> > > > Sent: Monday, 16 February, 2015 9:17:26 PM
> >
r would
> > achieve a faster response from the community?
> >
> > Andrei
> >
> > - Original Message -
> >
> > > From: "Mike Tutkowski"
> > > To: dev@cloudstack.apache.org
> > > Sent: Monday, 16 February, 2015 9:17:26 PM
> >
er response from the community?
>
> Andrei
>
> - Original Message -
>
> > From: "Mike Tutkowski"
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 16 February, 2015 9:17:26 PM
> > Subject: Re: Your thoughts on using Primary Storage for
achieve a faster
response from the community?
Andrei
- Original Message -
> From: "Mike Tutkowski"
> To: dev@cloudstack.apache.org
> Sent: Monday, 16 February, 2015 9:17:26 PM
> Subject: Re: Your thoughts on using Primary Storage for keeping
> snapshots
&g
Well...count me in on the general-purpose part (I'm already working on that
and have much of it working).
If someone is interested in implementing the RBD part, he/she can sync with
me and see if there is any overlapping work that I've already implementing
from a general-purpose standpoint.
On Mo
Agree with Logan. As fans of Ceph as well as SolidFire, we are interested
in seeing this particular use case (RBD/KVM) being well implemented,
however the concept of volume snapshots residing only on primary storage vs
being transferred to secondary storage is a more generally useful one that
is wo
Hi Mike,
I agree it is a general CloudStack issue that can be addressed across
multiple primary storage options. It's a two stage issue since some
changes will need to be implemented to support these features across
the board, and others will need to be made to each storage option.
It would be n
Hey Ian,
Since it looks like the intent of this particular thread is just to discuss
RBD and snapshots (which I don't think your business uses), you would be
more interested in the "Query on snapshot and cloning for managed storage"
thread as that one talks about this issue at a more general level
For example, Punith from CloudByte sent out an e-mail yesterday that was
very similar to this thread, but he was wondering how to implement such a
concept on his company's SAN technology.
On Mon, Feb 16, 2015 at 10:40 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Yeah, I think it's
Yeah, I think it's a similar concept, though.
You would want to take snapshots on Ceph (or some other backend system that
acts as primary storage) instead of copying data to secondary storage and
calling it a snapshot.
For Ceph or any other backend system like that, the idea is to speed up
snapsh
Hi Mike,
I think the interest in this issue is primarily for Ceph RBD, which
doesn't use iSCSI or SAN concepts in general. As well I believe RBD
is only currently supported in KVM (and VMware?). QEMU has native RBD
support, so it attaches the devices directly to the VMs in question.
It also nati
I should have also commented on KVM (since that was the hypervisor called
out in the initial e-mail).
In my situation, most of my customers use XenServer and/or ESXi, so KVM has
received the fewest of my cycles with regards to those three hypervisors.
KVM, though, is actually the simplest hypervi
I have been working on this on and off for a while now (as time permits).
Here is an e-mail I sent to a customer of ours that helps describe some of
the issues:
*** Beginning of e-mail ***
The main requests were around the following features:
* The ability to leverage SolidFire snapshots.
* Th
I'm just going to stick with the qemu-img option change for RBD for
now (which should cut snapshot time down drastically), and look
forward to this in the future. I'd be happy to help get this moving,
but I'm not enough of a developer to lead the charge.
As far as renaming goes, I agree that mayb
On 16-02-15 15:38, Logan Barfield wrote:
> I like this idea a lot for Ceph RBD. I do think there should still be
> support for copying snapshots to secondary storage as needed (for
> transfers between zones, etc.). I really think that this could be
> part of a larger move to clarify the naming
Totally agreed that there is high value in having both the ability to do
rapid, lightweight snapshots on primary storage as well as the ability to
transfer those snapshots to secondary storage for highly durable long-term
use, template creation etc... Glad to hear that others see a distinction
betw
stack.apache.org
> Sent: Monday, 16 February, 2015 2:38:00 PM
> Subject: Re: Your thoughts on using Primary Storage for keeping
> snapshots
> I like this idea a lot for Ceph RBD. I do think there should still be
> support for copying snapshots to secondary storage as needed (for
>
I like this idea a lot for Ceph RBD. I do think there should still be
support for copying snapshots to secondary storage as needed (for
transfers between zones, etc.). I really think that this could be
part of a larger move to clarify the naming conventions used for disk
operations. Currently "V
BIG +1
My team should submit some patch to ACS for better KVM snapshots, including
whole VM snapshot etc...but it's too early to give details...
best
On 16 February 2015 at 13:01, Andrei Mikhailovsky wrote:
> Hello guys,
>
> I was hoping to have some feedback from the community on the subject o
Hello guys,
I was hoping to have some feedback from the community on the subject of having
an ability to keep snapshots on the primary storage where it is supported by
the storage backend.
The idea behind this functionality is to improve how snapshots are currently
handled on KVM hypervisors
21 matches
Mail list logo
