Hide Forgot
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.
this is from https://bugzilla.redhat.com/show_bug.cgi?id=1301021#c21
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