Note - corresponding to the pause between the step between shot 5 and 6, the following line appears in /var/log/messages:

May 31 09:45:35 linvirt2 libvirtd: 09:45:35.731: 14409: error : virStorageBackendStablePath:1320 : cannot read dir '/dev/linvirt2_vg_fc15b': No such file or directory

This problem seems to confuse virt-manager so much that it gives up(?).

That error from the logs is the root problem. virt-manager is trying to detect if the specified path is libvirt managed storage. It does so by calling virStorageVolumeLookupByPath. The empty VG is causing that call to fail, even though the passed in path is indeed a storage volume.

virt-manager then does some more checks, sees that the root of the path /dev/existingvg is an existing storage pool, assumes you want to create a new volume named /dev/existingvg/existingvol, tries to use that name, and libvirt tells us it's taken.

I've committed an extra check in upstream virtinst that will make virt-manager check harder event if GetVolumeByPath fails, but libvirt needs to be fixed. 
Reassigning this bug to libvirt

And to clarify, an empty vg pool doesn't break GetVolumeByPath for every lookup, just for those pools who happen to come sequentially after the busted pool in libvirt's internal pool list, so just defining an empty vg pool might not cause the issue to easily reproduce. The root cause is the error:

virStorageBackendStablePath:1320 : cannot read dir '/dev/linvirt2_vg_fc15b': No
such file or directory

Patch posted to upstream.

http://www.redhat.com/archives/libvir-list/2011-September/msg00820.html

patch commited to upstream.

commit 05e2fc51d1f4ba884a18c23c924d90cfd04384e3
Author: Osier Yang <jyang>
Date:   Mon Sep 26 14:30:44 2011 +0800

    storage: Do not break the whole vol lookup process in the middle
    
    * src/storage/storage_driver.c: As virStorageVolLookupByPath lookups
    all the pool objs of the drivers, breaking when failing on getting
    the stable path of the pool will just breaks the whole lookup process,
    it can cause the API fails even if the vol exists indeed. It won't get
    any benefit. This patch is to fix it.

(In reply to comment #0)
> Description of problem:
> 
> Version-Release number of selected component (if applicable):
> virt-manager-0.8.6-4.el6.noarch
> 
> How reproducible:
> Every time.
> 
> Steps to Reproduce:
> 1. Create a volume group, but don't create any logical volumes from it yet.
> 2. Use virt-manager to create a new virtual server. (Or add to an existing
> one.)
> 3. In the storage selection step, choose "Select managed...", "Browse".
> 4. Select a storage pool from a VG which already has at least one LV.
> 5. Create a volume, and "Choose Volume"


I can't reproduce this issue on libvirt-0.9.4-1.el6_x86_64 with virt-manager-0.8.6-4.el6.noarch according to above steps, and could you give me your libvirt version? 

In addition, IMHO, 0.9.4-1(before Sep 26) is enough to verify this bug, but I indeed can't reproduce it.

Osier, I guess you should reproduce the bug, right? if so, please commit it, 
thanks.

# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               vg1
  PV Size               9.77 GiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              2499
  Free PE               499
  Allocated PE          2000
  PV UUID               mOej86-t93k-t2ai-E2XQ-BOJ1-e3AS-ZbTGbc

  "/dev/sda2" is a new physical volume of "9.77 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/sda2
  VG Name
  PV Size               9.77 GiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               8gWeh1-rl08-yuDR-ZqPJ-sKFj-uQ7b-IRTz6c

# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               9.76 GiB
  PE Size               4.00 MiB
  Total PE              2499
  Alloc PE / Size       2000 / 7.81 GiB
  Free  PE / Size       499 / 1.95 GiB
  VG UUID               u2HMVM-9xOd-7d8a-yovr-TlTH-rVvV-lyOSW0

# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vg1/test
  VG Name                vg1
  LV UUID                UEXCWp-MiN7-efF2-6SFY-913u-Wy1M-iRdBiA
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                7.81 GiB
  Current LE             2000
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

I have changed job, and I don't have access to any RHEL servers with libvirt, currently.

(In reply to comment #10)
> I have changed job, and I don't have access to any RHEL servers with libvirt,
> currently.

Hi Troels,
Thanks for your reply, no problem, I will check it again.

Alex

I can reproduce the bug on libvirt-0.9.4-1.el6.x86_64, I think it's helpful to show test steps in here:

Create a empty VG such as vg1 according to original bug description, then create a volume such as foo.img in 'default' pool:

# virsh pool-list
Name                 State      Autostart 
-----------------------------------------
default              active     yes       
vg1                  active     yes

# virsh vol-list vg1
Name                 Path                                    
-----------------------------------------


# virsh vol-list default
Name                 Path                                    
-----------------------------------------
foo.img           /var/lib/libvirt/images/foo.img      

# virsh vol-path vg1 /var/lib/libvirt/images/foo.img
error: failed to get pool '/var/lib/libvirt/images/foo.img'
error: failed to get vol 'vg1'
error: cannot read dir '/dev/vg1': No such file or directory

The 0.9.9-1 is fine, every lookup hasn't been broken by GetVolumeByPath, and I can also see a new warning in log file, the patch is valid:

warning : storageVolumeLookupByPath:1255 : Failed to get stable path for pool 'vg1'

But, it exists another issue, I will file a separated bug to trace it.

(In reply to comment #12)
> But, it exists another issue, I will file a separated bug to trace it.

New issue: virsh vol-path can't correctly display which pool a volume belongs to
https://bugzilla.redhat.com/show_bug.cgi?id=781515

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed.

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-2012-0748.html