<div dir="ltr"><div>Hi, all:</div><div><br></div><div>    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.</div>
<div>    </div><div>    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:</div><div>    </div><div>    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"</div>
<div>    2. For volume backup, the backup driver also supposes that src volumes are "raw" format, other format will not be supported</div><div>    </div><div>    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.</div>
<div>    </div><div>    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.</div>
<div>    </div><div>    Any advice?</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/100529/">https://review.openstack.org/#/c/100529/</a></div><div><br></div>-- <br><div dir="ltr">-------------------<div>
Best Regards</div><div><br></div><div>Trump.Zhang</div></div>
</div>