Bug 1090867

+++ This bug was initially created as a clone of Bug #1006159 +++
+++ This bug was initially created as a clone of Bug #879234 +++

Description of problem:

Currently the 'qemu-img -O vpc' does not produce a valid vhd file that could be used in Hyper-V. It would be nice if we could integrate at least the functionality of the vhdtool here:
archive.msdn.microsoft.com/vhdtool
https://github.com/andreiw/vhdtool

so that we can convert to valid VHD files

--- Additional comment from RHEL Product and Program Management on 2012-11-22 07:23:18 EST ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from RHEL Product and Program Management on 2012-12-13 15:09:08 EST ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Bhavna Sarathy on 2013-01-22 10:27:30 EST ---

This feature needs to be delivered in RHEL7 as it's a dependency for the virt-v2v conversion tool. Both VHD and VHDX should be done.

--- Additional comment from Richard W.M. Jones on 2013-01-28 13:53:00 EST ---

Should note that what we really want for virt-v2v is the
capability to convert *from* vhd/vhdx to a native qemu
format.

--- Additional comment from Jeff Cody on 2013-02-07 17:51:44 EST ---

Currently adding the vhdx file format, using the MS specification for VHDX from here: https://www.microsoft.com/en-us/download/details.aspx?id=29681

My github repo for the work in progress is 
branch jtc-vhdx-work
git://github.com/codyprime/qemu-kvm-jtc.git
https://github.com/codyprime/qemu-kvm-jtc

(this is just an informational update, it is not functional or ready to be committed upstream yet)

--- Additional comment from juzhang on 2013-04-24 04:48:30 EDT ---

(In reply to comment #5)
> Currently adding the vhdx file format, using the MS specification for VHDX
> from here: https://www.microsoft.com/en-us/download/details.aspx?id=29681
> 
> My github repo for the work in progress is 
> branch jtc-vhdx-work
> git://github.com/codyprime/qemu-kvm-jtc.git
> https://github.com/codyprime/qemu-kvm-jtc
> 
> (this is just an informational update, it is not functional or ready to be
> committed upstream yet)

Hi Jeff,

If we support vhdx on rhel7, Does QE need to test vpc format? Thanks.

--- Additional comment from Jeff Cody on 2013-04-30 10:54:01 EDT ---

Hi Junyi,

VHDX is completely independent of VPC.  So testing VPC is more of a question if RHEL7 is going to support VPC, rather than if VHDX will require us to test VPC.  But there is nothing with regards to VHDX that will cause VPC to need to be tested.

--- Additional comment from juzhang on 2013-05-02 02:26:20 EDT ---

(In reply to comment #7)
> Hi Junyi,
> 
> VHDX is completely independent of VPC.  So testing VPC is more of a question
> if RHEL7 is going to support VPC, rather than if VHDX will require us to
> test VPC.  But there is nothing with regards to VHDX that will cause VPC to
> need to be tested.

Thanks for the confirmation.

--- Additional comment from Jeff Cody on 2013-05-07 16:02:55 EDT ---

VHDX read-only patches are in upstream 1.5.0-rc0:

http://wiki.qemu.org/ChangeLog/1.5#Block_devices
VHDX (MS Hyper-V) image format has initial read-only support. Dynamic and fixed sized disks are supported, but not differencing images (e.g. VHDX images with a backing file). Read-only is strictly enforced, and the 'readonly=on' option must be used for any VHDX images.



http://git.qemu.org/?p=qemu.git;a=commit;h=25565e8595322b04902a09ebf877d80532f22fd1

http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg00341.html

--- Additional comment from Richard W.M. Jones on 2013-05-10 09:32:58 EDT ---

I tried upstream qemu from git with two vhdx disk images.  One
was a blank disk, the other was a Fedora 18 guest, both were
created on Windows 2012 Server Hyper-V.

The blank disk image works fine.

The real guest disk image is suspicious.  It doesn't give I/O
errors, but it doesn't entirely work properly either.  I see
odd errors which seem to indicate that the virtual disk is
truncated:

[    0.520259] sd 2:0:0:0: [sda] 9838592 512-byte logical blocks: (5.03 GB/4.69 GiB)
...
[    0.526631]  sda: sda1 sda2
[    0.526961] sda: p2 size 40916992 extends beyond EOD, enabling native capacity
...
[    0.529179]  sda: sda1 sda2
[    0.530624] sda: p2 size 40916992 extends beyond EOD, truncated
...
  Reading all physical volumes.  This may take a while...
  Found volume group "fedora" using metadata type lvm2
[    1.384526] bio: create slab <bio-1> at 1
[    1.389517] device-mapper: table: 253:1: sda2 too small for target: start=4065280, len=36847616, dev_size=8812544
  device-mapper: resume ioctl on  failed: Invalid argument
  Unable to resume fedora-root (253:1)
  2 logical volume(s) in volume group "fedora" now active

The real virtual disk size is 20 GB.

That error of course stops the guest from working.  I can supply
the .vhdx file if that would help.

--- Additional comment from Richard W.M. Jones on 2013-05-10 09:36:05 EDT ---

http://oirase.annexia.org/tmp/f18x64.vhdx.xz

--- Additional comment from Richard W.M. Jones on 2013-05-10 10:27:38 EDT ---

/dev/sda is the .vhdx file (or more precisely, is a qcow2
file with the .vhdx file as backing).

/dev/sdb is the libguestfs appliance root disk.

--- Additional comment from Richard W.M. Jones on 2013-05-10 10:59:49 EDT ---

Comments 10-12 are a false alarm.  This turns out to be
a libvirt bug (or missing feature).  libvirt needs to be
extended with support for vhdx.

--- Additional comment from Dave Allan on 2013-06-26 05:01:49 EDT ---

Moving to 7.1 as this work is somewhat invasive and the PM score is low.

--- Additional comment from Dave Allan on 2013-06-26 05:09:48 EDT ---

(In reply to Dave Allan from comment #14)
> Moving to 7.1 as this work is somewhat invasive and the PM score is low.

Sorry, I meant to move the libvirt bug; I've reset this BZ to 7.0.

--- Additional comment from Jeff Cody on 2013-09-03 16:29:08 EDT ---

v5 posted upstream:
https://lists.gnu.org/archive/html/qemu-devel/2013-09/msg00594.html

--- Additional comment from Miroslav Rezanina on 2013-09-05 07:31:37 EDT ---

RHEL-6 patch not present in RHEL-7 related to this bz:

8e08515 spec: add vhdx to the read-only block driver whitelist