On 07/24/2013 07:55 PM, Federico Simoncelli wrote:
----- 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"
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>,
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 
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 ?


it would use the gluster clone capability to offload the volume copy.

vdsm-devel mailing list

Reply via email to