[openstack-dev] [Cinder] Cloning vs copying images

Avishay Traeger AVISHAY at il.ibm.com
Tue Dec 3 07:08:00 UTC 2013

You are correct.  I made the same comment on the review before seeing this 
thread.  Let's see how both patches turn out and we'll choose one. :)


From:   Dmitry Borodaenko <dborodaenko at mirantis.com>
To:     openstack-dev at lists.openstack.org, 
Date:   12/02/2013 09:32 PM
Subject:        [openstack-dev] [Cinder] Cloning vs copying images

Hi OpenStack, particularly Cinder backend developers,

Please consider the following two competing fixes for the same problem:


The problem being fixed is that some backends, specifically Ceph RBD,
can only boot from volumes created from images in a certain format, in
RBD's case, RAW. When an image in a different format gets cloned into
a volume, it cannot be booted from. Obvious solution is to refuse
clone operation and copy/convert the image instead.

And now the principal question: is it safe to assume that this
restriction applies to all backends? Should the fix enforce copy of
non-RAW images for all backends? Or should the decision whether to
clone or copy the image be made in each backend?

The first fix puts this logic into the RBD backend, and makes changes
necessary for all other backends to have enough information to make a
similar decision if necessary. The problem with this approach is that
it's relatively intrusive, because driver clone_image() method
signature has to be changed.

The second fix has significantly less code changes, but it does
prevent cloning non-RAW images for all backends. I am not sure if this
is a real problem or not.

Can anyone point at a backend that can boot from a volume cloned from
a non-RAW image? I can think of one candidate: GPFS is a file-based
backend, while GPFS has a file clone operation. Is GPFS backend able
to boot from, say, a QCOW2 volume?


Dmitry Borodaenko

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list