Alright, I do remember that thread. I was just considering upgrading some of the ways CLVM handles snapshots/backups and wanted to do it in a way that was consistent with the way we're doing VHD or QCOW2 going forward, but it sounds like there's probably not much I can do now without having to rework it again when the storage refactor happens to see what that looks like.
On Thu, Nov 8, 2012 at 10:41 AM, Clayton Weise <cwe...@iswest.net> wrote: > >Imho snapshots should be handled by a plugin. So on a Snapshots aware > >SAN we should try to use the build in snapshots capabilities of that SAN > >instead of doing it ourself. > > This can considerably change the way storage is handled with XenServer and > iSCSI/FC since right now one SR is equivalent to a single LUN on your > storage array but that SR can contain many different volumes for VMs. In > order to take advantage of snapshots on the array you would need to create > a separate SR for each volume (somebody feel free to correct me if I'm > wrong here) since the array wouldn't know about the individual volumes/LVMs > inside of the SR. With NFS it's easier because it's all just files, but > block storage is different and can vary greatly in behavior from one HV to > another. > > -----Original Message----- > From: Wido den Hollander [mailto:w...@widodh.nl] > Sent: Thursday, November 8, 2012 3:50 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: snapshot vs backup > > > > On 07-11-12 18:13, Marcus Sorensen wrote: > > I believe I saw this discussed once somewhere, but at the moment > snapshots > > are basically backups, correct? You'll have to forgive my ignorance if I > > don't understand how it works on all platforms/storage types. > > > > Edison brought this up with a storage refactor. > > > So moving forward are we renaming everything that's snapshot to backup > > (since it works great for that as-is) and implementing a new snapshot, or > > splitting the existing snapshot functionality into taking the actual > > snapshot vs copying it to secondary storage (backup), or leaving snapshot > > as-is and implementing some flag or something else that allows for both > the > > existing backup functionality as well as an instant cow style backup? > > > > Imho snapshots should be handled by a plugin. So on a Snapshots aware > SAN we should try to use the build in snapshots capabilities of that SAN > instead of doing it ourself. > > Same goes for RBD, QCOW2, etc, etc. > > Backups should be different indeed, still handled differently for > different storage backends just to prevent we are working against the > storage backend while it could have awesome features for this. > > In the end a backup should end up at the Secondary Storage. > > Still, this is something that needs to go into the Storage Layer > refactor and we need to have this written down. > > This thread covers a lot of it: "Requirements of Storage Orchestration" > from over a week ago. > > Wido >
