Bug 815644
| Summary: | There is no executable permission on default pool. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | lei wang <leiwan> |
| Component: | libvirt | Assignee: | Osier Yang <jyang> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.3 | CC: | acathrow, dallan, dyasny, dyuan, gsun, jdenemar, lsu, mzhan, rwu, whuang, zpeng |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libvirt-0.10.0-0rc0.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-02-21 07:12:01 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: | |||
I don't see any issue in your bug description. The mode element says 700, where 7 is 4 + 2 + 1, i.e., all r, w, and x bits are set.
1) I found "default" pool 's permission is 0711 actually , but pool-dumpxml is 0700
#ll /var/lib/libvirt/images/ -d
drwx--x--x. 8 root root 4096 Apr 19 11:03 /var/lib/libvirt/images/
# virsh pool-dumpxml default
<pool type='dir'>
<name>default</name>
<uuid>736c6f23-2afe-0f4f-294b-3d8864f5872f</uuid>
<capacity unit='bytes'>30963351552</capacity>
<allocation unit='bytes'>20410916864</allocation>
<available unit='bytes'>10552434688</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0700</mode>
<owner>-1</owner>
<group>-1</group>
</permissions>
</target>
</pool>
2) if the folder permission is real "0700" then libvirt can not start guest which its image is in that folder, because qemu has not execute permission for the folder .
Now If you create a new dir pool with virt-manager ,the dir is real 0700 but virt-manager will help you to fix it by setfacl , add qemu "x" permission ,when try to start a guest .
Commit in upstream: 8a544719aa test with libvirt-0.10.0-0rc0.el6.x86_64
below is my step
step:
1:remove all libvirt package,& #rm /var/lib/libvirt -rf
2:install libvirt latest pkg and start libvirtd
#rpm -ivh libvirt*
#service libvirtd start
3:check default pool
#virsh pool-dumpxml default
......
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0700</mode>
<owner>4294967295</owner>
<group>4294967295</group>
</permissions>
</target>
......
#ls -dl /var/lib/libvirt/images
drwx--x--x. 2 root root 4096 Aug 2 03:46 /var/lib/libvirt/images/
the dir permission is 711
the mode not 755 , always 700 in dumpxml ,hi osier, is it right?
but when i create a new pool, the permissions mode is 755.
verify with libvirt-0.10.2-8.el6.x86_64
step:
1: create a new env. for libvirt
2: cat pool.xml
<pool type='dir'>
<name>default</name>
<uuid>736c6f23-2afe-0f4f-294b-3d8864f5872f</uuid>
<capacity unit='bytes'>30963351552</capacity>
<allocation unit='bytes'>20410916864</allocation>
<available unit='bytes'>10552434688</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<owner>-1</owner>
<group>-1</group>
</permissions>
</target>
</pool>
3: define and start pool
#virsh pool-define pool.xml
#virhs pool-start default
4: check pool permissions
#virsh pool-dumpxml default
<permissions>
<mode>0755</mode>
<owner>-1</owner>
<group>-1</group>
</permissions>
#ls -al /var/lib/libvirt
drwxr-xr-x. 19 root root 81920 Nov 15 02:05 images
verification passed.
Hi osier ,
In libvirt-0.10.2-15 , after reinstall libvirt , the default pool's permission doesn't match from the xml to the folder , should we reopen this bug?
In RHEL6.4 snap3
#rm -rf /var/lib/libvirt
#yum remove libvirt
#yum install libvirt
#rpm -q libvirt
libvirt-0.10.2-15.el6.x86_64
#service libvirtd start
Starting libvirtd daemon: [ OK ]
# virsh pool-list --all
Name State Autostart
-----------------------------------------
default active yes
# ll -d /var/lib/libvirt/images/
drwx--x--x. 2 root root 4096 Jan 9 22:51 /var/lib/libvirt/images/
# virsh pool-dumpxml default
<pool type='dir'>
<name>default</name>
<uuid>5fd3f4bb-8c3f-0738-9ecf-b362b2c0258f</uuid>
<capacity unit='bytes'>42275766272</capacity>
<allocation unit='bytes'>2305581056</allocation>
<available unit='bytes'>39970185216</available>
<source>
</source>
<target>
<path>/var/lib/libvirt/images</path>
<permissions>
<mode>0755</mode>
<owner>-1</owner>
<group>-1</group>
</permissions>
</target>
</pool>
(In reply to comment #9) After refresh , still keep 711 ,test in libvirt -16 # ll /var/lib/libvirt/images/ -d drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ # virsh pool-refresh default Pool default refreshed ll /var/lib/libvirt/images/ -d drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ (In reply to comment #10) > (In reply to comment #9) > After refresh , still keep 711 ,test in libvirt -16 > > # ll /var/lib/libvirt/images/ -d > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ > > # virsh pool-refresh default > Pool default refreshed > > ll /var/lib/libvirt/images/ -d > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ If you have started the pool after the re-installing, the directory permission modes are expected to be updated with 0755. It's bug if it's not updated. But please open a new bug instead, this bug is only for changing the default pool permission. And to reproduce it, you don't have to reinstall the libvirt. Do like following should work: 1) Create a directory like "/var/lib/libvirt/pool-test" with permission like 0711 2) define a pool with target permissions modes like 0755 (different with what you used to create the directory in 1)) 3) start the pool 4) Check if the directory's permission is updated to 0755. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > After refresh , still keep 711 ,test in libvirt -16 > > > > # ll /var/lib/libvirt/images/ -d > > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ > > > > # virsh pool-refresh default > > Pool default refreshed > > > > ll /var/lib/libvirt/images/ -d > > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/ > > If you have started the pool after the re-installing, the directory > permission > modes are expected to be updated with 0755. It's bug if it's not updated. But > please open a new bug instead, this bug is only for changing the default pool > permission. > > And to reproduce it, you don't have to reinstall the libvirt. Do like > following should work: > > 1) Create a directory like "/var/lib/libvirt/pool-test" with permission like > 0711 > 2) define a pool with target permissions modes like 0755 (different with what > you used to create the directory in 1)) > 3) start the pool s/start/pool-build/ > 4) Check if the directory's permission is updated to 0755. I test per comment 11 , get the expected reslut. 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. http://rhn.redhat.com/errata/RHSA-2013-0276.html |
Description of problem: There is no executable permission on default pool. Version-Release number of selected component (if applicable): # rpm -qa |grep libvirt libvirt-python-0.9.10-11.el6.x86_64 libvirt-debuginfo-0.9.10-11.el6.x86_64 libvirt-client-0.9.10-11.el6.x86_64 libvirt-0.9.10-11.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1.# virsh pool-dumpxml default <pool type='dir'> <name>default</name> <uuid>7d7ac6da-3fc8-f835-edc1-87f65df39e93</uuid> <capacity unit='bytes'>42275766272</capacity> <allocation unit='bytes'>7853170688</allocation> <available unit='bytes'>34422595584</available> <source> </source> <target> <path>/var/lib/libvirt/images</path> <permissions> <mode>0700</mode> <owner>-1</owner> <group>-1</group> </permissions> </target> </pool> Actual results: No executable permission on it. Expected results: There is executable permission on mode tag. Additional info: