Hi Dave,

This should be a regression as libvirt-0.9.10-21.el6.x86_64 works well:
# virsh pool-destroy mypool
error: Failed to destroy pool mypool
error: internal error Child process (/bin/umount /var/lib/libvirt/images/mypool) status unexpected: exit status 1

Should I set a Regression keywords for the bug?

Thanks,
EricLee

(In reply to comment #1)
> Should I set a Regression keywords for the bug?

Hi Eric, thanks for asking.  That's odd, since I don't think there was much change in this area of the code.  Osier, can you have a look at this and see what the root cause is?  Thanks, Dave

(In reply to comment #3)
> (In reply to comment #1)
> > Should I set a Regression keywords for the bug?
> 
> Hi Eric, thanks for asking.  That's odd, since I don't think there was much
> change in this area of the code.  Osier, can you have a look at this and see
> what the root cause is?  Thanks, Dave

<...>
2012-11-20 06:57:55.887+0000: 15676: error : virCommandWait:2345 : internal error Child process (/bin/umount /var/lib/libvirt/images/mypool) unexpected exit status 1: umount: /var/lib/libvirt/images/mypool: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
</...>

This proves the underlying things are just working as expected, I could see
the problem is caused by we have bug on handling the return value. Though I
run out of time today to track down the root cause, I think it's fair to set
regression.

Strange, but ok, marked as regression.

The fix was pushed upstream:

commit f4ac06569a8ffce24fb8c07a0fc01574e38de6e4
Author: Osier Yang <jyang>
Date:   Wed Nov 21 11:22:39 2012 +0800

    storage: Fix bug of fs pool destroying
    
    Regression introduced by commit 258e06c85b7, "ret" could be set to 1
    or 0 by virStorageBackendFileSystemIsMounted before goto cleanup.
    This could mislead the callers (up to the public API
    virStoragePoolDestroy) to return success even the underlying umount
    command fails.

I can reproduce this with:
libvirt-0.10.2-9.el6.x86_64

verify with :
libvirt-0.10.2-11.el6.x86_64

step:
1: prepare pool xml:
<pool type='fs'>
  <name>mypool</name>
    <source>
        <device path='/dev/sda11'/>
            <format type='auto'/>
              </source>
                <target>
                    <path>/var/lib/libvirt/images/mypool</path>
                      </target>
                      </pool>
2:# virsh pool-define pool.xml
Pool mypool defined from pool.xml

# virsh pool-build mypool
Pool mypool built

# virsh pool-start mypool
Pool mypool started

3: check status
#mount
/dev/sda11 on /var/lib/libvirt/images/mypool type ext4 (rw)

4:Prepare the following xml to create volume in the pool.

# cat vol.xml
<volume>
  <name>disk_new.img</name>
  <capacity unit='M'>10</capacity>
  <allocation unit='M'>0</allocation>
  <target>
    <path>/var/lib/libvirt/images/mypool/disk_new.img</path>
    <format type='raw'/>
  </target>
</volume>
5. Create volume untill the allocation is exceed the disk capability.

# virsh vol-create mypool vol.xml

6. Attach the volume disk1.img to an existing guest as secondary disk, then start the guest. Keep the disk in the guest.

7.
# virsh pool-destroy mypool
error: Failed to destroy pool mypool
error: internal error Child process (/bin/umount /var/lib/libvirt/images/mypool) unexpected exit status 1: umount: /var/lib/libvirt/images/mypool: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

the pool still active and error msg is clear,verification passed.

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