I wouldn't comment on the feasibility of this - but snapshots that stays on Primary Storage... in case of Primary Storage issues, will be unusable also. Perhaps you are talking about issues inside VMs - in this sense, again, snapshots might not be (in my opinion...) the best solution, at least such frequent snapshots, but again that is only my opinion.. Perhaps a proper backup mechanism inside VMs etc...
Anyhow, there is VM-level snapshots if KVM is using NFS for Primary Storage (and same for XenServer afaik) - these should be tested and evaluated for your use case. Simple volume snapshots are probably not going to work for you/customer in case of multiple-volume VMs - since you need to ensure consistent state inside the OS filesystem/apps, etc (imagine DB on volume1, and logs on volume2, etc) I'm just afraid that keeping huge number of snapshots of the VM will mean a serious performance degradation sooner or later. just my 2 cents, if you don't mind. Cheers On Mon, 29 Oct 2018 at 15:35, Alexandre Bruyere <bruyere.alexan...@gmail.com> wrote: > Tests will be done for sure. > > Use case is 5-minute snapshots on VMs for ultra-high-availability hybrid > cloud - to provide small and medium businesses with a reliable system that, > in the case of issues, loses as little work as possible. > > On Sun, Oct 28, 2018 at 6:00 AM Andrija Panic <andrija.pa...@gmail.com> > wrote: > > > I'm not sure what is your use case - what you want to achieve - but make > > sure to test this thoroughly > > > > You can "manually" (outside of ACS) always make a snap of the volume, but > > you need to make sure that this doesn't collide with CloudStack in any > way > > - i.e. there is also VM level snapshots in KVM if you are using NFS as > > Primary Storage - so check this out maybe it works for you - here for > > example you have the limitation (if I remember correctly) that you can > not > > attach additional volume (or something similar) to the VM, until you have > > deleted all VM-level snapshots, etc. (which makes sense of course) > > > > I guess it takes a lot of work to skip Secondary Storage (snapshot > workflow > > inside CLoudStack), because you need to make sure to provide workflow for > > all different Primary Storage providers (there are bunch of them, not > only > > NFS...), and then there are bunch of HyperVisors supported, and so on, so > > it's a big challenge (I'm not developer, but that is my assumption) > > > > Cheers > > > > On Sun, 28 Oct 2018 at 00:06, Alexandre Bruyere < > > bruyere.alexan...@gmail.com> > > wrote: > > > > > Well... Sounds like the new scripters that are coming in tomorrow will > > come > > > in handy. I'll probably have them script something to pull snapshots > from > > > KVM directly instead of going through Cloudstack. > > > > > > Is there anything that would stop this from working? > > > > > > On Fri, Oct 26, 2018 at 4:15 PM Andrija Panic <andrija.pa...@gmail.com > > > > > wrote: > > > > > > > Yes. > > > > > > > > There are improvements being done atm, (afaik), to try to manage > > > snapshots > > > > on the primary storage (for NFS and maybe CEPH, it's already > > implemented > > > on > > > > i.e. SolidFire). > > > > > > > > Simply this is how it was working so far - snapshots are meant to be > > > moved > > > > to Secondary Storage (and later can be converted to Templates, > > downloaded > > > > from SSVM, converted to volumes etc). > > > > I agree with you, but that is how it was implemented, I assume for > > > > compatibility reasons - since different Hypervisors manage things in > > > > different ways - you have to support different hypervisosrs, > different > > > > storage solutions etc (it's NOT only NFS...). > > > > > > > > Cheers > > > > > > > > > > > > On Fri, 26 Oct 2018 at 22:08, Alexandre Bruyere < > > > > bruyere.alexan...@gmail.com> > > > > wrote: > > > > > > > > > So wait. Are you telling me that Cloudstack does a full backup of > the > > > > > volume every time a snapshot is taken? > > > > > > > > > > What's the point of snapshots then? Making specific operations > > faster? > > > > > > > > > > -- > > > > > Alexandre Bruyère > > > > > > > > > > -----Original Message----- > > > > > Re: Questions on snapshots > > > > > From: Andrija Panic <andrija.pa...@gmail.com> > > > > > To: users <users@cloudstack.apache.org> > > > > > Friday, October 26, 2018 at 3:38 PM > > > > > > > > > > So :) > > > > > > > > > > 1. Snap interval - scheduled snaps are max 1h per the so called > > > "hourly" > > > > > schedule - so makes sense :) You could do some automation, by > > creating > > > > > manual snapshots and deleting oldest ones via automation - i.e. you > > can > > > > > use Cloud Monkey, CLI utility that talk to API and is great for any > > > kind > > > > of > > > > > automation, unless you talk directly to API from i.e. Python etc, > via > > > > > HTTPS. > > > > > > > > > > 2. number of snaps: Go to Global Configuration, there is parameter > > > > > "snapshot.max.hourly" - and you can change it, I assume to <=24 > > > > ...(restart > > > > > mgmt server and you are good),(there are similar for daily and > > monthly) > > > > > > > > > > Now, related to snapshots - when you decided to really use them > (i.e. > > > in > > > > > production) - a BIG warning - make sure to "know" what you are > > doing... > > > > > Because so far, when you create a snapshot of the volume on Primary > > > > Storage > > > > > (NFS or CEPH), there is really a snapshot that is created almost > > > > instantly > > > > > of that volume, but then the whole image (so whole image in that > > point > > > in > > > > > time) is being copied over (qemu-img) to the Secondary Storage NFS > - > > > and > > > > in > > > > > case of too frequent snaps, or modest networking, this might at > some > > > > point > > > > > throttle your network and also break some logic inside CloudStack > > > > > For example: I had clients that were expecting to do hourly > snapshots > > > of > > > > > the 2TB image (right... perhaps a too much expectation from their > > side) > > > > and > > > > > this can fail with timeout (in my case it was modest CEPH > > performance) > > > > > Also pay attention to schedules, so you don't have hourly snap (one > > of > > > > > hourly runs) begin at i.e. 17.00h and then you configured at same > > time > > > > > (17.00) daily (/weekly/monthly) at 17.00 (or about the same time) - > > > those > > > > > later snaps will simply fail, because there is already ongoing snap > > on > > > > the > > > > > same volume. > > > > > > > > > > Sorry long post... > > > > > > > > > > > > > > > Cheers > > > > > Andrija > > > > > > > > > > On Fri, 26 Oct 2018 at 20:53, Alexandre Bruyere < > > > > > bruyere.alexan...@gmail.com > > > > > > > > > > > wrote: > > > > > > > > > > > Hello. > > > > > > > > > > > > I'm currently investigating the functions of Cloudstack, and > looked > > > > into > > > > > > snapshots. > > > > > > > > > > > > As far as I can tell, the smallest possible interval for > snapshots > > is > > > > one > > > > > > hour. Is there a way to schedule them more frequently? For my > use, > > 5 > > > > > > minutes snapshots would be ideal. > > > > > > > > > > > > Also, it's limiting me to 8 snapshots kept. Is it possible to > keep > > a > > > > > larger > > > > > > number of them - whether it is by changing configurations, by > some > > > > other > > > > > > mechanic or any other way? > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Andrija Panić > > > > > > > > > > > > > > > -----Original Message----- > > > > > Re: Questions on snapshots > > > > > From: Andrija Panic <andrija.pa...@gmail.com> > > > > > To: users <users@cloudstack.apache.org> > > > > > Friday, October 26, 2018 at 3:38 PM > > > > > > > > > > > > > > > > > -- > > > > > > > > Andrija Panić > > > > > > > > > > > > > -- > > > > Andrija Panić > > > -- Andrija Panić
