Bug 1044763 - havana compute fails to create qcow2 image if xfs sectsz != 512.
Summary: havana compute fails to create qcow2 image if xfs sectsz != 512.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libguestfs
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1044762
TreeView+ depends on / blocked
 
Reported: 2013-12-18 23:22 UTC by Joe Julian
Modified: 2013-12-30 05:05 UTC (History)
8 users (show)

Fixed In Version: libguestfs-1.22.7-4.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of: 1044762
Environment:
Last Closed: 2013-12-30 05:05:15 UTC


Attachments (Terms of Use)

Description Joe Julian 2013-12-18 23:22:20 UTC
+++ This bug was initially created as a clone of Bug #1044762 +++

Description of problem:
In Fedora 19's libguestfs, qemu is started with cache=none when attempting to mount the new image in order to inject the configuration. This fails to pread the qcow2 image: pread(9, 0x7f1d44000a00, 512, 0) = -1 EINVAL (Invalid argument)

if the image is on xfs with sectsz=4096:
meta-data=/dev/mapper/fedora_ewcs9-var isize=256    agcount=49, agsize=319872 blks
         =                       sectsz=4096  attr=2
data     =                       bsize=4096   blocks=15360000, imaxpct=25
         =                       sunit=128    swidth=256 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Version-Release number of selected component (if applicable):
libguestfs-1.22.7-1.fc19

How reproducible:
Always

Steps to Reproduce:
Install with packstack.
1. mkfs -s 4096 /dev/vgfoo/lvbar
2. mount /dev/vgfoo/lvbar /var/lib/nova/instances
3. Install with packstack
4. start openstack
5. Install an image and launch a VM from that image

Actual results:
The VM is not started. A log entry about ignoring the failure to inject data into the image is logged.

An strace revealed that qemu is being called by libguestfs attempting to use -drive file={image filename},if=none,id=drive-scsi0-0-0-0,format=qcow2,cache=none

Attempting that same command results in the error, "Invalid argument"
A further strace reveals the EINVAL comes from pread due to the block size mismatch.

Expected results:
The data is injected and the VM starts.

Additional info:
This bug is fixed in libguestfs 1.24 because it uses writeback or unsafe depending on mode, and never uses cache=none

--- Additional comment from Richard W.M. Jones on 2013-12-18 18:20:23 EST ---

Note this is (effectively) a bug in libguestfs in F19, or if
not a bug then the fix will involve that component.

--- Additional comment from Richard W.M. Jones on 2013-12-18 18:21:30 EST ---

RHEL bug (private) is bug 999239.

Comment 1 Richard W.M. Jones 2013-12-20 22:38:28 UTC
I've backported the cachemode stuff to F19, so by default
it will now use cache=writeback, and cache=unsafe for
temporary/throwaway disks.

http://koji.fedoraproject.org/koji/taskinfo?taskID=6321380

Comment 2 Fedora Update System 2013-12-21 15:41:01 UTC
libguestfs-1.22.7-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/libguestfs-1.22.7-4.fc19

Comment 3 Fedora Update System 2013-12-22 05:41:19 UTC
Package libguestfs-1.22.7-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libguestfs-1.22.7-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23801/libguestfs-1.22.7-4.fc19
then log in and leave karma (feedback).

Comment 4 Fedora Update System 2013-12-30 05:05:15 UTC
libguestfs-1.22.7-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.