The cause is because virt-v2v is looking for:

/usr/share/OVMF/OVMF_CODE.fd
/usr/share/OVMF/OVMF_VARS.fd

but this package provides:

/usr/share/OVMF/OVMF_CODE.secboot.fd
/usr/share/OVMF/OVMF_VARS.fd

There was some discussion about this change in email, but I can't recall
what we concluded now, or indeed where we discussed it.

I read back all the threads, and there are some things I'm not clear about.

Assume first of all that we don't care at all about secure boot, and
even if we did and if we had a way to tell that the source was using
secure boot originally, we have no way to copy the keys from the source
guest / physical machine and write them to the p2v/v2v output files.

Do we still need to set the Q35 machine type, even though we are
not going to be using secure boot?  Currently we don't specify a
machine type in the libvirt XML output, so (I believe) libvirt
will always choose i440fx.

Do we still need to set smm=on, given the above?

Do we still need to set @secure attribute of the loader?

These are good questions. Let me clarify:

(1) We have to distinguish the Secure Boot Feature from the Secure Boot Mode. The former is a static characteristic (a build time decision) about the firmware binary. The latter is a persistent, but dynamically configurable characteristic of an individual virtual machine.

When you mention keys / certificates, those relate to Secure Boot Mode. However, at this time we are discussing the Secure Boot Feature.

(Obviously, Secure Boot Mode can only be enabled if the Secure Boot Feature was built into the firmware binary!)

(2) When building OVMF, the Secure Boot Feature can be enabled with

  -D SECURE_BOOT_ENABLE

And, when building OVMF, the SMM driver stack can be enabled with

  -D SMM_REQUIRE

First, these build options are orthogonal -- you may pick neither, either, or both.

If you pick "-D SECURE_BOOT_ENABLE", then the Secure Boot Feature will be built into the binary, and the guest will be able to enroll keys / certificates, and enable the Secure Boot Mode.

If you pick "-D SMM_REQUIRE", then the SMM driver stack will be built into the firmware. This driver stack presents *mandatory* requirements for the underlying QEMU/KVM platform, which are only satisfied by recent enough Q35 machine types, and host kernels. This is why the option name is SMM_REQUIRE, and not SMM_ENABLE -- once you build it in, SMM support is *required* from the hypervisor, and not optional. There are two reasons for this: first, edk2 doesn't support dynamic switching between SMM and no-SMM, second, SMM is a security feature, and silently downgrading it to no-SMM (due to lack of hypervisor support for SMM) would be a security vulnerability.

(3) If you pass -D SECURE_BOOT_ENABLE to the build *without* -D SMM_REQUIRE, then the Secure Boot related software interfaces will be available, and a benign / well-behaving guest will see the Secure Boot Feature as available. However, without the SMM driver stack, it won't be *actually* secure; a malicious guest OS can break through the OS <-> guest firmware barrier, by directly programming the pflash chip that contains the authenticated UEFI variables.

This is prevented by adding -D SMM_REQUIRE to the build. That is, for "production purposes", OVMF's Secure Boot Feature can only be called "secure" if OVMF was built with

  -D SECURE_BOOT_ENABLE -D SMM_REQUIRE

We decided to only ship an OVMF binary that was built like this. Corollary: it won't run on i440fx even if you don't want to enable the Secure Boot Mode in the guest.

(4) Libvirt exposes two configuration items, the <smm> feature under <features>, and the @secure attribute for <loader>.

<smm> enables or disables SMM support in the hypervisor in general. (This can be used for different things than OVMF as well.)

@secure instructs QEMU to enforce the pflash chip protection (so that only code running in SMM can program it), and this setting (therefore) depends on <smm> being present as well.

In this sense, libvirt's @secure attribute corresponds to the "actually secure", "production" definition from (3).

(5) As an end-result, *in RHEL-7.3* the libvirt knobs / machine type / etc cannot be avoided.

For upstream users, it is perfectly fine to use i440fx, assuming their OVMF binary was built with one of the following sets of build options:

- none of "-D SECURE_BOOT_ENABLE" and "-D SMM_REQUIRE"
- "-D SECURE_BOOT_ENABLE" only

Does this help?

That's great, thanks Laszlo.

Fixed upstream in:
https://github.com/libguestfs/libguestfs/commit/0c396650b0018dc3fcd7ca809202ad46ae2c327d
https://github.com/libguestfs/libguestfs/commit/913dd8a087597f4d9fc658fb75813148107ff72e

Verify this bug with below builds:
virt-v2v-1.32.7-2.el7.x86_64
libguestfs-1.32.7-2.el7.x86_64
kernel-3.10.0-493.el7.x86_64
libvirt-2.0.0-5.el7.x86_64
virtio-win-1.8.0-5.el7.noarch
OVMF-20160608-3.git988715a.el7.noarch
qemu-kvm-1.5.3-121.el7.x86_64


Steps:

1.Install OVMF package on conversion server
#yum install http://download.eng.bos.redhat.com/brewroot/packages/ovmf/20160608/3.git988715a.el7/noarch/OVMF-20160608-3.git988715a.el7.noarch.rpm

2.Convert uefi guest from vmware to libvirt
# virt-v2v -ic vpx://root.145.47/data/10.73.3.19/?no_verify=1 juzhou-test-efi -of qcow2 --password-file /tmp/passwd
[   0.0] Opening the source -i libvirt -ic vpx://root.145.47/data/10.73.3.19/?no_verify=1 juzhou-test-efi
[   0.8] Creating an overlay to protect the source from being modified
[   1.5] Initializing the target -o libvirt -os default
[   1.5] Opening the overlay
[  23.0] Inspecting the overlay
[  83.2] Checking for sufficient free disk space in the guest
[  83.2] Estimating space required on target for each disk
[  83.2] Converting Windows Server 2012 R2 Standard to run on KVM
virt-v2v: warning: there is no QXL driver for this version of Windows (6.3 
x86_64).  virt-v2v looks for this driver in /usr/share/virtio-win

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  93.4] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/sda2 failed.  Usually 
you can ignore this message.  To find out more read "Trimming" in 
virt-v2v(1).

Original message: fstrim: fstrim: /sysroot/: the discard operation is not 
supported
[  94.0] Closing the overlay
[  94.0] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[  94.0] Assigning disks to buses
[  94.0] Copying disk 1/1 to /var/lib/libvirt/images/juzhou-test-efi-sda (qcow2)
    (100.00/100%)
[ 596.7] Creating output metadata
Pool default refreshed

Domain juzhou-test-efi defined from /tmp/v2vlibvirtb2b963.xml

[ 597.1] Finishing off

Result now:
OVMF file which is built for rhel7.3 can be used for virt-v2v uefi conversion now


So move this bug from ON_QA to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2576.html