Can you provide the pool xml?

Created attachment 534049 [details]
pool xml

It has nothing special. Whenever I add a snapshot LV and refresh the pool, it gets inactive. More:
# lvdisplay VirtVG
File descriptor 8 (pipe:[35313]) leaked on lvdisplay invocation. Parent PID 8246: bash
  --- Logical volume ---
  LV Name                /dev/VirtVG/testqemu
  VG Name                VirtVG
  LV UUID                QRTK9G-08qk-ezAO-UB5P-bmXI-3Ofm-EZbvNj
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/VirtVG/testqemu_vorigin
  LV Status              available
  # open                 0
  LV Size                3.00 GiB
  Current LE             768
  COW-table size         880.00 MiB
  COW-table LE           220
  Allocated to snapshot  0.00% 
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:6

(In reply to comment #0)
> Description of problem:
> libvirt throws an error when trying to work with LVs which are snapshots.
> Please fix.
> 
> Steps to Reproduce:
> 1. Create a volume: lvcreate -nsnapshoted_lv -L1G VirtVG --virtualsize 3G

This is not an snapshot lv actually, though the name is "snapshoted_lv".

> 2. Add the VG to libvirt's qemu://system
> 
> Actual results:
> Error starting pool 'VirtVG': cannot open volume
> '/dev/VirtVG/[snapshoted_lv_vorigin]': No such file or directory
> 
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in
> cb_wrapper
>     callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
>     callback(*args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/storagepool.py", line 64, in start
>     self.pool.create(0)
>   File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1761, in create
>     if ret == -1: raise libvirtError ('virStoragePoolCreate() failed',
> pool=self)
> libvirtError: cannot open volume '/dev/VirtVG/[snapshoted_lv_vorigin]': No such
> file or directory

(In reply to comment #2)
> Created attachment 534049 [details]
> pool xml
> 
> It has nothing special. Whenever I add a snapshot LV and refresh the pool, it
> gets inactive. More:
> # lvdisplay VirtVG
> File descriptor 8 (pipe:[35313]) leaked on lvdisplay invocation. Parent PID
> 8246: bash
>   --- Logical volume ---
>   LV Name                /dev/VirtVG/testqemu
>   VG Name                VirtVG
>   LV UUID                QRTK9G-08qk-ezAO-UB5P-bmXI-3Ofm-EZbvNj
>   LV Write Access        read/write
>   LV snapshot status     active destination for /dev/VirtVG/testqemu_vorigin

This is a snapshot lv, but with my testing on the git head of libvirt, there is no problem for a logical pool has a snapshot lv. Both of pool-start and pool-refresh work fine.

@Ildar, What's the libvirt version you use? on which platform?

0.9.6, ALTLinux x86_64

There is no problem when I tested with 0.9.6, things are just fine (from tarball, and note that I don't have an ALTLinux).

By the way, the pool can't be started if there is a striped lv on 0.9.6 though, it's fixed in upstream 0.9.7 with commit 82c174.

@Ildar, could you figure out if the pool-start/pool-refresh work for you with a real snapshot lv?

I am sorry that my report was quite misleading.
I did it too general, noting snapshots instead of virtual volumes.

Note: virtual volumes are snapshots of some pseudo-volumes that do not exist in reality:
# lvcreate -n vlv-test -L1G VirtVG --virtualsize 3G
  Logical volume "vlv-test" created
# lvs | grep vlv-test
  vlv-test VirtVG swi-a-   1.00g [vlv-test_vorigin]   0.00                        
# lvdisplay /dev/VirtVG/vlv-test | grep status
  LV snapshot status     active destination for /dev/VirtVG/vlv-test_vorigin
# lvdisplay /dev/VirtVG/vlv-test_vorigin
  One or more specified logical volume(s) not found.

virsh # pool-start VirtVG
error: Failed to start pool VirtVG
error: cannot open volume '/dev/VirtVG/[vlv-test_vorigin]': No such file or directory

Summary: libvirt tries to find the origin volume that does not exist.

(In reply to comment #9)
> I am sorry that my report was quite misleading.
> I did it too general, noting snapshots instead of virtual volumes.
> 
> Note: virtual volumes are snapshots of some pseudo-volumes that do not exist in
> reality:
> # lvcreate -n vlv-test -L1G VirtVG --virtualsize 3G
>   Logical volume "vlv-test" created
> # lvs | grep vlv-test
>   vlv-test VirtVG swi-a-   1.00g [vlv-test_vorigin]   0.00                      
> # lvdisplay /dev/VirtVG/vlv-test | grep status
>   LV snapshot status     active destination for /dev/VirtVG/vlv-test_vorigin
> # lvdisplay /dev/VirtVG/vlv-test_vorigin
>   One or more specified logical volume(s) not found.
> 
> virsh # pool-start VirtVG
> error: Failed to start pool VirtVG
> error: cannot open volume '/dev/VirtVG/[vlv-test_vorigin]': No such file or
> directory
> 
> Summary: libvirt tries to find the origin volume that does not exist.

Thanks, Ildar, the problem exists indeed. 

# /sbin/lvs --separator \# --noheadings --units b --unbuffered --nosuffix --options lv_name,origin,uuid,devices,segtype,stripes,seg_size,vg_extent_size osier_vg
  osier_snap##gH3hDB-1QuA-UVkY-SlBJ-0Bbe-L0G2-tGS3cQ#/dev/sda5(15)#linear#1#4194304#4194304
  osier_linear##J63tmm-fV8z-lt52-4kKc-fKrE-dYe4-zDkJU3#/dev/sda5(16)#linear#1#12582912#4194304
  snap_test#osier_linear#11lBqw-xZbv-qf1o-IhT5-vcQH-nxAD-8PtDVe#/dev/sda6(16)#linear#1#104857600#4194304
  lv_test#[lv_test_vorigin]#Mo91Oc-lfVU-8F7A-12UM-ytvs-EKip-mofEKB#/dev/sda5(19)#linear#1#12582912#4194304

For the lv_test volume which created with "--virtualsize", it's the original path
is outputed as "[lv_test_vorigin]".

Patch committed to upstream:

commit d26b73ca2b1c35957b3c709a6cd9b3fd6a3d332a
Author: Osier Yang <jyang>
Date:   Fri Nov 18 19:15:10 2011 +0800

Ildar, would you be able to test the upstream HEAD?  (Apologies if you have I haven't been following all the details.)

Dave, I believe Osier and you that the problem is fixed, though I can't check it right now. You can close the bug. If I see some related problem, I'll REOPEN it.

Thanks a lot.

Ok, sounds like a plan.