Bug 589577

Summary: libvirt: virsh pool-start hangs for directory pool pointing to /tmp, /dev
Product: [Fedora] Fedora Reporter: Richard W.M. Jones <rjones>
Component: libvirtAssignee: Cole Robinson <crobinso>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: berrange, clalance, crobinso, eblake, itamar, jforbes, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-12 17:23:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard W.M. Jones 2010-05-06 13:18:36 UTC
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 13:25:01 UTC
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 13:28:07 UTC
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 13:28:58 UTC
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 18:20:46 UTC
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 Berrangé 2010-05-24 09:32:50 UTC
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.