Bug 872162

Summary: error creating partitions on LVM volume created with allocation=0
Product: [Fedora] Fedora Reporter: Petr Schindler <pschindl>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: awilliam, berrange, clalancette, crobinso, eblake, g.kaviyarasu, hbrock, itamar, jforbes, jonathan, joshua, jyang, laine, libvirt-maint, tflink, tibbs, tzheng, vanmeeuwen+fedora, veillard, virt-maint
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:074ffa47cecf899c64c8e31eced4f2397fa7a7028c7cbe2a13b09816c3da9ad0 RejectedNTH
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 888118 (view as bug list) Environment:
Last Closed: 2013-04-09 21:28:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 888118    
Description Flags
File: anaconda-tb
File: product
File: type
File: ifcfg.log
File: storage.log
File: version
File: environ
File: executable
File: anaconda.log
File: syslog
File: hashmarkername
File: packaging.log
File: cmdline_file
File: release
File: program.log
Output from 'lvs' none

Description Petr Schindler 2012-11-01 08:36:47 EDT
Description of problem:
I created a new LVM partition (I let allocation on 0) with virt-manager wizzard and choose it for virtual machine. I let anaconda to use the whole disk. When anaconda tried to create partitions it falls.

My guess is, that it is fault of libvirt and it is somehow related to bug 866481 

Version-Release number of selected component:

Additional info:
libreport version: 2.0.17
cmdline:        /usr/bin/python  /sbin/anaconda
kernel:         3.6.2-2.fc18.x86_64

:The following was filed automatically by anaconda:
:anaconda 18.21 exception report
:Traceback (most recent call first):
:  File "/usr/lib64/python2.7/site-packages/parted/disk.py", line 221, in commitToDevice
:    return self.__disk.commit_to_dev()
:  File "/usr/lib64/python2.7/site-packages/parted/decorators.py", line 32, in new
:    ret = fn(*args, **kwds)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/disklabel.py", line 300, in commitToDisk
:    self.partedDisk.commitToDevice()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 436, in execute
:    self.device.disk.format.commitToDisk()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 323, in processActions
:    action.execute()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 357, in doIt
:    self.devicetree.processActions()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 195, in turnOnFilesystems
:    storage.doIt()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 107, in doInstall
:    turnOnFilesystems(storage)
:  File "/usr/lib64/python2.7/threading.py", line 504, in run
:    self.__target(*self.__args, **self.__kwargs)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run
:    threading.Thread.run(self, *args, **kwargs)
:IOException: Input/output error during write on /dev/vda
Comment 1 Petr Schindler 2012-11-01 08:37:06 EDT
Created attachment 636640 [details]
File: anaconda-tb
Comment 2 Petr Schindler 2012-11-01 08:37:08 EDT
Created attachment 636641 [details]
File: product
Comment 3 Petr Schindler 2012-11-01 08:37:11 EDT
Created attachment 636642 [details]
File: type
Comment 4 Petr Schindler 2012-11-01 08:37:14 EDT
Created attachment 636643 [details]
File: ifcfg.log
Comment 5 Petr Schindler 2012-11-01 08:37:16 EDT
Created attachment 636644 [details]
File: storage.log
Comment 6 Petr Schindler 2012-11-01 08:37:18 EDT
Created attachment 636645 [details]
File: version
Comment 7 Petr Schindler 2012-11-01 08:37:21 EDT
Created attachment 636646 [details]
File: environ
Comment 8 Petr Schindler 2012-11-01 08:37:23 EDT
Created attachment 636647 [details]
File: executable
Comment 9 Petr Schindler 2012-11-01 08:37:25 EDT
Created attachment 636648 [details]
File: anaconda.log
Comment 10 Petr Schindler 2012-11-01 08:37:28 EDT
Created attachment 636649 [details]
File: syslog
Comment 11 Petr Schindler 2012-11-01 08:37:30 EDT
Created attachment 636650 [details]
File: hashmarkername
Comment 12 Petr Schindler 2012-11-01 08:37:32 EDT
Created attachment 636651 [details]
File: packaging.log
Comment 13 Petr Schindler 2012-11-01 08:37:36 EDT
Created attachment 636652 [details]
File: cmdline_file
Comment 14 Petr Schindler 2012-11-01 08:37:39 EDT
Created attachment 636653 [details]
File: release
Comment 15 Petr Schindler 2012-11-01 08:37:41 EDT
Created attachment 636654 [details]
File: program.log
Comment 16 Petr Schindler 2012-11-01 08:44:29 EDT
Created attachment 636667 [details]
Output from 'lvs'

This could be a hint.
Comment 17 Tim Flink 2012-12-13 04:47:53 EST
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.
Comment 18 Eric Blake 2012-12-13 11:58:10 EST
Looks like this commit already addressed the issue:
commit 9f0e9cba27b3e2b8409f2ce1c0ed4d24d677be9b
Author: Cole Robinson <crobinso@redhat.com>
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.
Comment 19 Eric Blake 2012-12-13 11:59:15 EST

*** This bug has been marked as a duplicate of bug 866481 ***
Comment 20 Eric Blake 2012-12-13 12:01:36 EST
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?
Comment 21 Cole Robinson 2012-12-13 12:02:52 EST
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.
Comment 22 tingting zheng 2012-12-17 03:30:09 EST
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.
Comment 23 Cole Robinson 2012-12-17 13:23:38 EST
(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
Comment 24 Adam Williamson 2012-12-19 15:16:11 EST
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.
Comment 25 Jason Tibbitts 2013-02-12 16:05:29 EST
Was there any further movement on this issue?  I'm running updated F18 on a VM host (libvirt- 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.
Comment 26 Jason Tibbitts 2013-02-18 15:21:12 EST
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.
Comment 27 Cole Robinson 2013-03-14 08:57:54 EDT
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:

Comment 28 Fedora Update System 2013-04-01 08:53:23 EDT
virt-manager-0.9.5-1.fc18 has been submitted as an update for Fedora 18.
Comment 29 Fedora Update System 2013-04-01 18:28:49 EDT
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:
then log in and leave karma (feedback).
Comment 30 Fedora Update System 2013-04-09 21:28:19 EDT
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.