Re: [vdsm] Exploiting domain specific offload features
On 07/24/2013 07:55 PM, Federico Simoncelli wrote: - Original Message - From: "Federico Simoncelli" To: "Itamar Heim" Cc: "Deepak C Shetty" , vdsm-devel@lists.fedorahosted.org, "Ayal Baron" Sent: Wednesday, July 24, 2013 4:22:02 PM Subject: Re: [vdsm] Exploiting domain specific offload features - Original Message - From: "Itamar Heim" To: "Federico Simoncelli" Cc: "Deepak C Shetty" , vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 24, 2013 3:35:35 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/24/2013 03:38 PM, Federico Simoncelli wrote: I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=>raw, cow=>cow). you still need to tailor the flow from engine's perspective, right? or just override the entity created by the engine with the native cloned one for simplicity? No, this change would be transparent to the engine. When vdsm is asked to clone/copy an image (eg. iirc create a non-thin-provisioned vm from template) Maybe in this case we use an hard-link (no time to check now). Anyway concept is that if we ever need to copy a volume within the same storage domain, that can be offloaded to gluster. I am not sure if its clear, but wanted to stress that when Gluster provides the clone/snapshot offloads.. the new files (which map to LVs as Gluster is configured with block backend) will be seen as normal files on the Gluster mount (aka Gluster storage domain). But VDSM expects the snapshot to appear as base <-- qcow2 in the FS domain, which won't happen in this case. Will something break in engine/VDSM assumptions and/or flows when this happens ? thanx, deepak it would use the gluster clone capability to offload the volume copy. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - > From: "Federico Simoncelli" > To: "Itamar Heim" > Cc: "Deepak C Shetty" , > vdsm-devel@lists.fedorahosted.org, "Ayal Baron" > > Sent: Wednesday, July 24, 2013 4:22:02 PM > Subject: Re: [vdsm] Exploiting domain specific offload features > - Original Message - > > From: "Itamar Heim" > > To: "Federico Simoncelli" > > Cc: "Deepak C Shetty" , > > vdsm-devel@lists.fedorahosted.org > > Sent: Wednesday, July 24, 2013 3:35:35 PM > > Subject: Re: [vdsm] Exploiting domain specific offload features > > > > On 07/24/2013 03:38 PM, Federico Simoncelli wrote: > > > I think we can already start exploiting cloning whenever we need to copy > > > a volume maintaining the same format (raw=>raw, cow=>cow). > > > > > > > you still need to tailor the flow from engine's perspective, right? > > or just override the entity created by the engine with the native cloned > > one for simplicity? > > No, this change would be transparent to the engine. When vdsm is asked to > clone/copy an image (eg. iirc create a non-thin-provisioned vm from template) Maybe in this case we use an hard-link (no time to check now). Anyway concept is that if we ever need to copy a volume within the same storage domain, that can be offloaded to gluster. > it would use the gluster clone capability to offload the volume copy. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - > From: "Itamar Heim" > To: "Federico Simoncelli" > Cc: "Deepak C Shetty" , > vdsm-devel@lists.fedorahosted.org > Sent: Wednesday, July 24, 2013 3:35:35 PM > Subject: Re: [vdsm] Exploiting domain specific offload features > > On 07/24/2013 03:38 PM, Federico Simoncelli wrote: > > > > > > - Original Message - > >> From: "Deepak C Shetty" > >> To: vdsm-devel@lists.fedorahosted.org > >> Sent: Wednesday, July 17, 2013 12:08:03 PM > >> Subject: Re: [vdsm] Exploiting domain specific offload features > >> > >> On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: > >>> Hello, > >>> > >>> We are adding features such as server offloaded cloning, snapshot of > >>> the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of > >>> now only BD xlator supports offloaded cloning & snapshot. Server > >>> offloaded zeroing of VM disks is supported both by posix and BD xlator. > >>> The initial approach is to use xattr interface to trigger this offload > >>> features such as > >>> # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file > >>> will create clone of path-to-source-file in path-to-new-clone-file. > >>> Cloning is done in GlusterFS server side and its kind of server > >>> offloaded copy. Similarly snapshot can also be taken using setfattr > >>> approach. > >>> > >>> GlusterFS storage domain is already part of VDSM and we want to exploit > >>> offload features provided by GlusterFS through VDSM. Is there any way to > >>> exploit these features from VDSM as of now? > >> > >> Mohan, > >> IIUC, zeroing of files in GlusterFS is supported for both posix and > >> block backends of GlusterFS > >> Today VDSM does zeroing (as part of preallocated vmdisk flow) itself > >> using 'dd'. If GlusterFS supports > >> zeroing this feature can be exploited in VDSM (by overriding create > >> volume flow as needed) so that we can save > >> compute resources on the VDSM host, when Gluster domain is being used. > >> > >> Regarding exploiting clone and snapshot, IIUC these are very native > >> to VDSM today... it expects that snapshots are qcow2 based and they form > >> the image chain etc... With snapshot and clone handled in Gluster > >> transparently, these > >> notions of VDSM will be broken, so it probably needs a lot of changes in > >> lots of places in VDSM to exploit these. > >> > >> Federico/Ayal, > >> Wanted to know your comments/opinion on this ? > >> Is there a way to exploit these features in VDSM Gluster storage domain > >> in an elegant way ? > > > > I think we can already start exploiting cloning whenever we need to copy > > a volume maintaining the same format (raw=>raw, cow=>cow). > > > > you still need to tailor the flow from engine's perspective, right? > or just override the entity created by the engine with the native cloned > one for simplicity? No, this change would be transparent to the engine. When vdsm is asked to clone/copy an image (eg. iirc create a non-thin-provisioned vm from template) it would use the gluster clone capability to offload the volume copy. -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
On 07/24/2013 03:38 PM, Federico Simoncelli wrote: - Original Message - From: "Deepak C Shetty" To: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 17, 2013 12:08:03 PM Subject: Re: [vdsm] Exploiting domain specific offload features On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning & snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now? Mohan, IIUC, zeroing of files in GlusterFS is supported for both posix and block backends of GlusterFS Today VDSM does zeroing (as part of preallocated vmdisk flow) itself using 'dd'. If GlusterFS supports zeroing this feature can be exploited in VDSM (by overriding create volume flow as needed) so that we can save compute resources on the VDSM host, when Gluster domain is being used. Regarding exploiting clone and snapshot, IIUC these are very native to VDSM today... it expects that snapshots are qcow2 based and they form the image chain etc... With snapshot and clone handled in Gluster transparently, these notions of VDSM will be broken, so it probably needs a lot of changes in lots of places in VDSM to exploit these. Federico/Ayal, Wanted to know your comments/opinion on this ? Is there a way to exploit these features in VDSM Gluster storage domain in an elegant way ? I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=>raw, cow=>cow). you still need to tailor the flow from engine's perspective, right? or just override the entity created by the engine with the native cloned one for simplicity? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
- Original Message - > From: "Deepak C Shetty" > To: vdsm-devel@lists.fedorahosted.org > Sent: Wednesday, July 17, 2013 12:08:03 PM > Subject: Re: [vdsm] Exploiting domain specific offload features > > On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: > > Hello, > > > > We are adding features such as server offloaded cloning, snapshot of > > the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of > > now only BD xlator supports offloaded cloning & snapshot. Server > > offloaded zeroing of VM disks is supported both by posix and BD xlator. > > The initial approach is to use xattr interface to trigger this offload > > features such as > > # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file > > will create clone of path-to-source-file in path-to-new-clone-file. > > Cloning is done in GlusterFS server side and its kind of server > > offloaded copy. Similarly snapshot can also be taken using setfattr > > approach. > > > > GlusterFS storage domain is already part of VDSM and we want to exploit > > offload features provided by GlusterFS through VDSM. Is there any way to > > exploit these features from VDSM as of now? > > Mohan, > IIUC, zeroing of files in GlusterFS is supported for both posix and > block backends of GlusterFS > Today VDSM does zeroing (as part of preallocated vmdisk flow) itself > using 'dd'. If GlusterFS supports > zeroing this feature can be exploited in VDSM (by overriding create > volume flow as needed) so that we can save > compute resources on the VDSM host, when Gluster domain is being used. > > Regarding exploiting clone and snapshot, IIUC these are very native > to VDSM today... it expects that snapshots are qcow2 based and they form > the image chain etc... With snapshot and clone handled in Gluster > transparently, these > notions of VDSM will be broken, so it probably needs a lot of changes in > lots of places in VDSM to exploit these. > > Federico/Ayal, > Wanted to know your comments/opinion on this ? > Is there a way to exploit these features in VDSM Gluster storage domain > in an elegant way ? I think we can already start exploiting cloning whenever we need to copy a volume maintaining the same format (raw=>raw, cow=>cow). -- Federico ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Exploiting domain specific offload features
On 07/17/2013 12:48 PM, M. Mohan Kumar wrote: Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning & snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now? Mohan, IIUC, zeroing of files in GlusterFS is supported for both posix and block backends of GlusterFS Today VDSM does zeroing (as part of preallocated vmdisk flow) itself using 'dd'. If GlusterFS supports zeroing this feature can be exploited in VDSM (by overriding create volume flow as needed) so that we can save compute resources on the VDSM host, when Gluster domain is being used. Regarding exploiting clone and snapshot, IIUC these are very native to VDSM today... it expects that snapshots are qcow2 based and they form the image chain etc... With snapshot and clone handled in Gluster transparently, these notions of VDSM will be broken, so it probably needs a lot of changes in lots of places in VDSM to exploit these. Federico/Ayal, Wanted to know your comments/opinion on this ? Is there a way to exploit these features in VDSM Gluster storage domain in an elegant way ? thanx, deepak ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Exploiting domain specific offload features
Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning & snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
