RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1375887 - volume xml's encryption info lost after pool refreshed
Summary: volume xml's encryption info lost after pool refreshed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: jiyan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-14 07:29 UTC by yisun
Modified: 2017-08-01 23:57 UTC (History)
7 users (show)

Fixed In Version: libvirt-2.5.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 17:16:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description yisun 2016-09-14 07:29:18 UTC 
Description of problem:
volume xml's encryption info lost after pool refreshed. 

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

How reproducible:
100%

Steps:
# /bin/virsh pool-create-as --name temp_pool --type dir --target /tmp/dir
Pool temp_pool created

# cat vol.xml 
<volume>
<name>temp_vol_0</name>
<capacity>104857600</capacity>
<allocation>52428800</allocation>
<target><format type="qcow2" />
<encryption format="default" />
</target>
</volume>

# /bin/virsh vol-create --pool temp_pool --file vol.xml 
Vol temp_vol_0 created from vol.xml

# virsh vol-dumpxml /tmp/dir/temp_vol_0 
<volume type='file'>
  <name>temp_vol_0</name>
  <key>/tmp/dir/temp_vol_0</key>
  <source>
  </source>
  <capacity unit='bytes'>104857600</capacity>
  <allocation unit='bytes'>200704</allocation>
  <target>
    <path>/tmp/dir/temp_vol_0</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:user_tmp_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1473165357.642969550</atime>
      <mtime>1473165357.615969146</mtime>
      <ctime>1473165357.642969550</ctime>
    </timestamps>
    <encryption format='qcow'>   <==== currently, the encryption part exists
      <secret type='passphrase' uuid='3dc1ea14-0eb4-4d8c-938d-5174f33d9b80'/>
    </encryption>
  </target>
</volume>


# virsh pool-refresh temp_pool
Pool temp_pool refreshed

<=== now the <encryption> part gone, as follow:
# virsh vol-dumpxml /tmp/dir/temp_vol_0 
<volume type='file'>
  <name>temp_vol_0</name>
  <key>/tmp/dir/temp_vol_0</key>
  <source>
  </source>
  <capacity unit='bytes'>104857600</capacity>
  <allocation unit='bytes'>200704</allocation>
  <target>
    <path>/tmp/dir/temp_vol_0</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:user_tmp_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1473165374.469221007</atime>
      <mtime>1473165357.615969146</mtime>
      <ctime>1473165357.642969550</ctime>
    </timestamps>
  </target>
</volume>

Actual results:
encryption xml lost after pool refreshed

Expected results:
encryption info still exist


Additional info:
 John Ferlan 2016-09-09 06:39:49 EDT

There's a patch upstream for the comment 25 issue, see:

http://www.redhat.com/archives/libvir-list/2016-September/msg00180.html

It's the 2/2 of the series, where the 1/2 modifies the code for a similar refresh issue for the LUKS volume:

http://www.redhat.com/archives/libvir-list/2016-September/msg00179.html

Both have the same caveat that the either the secret uses the 'uuid' for lookup or if the 'usage' is supplied, then it must be the path to the volume (as documented). While these patches are relatively simple, I'd be hard pressed to call them release blockers as they're "annoyances" in the volume display. Perhaps more likely for them to make a z-stream release...

As for the snapshot issue, seems like it has no chance of resolution by the end of September. It's not just a luks issue...

In order to make progress here though - I'd say just generate new bzs.
Comment 1 yisun 2016-09-14 07:29:52 UTC 
this is from https://bugzilla.redhat.com/show_bug.cgi?id=1301021#c21
Comment 2 John Ferlan 2016-09-14 19:27:51 UTC 
Patch was pushed :

$ git describe 2f6b750ecaff0e1d87e17d3a7c5a01218a527220
v2.2.0-68-g2f6b750

$ git show 2f6b750ecaff0e1d87e17d3a7c5a01218a527220
commit 2f6b750ecaff0e1d87e17d3a7c5a01218a527220
Author: John Ferlan <jferlan>
Date:   Tue Sep 6 17:00:30 2016 -0400

    storage: Need to properly read the crypt offset value
    
    Commit id 'a48c7141' altered how to determine if a volume was encrypted
    by adding a peek at an offset into the file at a specific buffer location.
    Unfortunately, all that was compared was the first "char" of the buffer
    against the expect "int" value.
    
    Restore the virReadBufInt32BE to get the complete field in order to
    compare against the expected value from the qcow2EncryptionInfo or
    qcow1EncryptionInfo "modeValue" field.
    
    This restores the capability to create a volume with encryption, then
    refresh the pool, and still find the encryption for the volume.
Comment 4 jiyan 2017-05-26 10:32:24 UTC 
Version-Release number of selected component:
kernel-3.10.0-671.el7.x86_64
qemu-kvm-rhev-2.9.0-6.el7.x86_64
libvirt-3.2.0-6.el7.x86_64


Steps to verify:
1:create volume through vol.xml and check the dumpxml file
# cat vol.xml 
<volume>
<name>test</name>
<capacity>104857600</capacity>
<allocation>52428800</allocation>
<target>
<format type="qcow2" />
<encryption format="default" />
</target>
</volume>

# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              active     yes 

# virsh vol-create --pool default --file vol.xml 
Vol test created from vol.xml

# virsh vol-dumpxml test --pool default
<volume type='file'>
  <name>test</name>
  <key>/var/lib/libvirt/images/test</key>
  <source>
  </source>
  <capacity unit='bytes'>104857600</capacity>
  <allocation unit='bytes'>200704</allocation>
  <physical unit='bytes'>196616</physical>
  <target>
    <path>/var/lib/libvirt/images/test</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1495706930.351323456</atime>
      <mtime>1495706930.349323456</mtime>
      <ctime>1495706930.350323456</ctime>
    </timestamps>
    <encryption format='qcow'>
      <secret type='passphrase' uuid='8ef116e4-cb77-4442-9f55-a361b2c7d402'/>
    </encryption>
  </target>
</volume>

2:refresh the pool and check the volume dumpxml file again
# virsh pool-refresh default
Pool default refreshed

# virsh vol-dumpxml test --pool default
<volume type='file'>
  <name>test</name>
  <key>/var/lib/libvirt/images/test</key>
  <source>
  </source>
  <capacity unit='bytes'>104857600</capacity>
  <allocation unit='bytes'>200704</allocation>
  <physical unit='bytes'>196616</physical>
  <target>
    <path>/var/lib/libvirt/images/test</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0600</mode>
      <owner>0</owner>
      <group>0</group>
      <label>system_u:object_r:virt_image_t:s0</label>
    </permissions>
    <timestamps>
      <atime>1495706930.351323456</atime>
      <mtime>1495706930.349323456</mtime>
      <ctime>1495706930.350323456</ctime>
    </timestamps>
    <encryption format='qcow'>
      <secret type='passphrase' uuid='8ef116e4-cb77-4442-9f55-a361b2c7d402'/>
    </encryption>
  </target>
</volume>
Comment 5 errata-xmlrpc 2017-08-01 17:16:43 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://access.redhat.com/errata/RHEA-2017:1846
Comment 6 errata-xmlrpc 2017-08-01 23:57: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://access.redhat.com/errata/RHEA-2017:1846
Note You need to log in before you can comment on or make changes to this bug.