Bug 1371749

Summary: virsh migrate --copy-storage-all genrates a qcow2v2 image on target even if qcow2v3 image is used on source
Product: Red Hat Enterprise Linux 7 Reporter: Yang Yang <yanyang>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED NOTABUG QA Contact: zhe peng <zpeng>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: dyuan, dzheng, fjin, rbalakri, xuzhang, yafu, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-25 08:48:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Yang Yang 2016-08-31 02:28:44 UTC
Description of problem:
I have a running vm using qcow2v3 image on source host. I migrate vm
with copy-storage-all flag. After migration, libvirt generates a qcow2v2 image
on target host.

Version-Release number of selected component (if applicable):
on both source and target:
libvirt-2.0.0-6.el7.x86_64
qemu-kvm-rhev-2.6.0-22.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1. start vm with qcow2v3 image on source

# qemu-img info /var/lib/libvirt/images/RHEL-7.3-latest.qcow2
image: /var/lib/libvirt/images/RHEL-7.3-latest.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 1.3G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' io='threads' ioeventfd='on' event_idx='off' detect_zeroes='on'/>
      <source file='/var/lib/libvirt/images/RHEL-7.3-latest.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </disk>

# virsh start vm-mig
Domain vm-mig started

2. migrate vm with copy-storage-all flag
# virsh migrate vm-mig qemu+ssh://hp-dl385g7-05.lab.eng.pek2.redhat.com/system --verbose --live --unsafe --copy-storage-all
root.eng.pek2.redhat.com's password:
Migration: [100 %]

3. check image on target
# qemu-img info /var/lib/libvirt/images/RHEL-7.3-latest.qcow2
image: /var/lib/libvirt/images/RHEL-7.3-latest.qcow2
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 5.0G
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16


Actual result:
virsh migrate --copy-storage-all genrates a qcow2v2 image on target even if qcow2v3 image is used on source

Expected result:
Images on both source and target should keep identical

Additional info:
Addressed libvirtd.log on target host:

2016-08-30 04:43:03.597+0000: 1744: debug : qemuMigrationPrecreateStorage:1687 : Looking up disk target 'vda' (capacity=5368709120)
2016-08-30 04:43:03.598+0000: 1744: debug : qemuMigrationPrecreateStorage:1712 : Proceeding with disk source /var/lib/libvirt/images/RHEL-7.3-latest.qcow2
2016-08-30 04:43:03.598+0000: 1744: debug : qemuMigrationPrecreateDisk:1553 : Precreate disk type=file
2016-08-30 04:43:03.598+0000: 1744: info : virObjectNew:202 : OBJECT_NEW: obj=0x7f7be000e420 classname=virStoragePool
2016-08-30 04:43:03.598+0000: 1744: info : virObjectRef:296 : OBJECT_REF: obj=0x7f7bdc001870
2016-08-30 04:43:03.598+0000: 1744: debug : virStorageVolLookupByName:1293 : pool=0x7f7be000e420, name=RHEL-7.3-latest.qcow2
2016-08-30 04:43:03.598+0000: 1744: debug : storageVolLookupByName:1528 : Storage volume not found: no storage vol with matching name 'RHEL-7.3-latest.qcow2'
2016-08-30 04:43:03.598+0000: 1744: debug : virStorageVolCreateXML:1466 : pool=0x7f7be000e420, xmlDesc=<volume>
  <name>RHEL-7.3-latest.qcow2</name>
  <capacity>5368709120</capacity>
  <target>
    <format type='qcow2'/>
  </target>
</volume>
, flags=1
2016-08-30 04:43:03.624+0000: 1744: debug : virCommandRunAsync:2429 : About to run /usr/local/bin/qemu-img create -f qcow2 -o preallocation=metadata,compat=0.10 /var/lib/libvirt/images/RHEL-7.3-latest.qcow2 5242880K
2016-08-30 04:43:03.626+0000: 1744: debug : virFileClose:102 : Closed fd 26
2016-08-30 04:43:03.626+0000: 1744: debug : virFileClose:102 : Closed fd 29
2016-08-30 04:43:03.627+0000: 1744: debug : virFileClose:102 : Closed fd 31
2016-08-30 04:43:03.627+0000: 1744: debug : virCommandRunAsync:2432 : Command result 0, with PID 14872
2016-08-30 04:43:03.760+0000: 1744: debug : virCommandRun:2280 : Result status 0, stdout: 'Formatting '/var/lib/libvirt/images/RHEL-7.3-latest.qcow2', fmt=qcow2 size=5368709120 compat=0.10 encryption=off cluster_size=65536 preallocation=metadata lazy_refcounts=off refcount_bits=16
' stderr: '2016-08-30 04:43:03.633+0000: 14872: debug : virFileClose:102 : Closed fd 29
2016-08-30 04:43:03.633+0000: 14872: debug : virFileClose:102 : Closed fd 31
2016-08-30 04:43:03.633+0000: 14872: debug : virFileClose:102 : Closed fd 26
'
2016-08-30 04:43:03.760+0000: 1744: debug : virFileClose:102 : Closed fd 27
2016-08-30 04:43:03.760+0000: 1744: debug : virFileClose:102 : Closed fd 30
2016-08-30 04:43:03.762+0000: 1744: debug : virStorageFileGetMetadataInternal:937 : path=/var/lib/libvirt/images/RHEL-7.3-latest.qcow2, buf=0x7f7be0017ac0, len=33280, meta->format=14
2016-08-30 04:43:03.762+0000: 1744: info : storageVolCreateXML:1996 : Creating volume 'RHEL-7.3-latest.qcow2' in storage pool 'default'
2016-08-30 04:43:03.762+0000: 1744: info : virObjectUnref:259 : OBJECT_UNREF: obj=0x7f7be00177c0
2016-08-30 04:43:03.762+0000: 1744: info : virObjectUnref:261 : OBJECT_DISPOSE: obj=0x7f7be00177c0
2016-08-30 04:43:03.762+0000: 1744: debug : virStorageVolDispose:589 : release vol 0x7f7be00177c0 RHEL-7.3-latest.qcow2

Comment 3 Michal Privoznik 2017-04-12 08:30:31 UTC
Now that I'm thinking about this, is this really a problem? I mean, with storage migration the whole backing chain is flattened, so different compat version is the least problem. Therefore I'm inclined to close this. Any objections?

Comment 4 Michal Privoznik 2017-04-25 08:48:36 UTC
Okay. I'm closing this one. If somebody feel otherwise, please feel free to reopen and state why this matters.