Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup
On 18 May 2014 12:32, Murali Balcha murali.bal...@triliodata.com wrote: 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. I think the problem being referred to in this thread is that the backup code assumes the *source* is a raw volume. The destination (i.e. swift) should absolutely remain universal across all volume back-ends - a JSON list with pointers. The JSON file is versioned, so there is scope to add more to it (like we did volume metadata), but I don't want to see QCOW or similar going into swift. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup
I think the problem being referred to in this thread is that the backup code assumes the *source* is a raw volume. The destination (i.e. swift) should absolutely remain universal across all volume back-ends - a JSON list with pointers. The JSON file is versioned, so there is scope to add more to it (like we did volume metadata), but I don't want to see QCOW or similar going into swift. I agreed with Duncan. I will finish the spec for it within the next few days. -- zhangleiqiang (Trump) Best Regards -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Wednesday, May 28, 2014 9:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup On 18 May 2014 12:32, Murali Balcha murali.bal...@triliodata.com wrote: 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. I think the problem being referred to in this thread is that the backup code assumes the *source* is a raw volume. The destination (i.e. swift) should absolutely remain universal across all volume back-ends - a JSON list with pointers. The JSON file is versioned, so there is scope to add more to it (like we did volume metadata), but I don't want to see QCOW or similar going into swift. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Qcow2 support for cinder-backup
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] Qcow2 support for cinder-backup
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? [1] https://review.openstack.org/#/c/92011/ -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
