Bug 1126976 - VHDX image format does not work on PPC64 (Endian issues)
Summary: VHDX image format does not work on PPC64 (Endian issues)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: ppc64
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-05 18:36 UTC by Jeff Cody
Modified: 2015-03-26 11:42 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-rhev-2.1.0-4.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-26 11:42:25 UTC


Attachments (Terms of Use)
Draft endian fix patch for VHDX (6.40 KB, patch)
2014-08-06 06:35 UTC, David Gibson
no flags Details | Diff

Description Jeff Cody 2014-08-05 18:36:22 UTC
There are some endian issues with the vhdx image format driver, on big-endian hosts.

This bug is to track all endian-related changes for VHDX, for big-endian hosts.

These can be verified by running ./check -vdhx in the qemu-iotests directory on a big-endian host; all tests should pass.  Currently, on big-endian hosts, the vhdx tests will fail.

Comment 1 David Gibson 2014-08-06 06:35:57 UTC
Created attachment 924360 [details]
Draft endian fix patch for VHDX

I had a look into this today.

I've attached a draft patch which fixes at least some of the VHDX endian problems.

With this a VHDX created by "qemu-img create -f vhdx 8M" on an x86 host passes "qemu-img check" on a ppc64 host, and also the other way around (created on ppc64, checked on x86).

I haven't yet tested anything more strenuous though.

It'd be nice if someone can sanity check this, then I'll send it upstream.

Comment 2 David Gibson 2014-08-06 06:37:25 UTC
By the by, the real use cases for using Hyper-V VHDX images on ppc64 seem.. limited at best.

Comment 3 Jeff Cody 2014-08-06 13:24:14 UTC
(In reply to David Gibson from comment #1)
> Created attachment 924360 [details]
> Draft endian fix patch for VHDX
> 
> I had a look into this today.
> 
> I've attached a draft patch which fixes at least some of the VHDX endian
> problems.
> 
> With this a VHDX created by "qemu-img create -f vhdx 8M" on an x86 host
> passes "qemu-img check" on a ppc64 host, and also the other way around
> (created on ppc64, checked on x86).
> 
> I haven't yet tested anything more strenuous though.
> 
> It'd be nice if someone can sanity check this, then I'll send it upstream.

Hi, Thanks!  I actually created the bug because I have a patch about ready to go upstream as well - I'll check against your patch, and see if there are any areas I missed.

>By the by, the real use cases for using Hyper-V VHDX images on ppc64 seem.. >limited at best.

I am thinking main uses would probably be with qemu-img, and v2v, but I guess I don't really know for sure..

Comment 4 David Gibson 2014-08-07 01:27:35 UTC
>Hi, Thanks!  I actually created the bug because I have a patch about ready to go
>upstream as well - I'll check against your patch, and see if there are any areas
>I missed.

Ah, ok, just saw your patches on qemu-devel.  Would have been nice to mention that at the start of the BZ to avoid the duplicated effort.  Oh well.

> I am thinking main uses would probably be with qemu-img, and v2v, but I guess I > don't really know for sure..

Doing what with qemu-img?  And v2v from where to where?

Comment 5 Jeff Cody 2014-08-07 02:48:46 UTC
(In reply to David Gibson from comment #4)
> >Hi, Thanks!  I actually created the bug because I have a patch about ready to go
> >upstream as well - I'll check against your patch, and see if there are any areas
> >I missed.
> 
> Ah, ok, just saw your patches on qemu-devel.  Would have been nice to
> mention that at the start of the BZ to avoid the duplicated effort.  Oh well.
> 

Sorry if there was any duplicated effort, however I did create the bug, set the bug's "Assigned To" to me, and moved the status to "ASSIGNED" ;-)

> > I am thinking main uses would probably be with qemu-img, and v2v, but I guess I > don't really know for sure..
> 
> Doing what with qemu-img?  And v2v from where to where?

Like I said, not sure what the exact use case might be in the wild.  But it wouldn't seem unreasonable to want convert a VHDX data disk to a native format (e.g. qcow2), or mount a VHDX data drive, even though the host happens to be ppc64.

Comment 6 David Gibson 2014-08-08 01:21:48 UTC
> Sorry if there was any duplicated effort, however I did create the bug, set the
> bug's "Assigned To" to me, and moved the status to "ASSIGNED" ;-)

Yeah, good point, I guess I was over-eager :).

> Like I said, not sure what the exact use case might be in the wild.  But it
> wouldn't seem unreasonable to want convert a VHDX data disk to a native format
> (e.g. qcow2), or mount a VHDX data drive, even though the host happens to be
> ppc64.

Hmm.  So, there's no question that this ought to be fixed upstream, but it still seems an unlikely use case to me.  A VHDX image pretty much implies the guest was or will be running on Hyper-V, which implies x86, which means it won't run on a ppc64 host.

Comment 7 Miroslav Rezanina 2014-09-17 07:37:53 UTC
Fix included in qemu-kvm-rhev-2.1.0-4.el7

Comment 9 Xu Han 2015-01-05 04:39:54 UTC
Reproduced this issue with qemu-kvm-rhev-2.1.0-3.el7:

# ./check -vhdx
QEMU          -- /home/xuhan/src-3/qemu-2.1.0/tests/qemu-iotests/qemu
QEMU_IMG      -- /home/xuhan/src-3/qemu-2.1.0/tests/qemu-iotests/qemu-img
QEMU_IO       -- /home/xuhan/src-3/qemu-2.1.0/tests/qemu-iotests/qemu-io 
QEMU_NBD      -- /home/xuhan/src-3/qemu-2.1.0/tests/qemu-iotests/qemu-nbd
IMGFMT        -- vhdx
IMGPROTO      -- file
PLATFORM      -- Linux/ppc64 ibm-p8-kvm-02-qe 3.10.0-217.el7.ppc64
SOCKET_SCM_HELPER -- 

001         - output mismatch (see 001.out.bad)
...
Not run: 006 007 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 053 054 055 056 057 058 059 060 061 062 063 065 066 067 068 069 071 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 095
Failures: 001 002 003 004 005 008 009 010 011 012 021 032 033 052 064 070 072
Failed 17 of 17 tests


Verified this issue with qemu-kvm-rhev-2.1.2-17.el7:

# ./check -vhdx
QEMU          -- /home/xuhan/src-17/qemu-2.1.2/tests/qemu-iotests/qemu
QEMU_IMG      -- /home/xuhan/src-17/qemu-2.1.2/tests/qemu-iotests/qemu-img
QEMU_IO       -- /home/xuhan/src-17/qemu-2.1.2/tests/qemu-iotests/qemu-io 
QEMU_NBD      -- /home/xuhan/src-17/qemu-2.1.2/tests/qemu-iotests/qemu-nbd
IMGFMT        -- vhdx
IMGPROTO      -- file
PLATFORM      -- Linux/ppc64 ibm-p8-kvm-02-qe 3.10.0-217.el7.ppc64
SOCKET_SCM_HELPER -- 

001 2s ...
...
Not run: 006 007 013 014 015 016 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 053 054 055 056 057 058 059 060 061 062 063 065 066 067 068 069 073 074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 095 101
Passed all 18 tests


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