Bug 1375887
| Summary: | volume xml's encryption info lost after pool refreshed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | yisun |
| Component: | libvirt | Assignee: | John Ferlan <jferlan> |
| Status: | CLOSED ERRATA | QA Contact: | jiyan <jiyan> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.4 | CC: | dyuan, jdenemar, jferlan, lmen, rbalakri, xuzhang, yanyang |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-2.5.0-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 17:16:43 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: | |||
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.
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>
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 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 |
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.