Bug 1233003
Summary: | Manually created LVM is deleted by virsh vol-create-as if it is having the same name | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Yang Yang <yanyang> |
Component: | libvirt | Assignee: | John Ferlan <jferlan> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | cww, dyuan, jferlan, mzhan, rbalakri, xuzhang, yanyang, yisun |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.3.1-1.el7 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | 1232170 | Environment: | |
Last Closed: | 2016-11-03 18:18:57 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: | |||
Bug Depends On: | 1232170 | ||
Bug Blocks: | 1203710 |
Comment 2
Yang Yang
2015-06-18 06:38:24 UTC
I don't believe this is a bug. You're taking "knowledge" of how libvirt does something in order to "go behind libvirt's back" and create something. Then you decide to go back to using libvirt to manage the data in the pool. Since you decided to use the same name, you now expect libvirt to manage that name. That name failed (because of subterfuge), so libvirt handles the error by removing the volume that "a" it didn't know about originally and "b" caused some sort of issue. Seems to me that's an "expected reaction" to a "unexpected condition". Either you choose to have libvirt manage your storage or you choose not to. Going with some sort of hybrid model just cannot be "supported". Consider a 5G pool with 2G taken... You go and add a 3G volume outside of libvirt's knowledge, you don't refresh, and then attempt to use libvirt to create a 3G volume - it's going to fail, but libvirt won't know that until you refresh and libvirt "learns" about the existence of something it didn't know about or create and can adjust it's view of the space available in the pool. (In reply to John Ferlan from comment #3) > I don't believe this is a bug. You're taking "knowledge" of how libvirt does > something in order to "go behind libvirt's back" and create something. Then > you decide to go back to using libvirt to manage the data in the pool. > Since you decided to use the same name, you now expect libvirt to manage > that name. That name failed (because of subterfuge), so libvirt handles the > error by removing the volume that "a" it didn't know about originally and > "b" caused some sort of issue. Seems to me that's an "expected reaction" to > a "unexpected condition". Um.. I think libvirt should avoid damaging existing available volume. How about doing a RefreshPool to get all logical volumes before CreateVol > > Either you choose to have libvirt manage your storage or you choose not to. > Going with some sort of hybrid model just cannot be "supported". Consider a > 5G pool with 2G taken... You go and add a 3G volume outside of libvirt's > knowledge, you don't refresh, and then attempt to use libvirt to create a 3G > volume - it's going to fail, but libvirt won't know that until you refresh > and libvirt "learns" about the existence of something it didn't know about > or create and can adjust it's view of the space available in the pool. I disagree still. Expecting libvirt to do a refresh before a create in order to work around a self inflicted issue? It could just as easily be stated that if an admin attempts to manage storage outside of libvirt's knowledge, then that same admin should cause the refresh themselves in order to "teach" or "tell" libvirt what they did. Now if libvirt had the ability to subscribe and process some sort of event from a file system or external storage server when adjustments were made "out of band" to the storage libvirt felt it was managing perhaps that might work, but that would require each of the storage targets that libvirt can manage to be able to generate the event and then libvirt to handle processing events for adjustment it recognizes or initiated versus those that were initiated by some action external to libvirt. Even though I'm still of the opinion that modifying the pool contents outside libvirt borders on a "don't do that type operation", there is a check on the deleteVol side to determine that an unlink or rmdir failed because of ENOENT, then don't cause an error (e.g., don't cause an error if someone manipulated the pool outside libvirt's knowledge by removing the file/dir). So I'll reopen and generate a patch for upstream shortly Patch posted upstream: http://www.redhat.com/archives/libvir-list/2015-October/msg00079.html Pushed upstream as commit id 'fdda37608a6e22406fbdfe4ac0c573a96a8d0417' git describe fdda37608a6e22406fbdfe4ac0c573a96a8d0417 v1.2.20-23-gfdda376 Ugh... Need to set back to assigned.... Commit will be reverted and other patches generated to handle this specific case and other more general cases. More patches posted - patch 4 of the series fixes the specific problem, but extrapolating a bit to possible problems for other backends result in changes in patches 5-12, where patch 11 reverts the previous commit. series start: http://www.redhat.com/archives/libvir-list/2015-October/msg00312.html patch 4: http://www.redhat.com/archives/libvir-list/2015-October/msg00316.html Reposted the patches, got reviews, made updates and pushed upstream http://www.redhat.com/archives/libvir-list/2015-October/msg00810.html updates from review from original series: http://www.redhat.com/archives/libvir-list/2015-November/msg00093.html http://www.redhat.com/archives/libvir-list/2015-November/msg00094.html Pushed changes into upstream 1.2.22 commit 4cd7d220c9b93d559311c5c418c5aed0025763a2 $ git describe 4cd7d220c9b93d559311c5c418c5aed0025763a2 v1.2.21-13-g4cd7d22 $ *** Bug 1282283 has been marked as a duplicate of this bug. *** Verified on: libvirt-1.3.2-1.el7.x86_64 and PASSED ==== RBD storage === 1. # virsh pool-dumpxml rbd <pool type='rbd'> <name>rbd</name> <uuid>89733e5d-2883-43ed-8046-8005129da0d1</uuid> <capacity unit='bytes'>152820314112</capacity> <allocation unit='bytes'>1803247016</allocation> <available unit='bytes'>126306897920</available> <source> <host name='xxxxxxx' port='6789'/> <name>rbd</name> </source> </pool> 2. # virsh vol-list rbd --details Name Path Type Capacity Allocation ----------------------------------------------------------- hhan.img rbd/hhan.img network 1.00 GiB 1.00 GiB V.qcow2 rbd/V.qcow2 network 3.00 GiB 3.00 GiB VVV.qcow2 rbd/VVV.qcow2 network 0.00 B 0.00 B ys1.img rbd/ys1.img network 100.00 MiB 100.00 MiB 3. # virsh vol-create-as rbd ys1.img 200M error: Failed to create vol ys1.img error: storage volume 'ys1.img' exists already 4. # virsh pool-refresh rbd; virsh vol-list rbd --details Pool rbd refreshed Name Path Type Capacity Allocation ----------------------------------------------------------- hhan.img rbd/hhan.img network 1.00 GiB 1.00 GiB V.qcow2 rbd/V.qcow2 network 3.00 GiB 3.00 GiB VVV.qcow2 rbd/VVV.qcow2 network 0.00 B 0.00 B ys1.img rbd/ys1.img network 100.00 MiB 100.00 MiB =========== iscsi ============== 1. # virsh pool-dumpxml iscsi <pool type='iscsi'> <name>iscsi</name> <uuid>41c89778-5833-4a4e-809b-1d5831432c40</uuid> <capacity unit='bytes'>3221225472</capacity> <allocation unit='bytes'>3221225472</allocation> <available unit='bytes'>0</available> <source> <host name='xxxxxxxx'/> <device path='iqn.2014-12.com.redhat:libvirt-manual'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> 2. # virsh vol-list iscsi --details Name Path Type Capacity Allocation --------------------------------------------------------------------------------------------------------------------------------- unit:0:0:1 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-1 block 1.00 GiB 1.00 GiB unit:0:0:2 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-2 block 1.00 GiB 1.00 GiB unit:0:0:3 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-3 block 1.00 GiB 1.00 GiB 3. # virsh vol-create-as iscsi unit:0:0:3 100M error: Failed to create vol unit:0:0:3 error: storage volume 'unit:0:0:3' exists already 4. # virsh vol-list iscsi --details Name Path Type Capacity Allocation --------------------------------------------------------------------------------------------------------------------------------- unit:0:0:1 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-1 block 1.00 GiB 1.00 GiB unit:0:0:2 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-2 block 1.00 GiB 1.00 GiB unit:0:0:3 /dev/disk/by-path/ip-10.66.5.88:3260-iscsi-iqn.2014-12.com.redhat:libvirt-manual-lun-3 block 1.00 GiB 1.00 GiB ====== dir ====== 1. # virsh pool-dumpxml default <pool type='dir'> <name>default</name> <uuid>80bf5440-5491-9247-043c-39eaa5962c13</uuid> <capacity unit='bytes'>42141450240</capacity> <allocation unit='bytes'>11058479104</allocation> <available unit='bytes'>31082971136</available> <source> </source> <target> <path>/var/lib/libvirt/images</path> <permissions> <mode>0711</mode> <owner>0</owner> <group>0</group> <label>system_u:object_r:virt_image_t:s0</label> </permissions> </target> </pool> 2. # virsh vol-list default --details Name Path Type Capacity Allocation --------------------------------------------------------------------------------------------------------------- attacheddisk /var/lib/libvirt/images/attacheddisk file 1.00 GiB 196.00 KiB dir_pool /var/lib/libvirt/images/dir_pool dir 0.00 B 0.00 B dirpool /var/lib/libvirt/images/dirpool dir 0.00 B 0.00 B haha /var/lib/libvirt/images/haha file 1.00 MiB 1.00 MiB 3. # virsh vol-create-as default haha 100M error: Failed to create vol haha error: storage volume 'haha' exists already 4. # virsh vol-list default --details Name Path Type Capacity Allocation --------------------------------------------------------------------------------------------------------------- attacheddisk /var/lib/libvirt/images/attacheddisk file 1.00 GiB 196.00 KiB dir_pool /var/lib/libvirt/images/dir_pool dir 0.00 B 0.00 B dirpool /var/lib/libvirt/images/dirpool dir 0.00 B 0.00 B haha /var/lib/libvirt/images/haha file 1.00 MiB 1.00 MiB ========= lvm =========== 1. # virsh pool-dumpxml lvm <pool type='logical'> <name>lvm</name> <uuid>12345678-1234-1234-1234-123456781234</uuid> <capacity unit='bytes'>1069547520</capacity> <allocation unit='bytes'>629145600</allocation> <available unit='bytes'>440401920</available> <source> <name>vg_libvirt</name> <format type='lvm2'/> </source> <target> <path>/dev/vg_libvirt</path> </target> </pool> 2. # virsh vol-list lvm --details Name Path Type Capacity Allocation ----------------------------------------------------------- haha /dev/vg_libvirt/haha block 100.00 MiB 100.00 MiB hehe /dev/vg_libvirt/hehe block 200.00 MiB 200.00 MiB hoho /dev/vg_libvirt/hoho block 300.00 MiB 300.00 MiB 3. # virsh vol-create-as lvm hoho 500M error: Failed to create vol hoho error: storage volume 'hoho' exists already 4. # virsh vol-list lvm --details Name Path Type Capacity Allocation ----------------------------------------------------------- haha /dev/vg_libvirt/haha block 100.00 MiB 100.00 MiB hehe /dev/vg_libvirt/hehe block 200.00 MiB 200.00 MiB hoho /dev/vg_libvirt/hoho block 300.00 MiB 300.00 MiB 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/RHSA-2016-2577.html |