Created attachment 636640 [details]
File: anaconda-tb

Created attachment 636641 [details]
File: product

Created attachment 636642 [details]
File: type

Created attachment 636643 [details]
File: ifcfg.log

Created attachment 636644 [details]
File: storage.log

Created attachment 636645 [details]
File: version

Created attachment 636646 [details]
File: environ

Created attachment 636647 [details]
File: executable

Created attachment 636648 [details]
File: anaconda.log

Created attachment 636649 [details]
File: syslog

Created attachment 636650 [details]
File: hashmarkername

Created attachment 636651 [details]
File: packaging.log

Created attachment 636652 [details]
File: cmdline_file

Created attachment 636653 [details]
File: release

Created attachment 636654 [details]
File: program.log

Created attachment 636667 [details]
Output from 'lvs'

This could be a hint.

This bug has been proposed as NTH for Fedora 18 final. If accepted as NTH, a fix for this would be considered for pushing to stable past the change freeze. More details about the NTH process is available at http://fedoraproject.org/wiki/QA:SOP_nth_bug_process .

Since there are so may NTH bugs to review, we'd like to find out if there is developer support for accepting this as NTH. If accepted as NTH, would a fix likely be ready in time to be included in Fedora 18 (currently scheduled for 2013-01-08)?

Developers, please respond soon as we will be using these responses to prioritize the order in which we review the proposed NTH bugs.

Looks like this commit already addressed the issue:
commit 9f0e9cba27b3e2b8409f2ce1c0ed4d24d677be9b
Author: Cole Robinson <crobinso>
Date:   Tue Oct 16 20:30:23 2012 -0400

    On F17 at least, this command fails:
    
    $ sudo /usr/sbin/lvcreate --name sparsetest -L 0K --virtualsize 16384K vgvirt
      Unable to create new logical volume with no extents
    
    Which is unfortunate since allocation=0 is what virt-manager tries to use
    by default.
    
    Rather than telling the user 'don't do that', let's just give them the
    smallest allocation possible if alloc=0 is requested.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=866481

*** This bug has been marked as a duplicate of bug 866481 ***

Or is this a followon issue, only made manifest by the fix for 866481, and we need to reopen this to figure out what further changes need to be made?

Reopening, this is actually a different issue.

Before, trying to do allocation=0 with libvirt would fail at volume creation time. The commit referened in comment #18 changed that to not fail, but the volume is not usable inside the guest, anaconda errors out. So something else is going on here.

Hi cole,
   This issue also exists on rhel6.4,when I use virt-manager to create a default volume in lvm pool,error occurs:libvirtError: internal error Child process (/usr/sbin/lvchange -aln vg_data/newlv) unexpected exit status 5:   One or more specified logical volume(s) not found.
   Is it necessary to clone this bug to rhel6.4 to track this issue?thanks.

(In reply to comment #22)
> Hi cole,
>    This issue also exists on rhel6.4,when I use virt-manager to create a
> default volume in lvm pool,error occurs:libvirtError: internal error Child
> process (/usr/sbin/lvchange -aln vg_data/newlv) unexpected exit status 5:  
> One or more specified logical volume(s) not found.
>    Is it necessary to clone this bug to rhel6.4 to track this issue?thanks.

Yes, please file a separate bug for RHEL

Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . This involves VM creation which is not likely to affect live images and isn't the default path for VM creation anyways. It could be fixed with an update and doesn't need to be pulled past freeze. If our assessment here is mistaken, please re-propose with more details, thanks. But we couldn't see any reason this needs to go into the frozen package set.

Was there any further movement on this issue?  I'm running updated F18 on a VM host (libvirt-0.10.2.3-1.fc18.x86_64) and am getting the same "Input/output error during write on /dev/vda" error when trying to create an F18 guest using an LVM storage pool.  My backtrace is different, though and ends at (or begins with, I guess) parted/disk.py, line 213, in commit  return self.__disk.commit()

Doing some random testing at the console while anaconda has crashed, I found that any attempt to write to /dev/vda simply results in IO errors.  However, on the host I also see some selinux errors like: 
 
type=SYSCALL msg=audit(1360702207.131:2485): arch=c000003e syscall=296 success=no exit=-13 a0=a a1=7f843e51bbf0 a2=11e a3=0 items=0 ppid=1 pid=12623 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 ses=4294967295 tty=(none) comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c261,c658 key=(null)
type=AVC msg=audit(1360702207.131:2485): avc:  denied  { write } for  pid=12623 comm="qemu-kvm" path="/dev/dm-3" dev="devtmpfs" ino=45875 scontext=system_u:system_r:svirt_t:s0:c261,c658 tcontext=system_u:object_r:virt_content_t:s0 tclass=blk_file

so on a hunch I did 'setenforce 0' but that didn't help.  On the host I also notice things like:

[12701.917205] Buffer I/O error on device dm-3, logical block 1180928
[12701.917205] lost page write due to I/O error on dm-3

which would seem to point to some rather bad hardware problems on the host, except that everything appears to test out OK.  The underlying device is raided, I can create volumes in the volume group manually, make filesystems in them and push data to those filesystes without errors.  I have an F16 host with pretty much the identical configuration that doesn't have any issues.

FYI, my problem was solved by removing libguestfs, as it was tickling some weird selinux issue causing the security context on the backing storage to get reset.  This is documented in bug https://bugzilla.redhat.com/show_bug.cgi?id=912499

I suspect several of the problems having to do with inability to write to /dev/vda are related to that issue.

So turns out that sparse LVM volumes don't auto-grow, like a sparse image file will. Which is legitimate behavior, but doesn't mesh with virt-manager expectations. So the fix here is for virt-manager to not try and create sparse LVM by default. Reassigning.

Fixed upstream as well:

http://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=507640ea85023ccdd7f49f522b5637e44f207030

virt-manager-0.9.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/virt-manager-0.9.5-1.fc18

Package virt-manager-0.9.5-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-0.9.5-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4629/virt-manager-0.9.5-1.fc18
then log in and leave karma (feedback).

virt-manager-0.9.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.