It looks as if virt-install simply passes this element to the libvirt
XML, so libvirt is the problem here.  I am using:

libvirt-daemon-3.4.0-1.fc27.x86_64

The XML generated by virt-install (found by --print-xml option) is
as follows.  I'm guessing the lack of a full path is the problem.

<domain type="qemu">
  <name>tmp</name>
  <uuid>f7c7c522-b64b-4d58-81e1-1cd6bd7cb8dd</uuid>
  <memory>2097152</memory>
  <currentMemory>2097152</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch="aarch64" machine="virt">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw</loader>
    <nvram>vars-template-pflash.raw</nvram>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
  </features>
  <cpu mode="custom" match="exact">
    <model>cortex-a57</model>
  </cpu>
  <clock offset="utc"/>
  <devices>
    <emulator>/usr/bin/qemu-system-aarch64</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/var/tmp/tmp"/>
      <target dev="sda" bus="scsi"/>
    </disk>
    <controller type="scsi" index="0" model="virtio-scsi"/>
    <interface type="user">
      <mac address="52:54:00:8a:2d:67"/>
      <model type="virtio"/>
    </interface>
    <console type="pty"/>
    <channel type="unix">
      <source mode="bind"/>
      <target type="virtio" name="org.qemu.guest_agent.0"/>
    </channel>
  </devices>
</domain>

You are using the --boot ...,nvram=$PATH options incorrectly.  The libvirt documentation states:

"Some UEFI firmwares may want to use a non-volatile memory to store some variables. In the host, this is represented as a file and the absolute path to the file is stored in this element."

The "absolute path to the file is stored in this element" is the important part of the documentation.

Well that sounds like a bug in virt-install.

There is no bug in any component.

From the Comment 1 the relevant part of virt-install command line is:

 "--boot loader=/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw,loader_ro=yes,loader_type=pflash,nvram=vars-template-pflash.raw"

Where you've provided relative path "vars-template-pflash.raw".

The Comment 2 shows the generated XML which correctly uses the provided path:

  <os>
    <type arch="aarch64" machine="virt">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw</loader>
    <nvram>vars-template-pflash.raw</nvram>
    <boot dev="hd"/>
  </os>

You need to use absolute path in order to get it work, virt-install will not expand the relative path to absolute path.

Rich, what are you trying to do exactly? Is 'vars-template-pflash.raw' just meant to be the generated nvram basename, or do you actually want it generated in $CWD, or something else?

Things we could fix: have libvirt reject a non-absolute path (which it should really do for a whole slew of cases like disk paths if it doesn't do that already), and/or have virt-install run os.path.abspath on the value like we do for --disk, or have virtinst reject a non absolute path

(In reply to Cole Robinson from comment #6)
> Rich, what are you trying to do exactly? Is 'vars-template-pflash.raw' just
> meant to be the generated nvram basename, or do you actually want it
> generated in $CWD, or something else?

No it's an existing file in the current working directory.

This worked in Fedora 25, it's just stopped working at some point
recently.

I pushed the abspath change to virt-manager:

commit b5c9321b0762b6a33a1ca5d20a4ab4bd4a16ad3e (HEAD -> master, origin/master, origin/HEAD)
Author: Cole Robinson <crobinso>
Date:   Mon Jul 17 09:16:45 2017 -0400

    osxml: run abspath on passed nvram value


But it would be interesting to test and see if an absolute path is still working as you expected or if there's some other regression.

It works.  I tested it using the reproducer (comment 0) against
the current master of virt-manager, just substituting ./virt-install
for the virt-install command.  Thanks.