Red Hat Bugzilla – Full Text Bug Listing
|Summary:||libvirt: virsh pool-start hangs for directory pool pointing to /tmp, /dev|
|Product:||[Fedora] Fedora||Reporter:||Richard W.M. Jones <rjones>|
|Component:||libvirt||Assignee:||Cole Robinson <crobinso>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, clalance, crobinso, eblake, itamar, jforbes, veillard, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-07-12 13:23:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Richard W.M. Jones 2010-05-06 09:18:36 EDT
Description of problem: I created a dir pool using the path /tmp just for some testing. I was able to define this pool OK, but attempts to start it result in a hang. Nothing appears to be happening on the machine, and the hang goes on for at least several minutes (until I killed virsh). Version-Release number of selected component (if applicable): libvirt-0.7.7-3.fc14.x86_64 How reproducible: ? Steps to Reproduce: 1. cat /tmp/pool.xml <pool type="dir"> <name>tmp</name> <target><path>/tmp</path></target> </pool> 2. virsh pool-define /tmp/pool.xml 3. virsh pool-start tmp Actual results: virsh pool-start hangs Expected results: Should do something but not hang. Additional info: There are 6,600 files in /tmp.
Comment 1 Richard W.M. Jones 2010-05-06 09:25:01 EDT
Same thing with libvirt-0.8.1-1.fc14.x86_64, and the same also after restarting libvirtd.
Comment 2 Richard W.M. Jones 2010-05-06 09:28:07 EDT
The cause (thanks danpb) turned out to be a FIFO in /tmp. After removing this file and restarting libvirtd, it still fails (but at least it doesn't hang) on: # virsh pool-start tmp error: Failed to start pool tmp error: cannot open volume '/tmp/vc': No such device or address where /tmp/vc happens to be a socket.
Comment 3 Richard W.M. Jones 2010-05-06 09:28:58 EDT
Removing the socket gives: # virsh pool-start tmp error: Failed to start pool tmp error: cannot open volume '/tmp/sound-juicer.rjones.1182249894': No such device or address This really _ought_ to work. It should ignore special files.
Comment 4 Eric Blake 2010-05-21 14:20:46 EDT
Well, block devices are special files but should not be ignored; so we do want more than just regular files. The only question I have is whether we have a use case for allowing character devices (such as /dev/null or /dev/zero); but I agree that directories, sockets, and pipes should never be used as a valid form of backend storage (storage devices pretty much have to be seekable to be usable).
Comment 5 Daniel Berrange 2010-05-24 05:32:50 EDT
No, in the context of a directory pool, block devices aren't relevant. The directory pool is for managing file based & directory based storage. So we should only report on regular files and directories, ignoring everything else. We need to avoid trying to seek on directories obviously.
Comment 6 Cole Robinson 2010-06-03 14:03:46 EDT