Open Stack

Hi,
I did a design session on Friday though my proposal was to capture the
delta as qcow2. Here is the link to ether pad notes.

https://etherpad.openstack.org/p/juno-cinder-changed-block-list


Do you see synergies between what you are proposing and my proposal?
Shouldn¹t we standardize on one format for all backups? I believe Cinder
backup API currently uses JSON based list with pointers to all swift
objects that make up the backup data of a volume.

Regards,
Murali Balcha

On 5/18/14, 12:02 PM, "Mike Perez" <thingee at gmail.com> wrote:

>On 12:45 Mon 12 May     , Zhangleiqiang (Trump) wrote:
>> Hi, all:
>> 
>> 	I have planned to add the support to create qcow2 format file in NFS
>>driver ([1]). From the comment of Eric Harney, I know that cinder-backup
>>service currently assumes the volume is raw-formatted, and enable
>>creating qcow2 in NFS driver will break backups of NFS volumes .
>> 
>> 	After reading the code of backup service, I find we can first mount
>>the qcow2 volume as a NBD device and then pass the NBD device as the
>>"source volume_file" to backup service. Similar method of mounting qcow2
>>as NBD device has already used in Nova now. I think we can add it to NFS
>>driver for backup, and it can be used for GlusterFS too.
>> 
>> 	Any advice? Is there something I have not expected?
>
>This approach makes sense to me. Thanks for looking into this.
>
>-- 
>Mike Perez
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev