[openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers

Trump.Zhang zhangleiqiang at gmail.com
Mon Jun 23 15:07:10 UTC 2014

Hi, all:

    Currently, there are several filesystem-based drivers in Cinder, such
as nfs, glusterfs, etc. Multiple format of volume other than "raw" can be
potentially supported in these drivers, such as qcow2, raw, sparse, etc.

    However, Cinder does not store the actual format of volume and suppose
all volumes are "raw" format. It will has or already has several problems
as follows:

    1. For volume migration, the generic migration implementation in Cinder
uses the "dd" command to copy "src" volume to "dest" volume. If the src
volume is "qcow2" format, instance will not get the right data from volume
after the dest volume attached to instance, because the info returned from
Cinder states that the volume's format is "raw" other than "qcow2"
    2. For volume backup, the backup driver also supposes that src volumes
are "raw" format, other format will not be supported

    Indeed, glusterfs driver has used "qemu-img info" command to judge the
format of volume. However, as the comment from Duncan in [1] says, this
auto detection method has many possible error / exploit vectors. Because if
the beginning content of a "raw" volume happens to a "qcow2" disk, auto
detection method will judge this volume to be a "qcow2" volume wrongly.

    I proposed that the "format" info should be added to "admin_metadata"
of volumes, and enforce it on all operations, such as create, copy, migrate
and retype. The "format" will be only set / updated for filesystem-based
drivers,  other drivers will not contains this metadata and have a default
"raw" format.

    Any advice?

[1] https://review.openstack.org/#/c/100529/

Best Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140623/0f7836ae/attachment.html>

More information about the OpenStack-dev mailing list