Bug 1185165

Summary: qcow volume encryption element gone after refresh pool
Product: Red Hat Enterprise Linux 7 Reporter: yanbing du <ydu>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: dyuan, jtomko, mzhan, rbalakri, yanyang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-1.2.13-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 06:08:38 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:

Description yanbing du 2015-01-23 05:59:45 UTC
Description of problem:
Create a 'qcow' format volume with encryption, then refresh the pool, the new created encryption element in volume XML will gone.
BTW, for 'qocw2' format, there's no problem. 

Version-Release number of selected component (if applicable):
libvirt-1.2.8-15.el7.x86_64

How reproducible:
100% 

Steps to Reproduce:
1.# virsh vol-create default /tmp/encrypt_vol.xml
Vol vol2 created from /tmp/encrypt_vol.xml

# cat /tmp/encrypt_vol.xml
<volume>
    <name>vol2</name>
    <target>
        <format type="qcow" />
        <encryption format="default" />
    </target>
    <capacity>1048576</capacity>
    <allocation>1048576</allocation>
</volume>

# virsh vol-dumpxml vol2 default
<volume type='file'>
  <name>vol2</name>
  <key>/var/lib/libvirt/images/vol2</key>
  <source>
  </source>
  <capacity unit='bytes'>1048576</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol2</path>
    <format type='qcow'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1421913782.961073448</atime>
      <mtime>1421913782.961073448</mtime>
      <ctime>1421913782.990073353</ctime>
    </timestamps>
    <encryption format='qcow'>
      <secret type='passphrase' uuid='c8959746-c442-48b5-8b8c-0d394d5f7f1c'/>
    </encryption>
  </target>
</volume>

# virsh pool-refresh default
Pool default refreshed

# virsh vol-dumpxml vol2 default
<volume type='file'>
  <name>vol2</name>
  <key>/var/lib/libvirt/images/vol2</key>
  <source>
  </source>
  <capacity unit='bytes'>1048576</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol2</path>
    <format type='qcow'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1421913793.043040089</atime>
      <mtime>1421913782.961073448</mtime>
      <ctime>1421913782.990073353</ctime>
    </timestamps>
  </target>
</volume>

2.
3.

Actual results:
The <encryption> element part disappeared after refresh pool 

Expected results:
The <encryption> element part still exist after refresh pool

Additional info:

Comment 2 Ján Tomko 2015-01-23 13:12:10 UTC
Upstream patch:
https://www.redhat.com/archives/libvir-list/2015-January/msg00912.html

Comment 3 Ján Tomko 2015-01-26 15:55:08 UTC
Fixed upstream by:
commit 495accb047fe85dd17f181c2a19b34fd84ed89f5
Author:     Ján Tomko <jtomko>
AuthorDate: 2015-01-23 13:29:48 +0100
Commit:     Ján Tomko <jtomko>
CommitDate: 2015-01-26 16:13:02 +0100

    Use correct location for qcow1 encryption header
    
    After the 8-byte size header, there are two one-byte headers
    and two bytes of padding before the crypt_header field.
    
    Our QCOW1_HDR_CRYPT constant did not skip the padding.
    http://git.qemu.org/?p=qemu.git;a=blob;f=block/qcow.c;h=ece22697#l41
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1185165

git describe: v1.2.12-rc2-3-g495accb

Comment 4 Yang Yang 2015-04-29 06:16:02 UTC
Verified on libvirt-1.2.14-1.el7.x86_64

# cat encrypt_vol.xml 
<volume>
    <name>BZ1185165</name>
    <target>
        <format type="qcow" />
        <encryption format="default" />
    </target>
    <capacity>1048576</capacity>
    <allocation>1048576</allocation>
</volume>

# virsh vol-create default encrypt_vol.xml 
Vol BZ1185165 created from encrypt_vol.xml

# virsh vol-dumpxml BZ1185165 default
<volume type='file'>
  <name>BZ1185165</name>
  <key>/var/lib/libvirt/images/BZ1185165</key>
  <source>
  </source>
  <capacity unit='bytes'>1048576</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/BZ1185165</path>
    <format type='qcow'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1430287892.598787017</atime>
      <mtime>1430287892.580787005</mtime>
      <ctime>1430287892.597787016</ctime>
    </timestamps>
    <encryption format='qcow'>
      <secret type='passphrase' uuid='3038ed40-163d-44c4-beb4-516514bea20a'/>
    </encryption>
  </target>
</volume>

# virsh pool-refresh default
Pool default refreshed

# virsh vol-dumpxml BZ1185165 default
<volume type='file'>
  <name>BZ1185165</name>
  <key>/var/lib/libvirt/images/BZ1185165</key>
  <source>
  </source>
  <capacity unit='bytes'>1048576</capacity>
  <allocation unit='bytes'>4096</allocation>
  <target>
    <path>/var/lib/libvirt/images/BZ1185165</path>
    <format type='qcow'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1430287892.598787017</atime>
      <mtime>1430287892.580787005</mtime>
      <ctime>1430287892.597787016</ctime>
    </timestamps>
    <encryption format='qcow'>
      <secret type='passphrase' uuid='3038ed40-163d-44c4-beb4-516514bea20a'/>
    </encryption>
  </target>
</volume>

Comment 6 Yang Yang 2015-05-14 10:19:20 UTC
Set it to verified status according to comment #4

Comment 8 errata-xmlrpc 2015-11-19 06:08:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html