#qemu-img rebase -b  /opt/cloud_backend/base/ubuntu.img  /opt/cloud_backend/instances/c1322944-9d1c-11e3-bda8-485b39433121/root

类似命令出现如题问题。

在网上找到的一段话可以解释：

'''

rebase [-f fmt] [-t cache] [-p] [-u] -b backing_file [-F backing_fmt] filename

改变镜像文件的后端镜像文件，只有qcow2和qed格式支持rebase命令。使用“-b backing_file”中指定的文件作为后端镜像，后端镜像也被转化为“-F backing_fmt”中指定的后端镜像格式。

它可以工作于两种模式之下，一种是安全模式（Safe Mode）也是默认的模式，qemu-img会去比较原来的后端镜像与现在的后端镜像的不同进行合理的处理；另一种是非安全模式（Unsafe Mode），是通过“-u”参数来指定的，这种模式主要用于将后端镜像进行了重命名或者移动了位置之后对前端镜像文件的修复处理，由用户去保证后端镜像的一致性。

'''*

# qemu-img info /opt/cloud_backend/instances/01b1e090-9dc2-11e3-bda8-485b39433121/root 

image: /opt/cloud_backend/instances/01b1e090-9dc2-11e3-bda8-485b39433121/root

file format: qcow2

virtual size: 40G (42949672960 bytes)

disk size: 196K

cluster_size: 65536

backing file: ../../base/ubuntu.img (actual path: /opt/cloud_backend/instances/01b1e090-9dc2-11e3-bda8-485b39433121/../../base/ubuntu.img)

以此为例，后端镜像即backing file。

经测试，若修改后的后端镜像文件与原后端文件在同一目录下，并且在上例中的image所在目录（即/opt/cloud_backend/instances/01b1e090-9dc2-11e3-bda8-485b39433121）中执行命令，则不会出现问题；否则报错‘qemu-img: Could not open old backing file...’。

在不改路径的情况下，解决也很简单，加上参数-u：

#qemu-img rebase -u -b  /opt/cloud_backend/base/ubuntu.img  /opt/cloud_backend/instances/c1322944-9d1c-11e3-bda8-485b39433121/root

PS：在测试中，非安全模式执行时，调用libvirt执行其它命令，绝大部分都会卡住；而安全模式下，出现这种情况的机率少得多

*参考来源：

版权声明：本文为博主原创文章，未经博主允许不得转载。