[vdsm] Linking to bugs from oVirt wiki
Hi guys,
Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I
cooeked up a quick template to help adding Bugzilla links.
You can just use {BZ|number} in your wiki markup, and you'll get a
user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will
create a link to http://bugzilla.redhat.com/123).
Enjoy,
Allon
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Linking to bugs from oVirt wiki
- Original Message -
From: Allon Mureinik amure...@redhat.com
To: engine-devel engine-de...@ovirt.org, vdsm-devel@lists.fedorahosted.org
Sent: Wednesday, July 24, 2013 2:54:44 PM
Subject: Linking to bugs from oVirt wiki
Hi guys,
Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I
cooeked up a quick template to help adding Bugzilla links.
You can just use {BZ|number} in your wiki markup, and you'll get a
{{BZ|number}} of course.
Thanks Alissa for pointing this out. ;-)
user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will
create a link to http://bugzilla.redhat.com/123).
Enjoy,
Allon
___
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 deepa...@linux.vnet.ibm.com 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/24/2013 03:38 PM, Federico Simoncelli wrote: - Original Message - From: Deepak C Shetty deepa...@linux.vnet.ibm.com 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: Itamar Heim ih...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, 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 deepa...@linux.vnet.ibm.com 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
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Itamar Heim ih...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, vdsm-devel@lists.fedorahosted.org, Ayal Baron aba...@redhat.com Sent: Wednesday, July 24, 2013 4:22:02 PM Subject: Re: [vdsm] Exploiting domain specific offload features - Original Message - From: Itamar Heim ih...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Deepak C Shetty deepa...@linux.vnet.ibm.com, 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
