Description of problem:
If the name in the top-level metadata section of a VirtualMachine definition does not match the name defined in the metadata of the 'template' section of the definition, both a VM and VMI will be created but with different names. 

This prevents the controller from reconciling the VM to the running VMI. The VM will be stuck in a pending state, even though the VMI is fine.



Version-Release number of selected component (if applicable):
OpenShift virtualization 2.3

How reproducible:
Always

Steps to Reproduce:
1. Create a template where the metadata's do not match:

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: myfriendlyvmname
spec:
<...>
  running: true
  template:
    metadata:
      name: someothevmname
    spec:
      domain:
        resources:
<...>
2. oc create -f <vm file>


Actual results:
oc get vm reports:

  Warning  FailedCreate                41s (x17 over 61s)  virtualmachine-controller  Error creating virtual machine instance: The POST operation against VirtualMachineInstance.kubevirt.io could not be completed at this time, please try again.

The virt-controller logs show its confusion:

{"component":"virt-controller","kind":"","level":"info","msg":"Failed to create VirtualMachineInstance: /","name":"myfriendlyvmname","namespace":"default","pos":"vm.go:641","service":"http","timestamp":"2020-05-08T21:36:37.043785Z","uid":"bfde9daa-2bdf-44b6-bca3-9ad83fd9ab42"}
{"component":"virt-controller","kind":"","level":"error","msg":"Creating the VirtualMachine failed.","name":"myfriendlyvmname","namespace":"default","pos":"vm.go:265","service":"http","timestamp":"2020-05-08T21:36:37.043848Z","uid":"bfde9daa-2bdf-44b6-bca3-9ad83fd9ab42"}
{"component":"virt-controller","kind":"","level":"info","msg":"Reason to fail: FailedCreate","name":"myfriendlyvmname","namespace":"default","pos":"vm.go:1225","service":"http","timestamp":"2020-05-08T21:36:37.043887Z","uid":"bfde9daa-2bdf-44b6-bca3-9ad83fd9ab42"}
{"component":"virt-controller","level":"info","msg":"reenqueuing VirtualMachineInstance default/someothevmname","pos":"vmi.go:201","reason":"Operation cannot be fulfilled on virtualmachineinstances.kubevirt.io \"someothevmname\": the object has been modified; please apply your changes to the latest version and try again","service":"http","timestamp":"2020-05-08T21:36:37.058788Z"}
{"component":"virt-controller","level":"info","msg":"re-enqueuing VirtualMachine default/myfriendlyvmname","pos":"vm.go:143","reason":"The POST operation against VirtualMachineInstance.kubevirt.io could not be completed at this time, please try again.","service":"http","timestamp":"2020-05-08T21:36:37.061318Z"}
{"component":"virt-controller","level":"info","msg":"reenqueuing VirtualMachineInstance default/someothevmname","pos":"vmi.go:201","reason":"Operation cannot be fulfilled on virtualmachineinstances.kubevirt.io \"someothevmname\": the object has been modified; please apply your changes to the latest version and try again","service":"http","timestamp":"2020-05-08T21:36:37.067814Z"}


(note the different names)

The result is VM myfriendlyvmname is in a pending state, while VMI someothevmname is running fine.

Expected results:
VM resultant VMI are created and associated with each other

Additional info:

Not sure if this is a template validation issue, or a doc issue. Omitting a name in the metadata section of the VM template also works fine, since it must inherit from the top-level spec. It seems optional, put possible to override in the VM template and cause a bit of a split-brain.

Perhaps a name shouldn't be allowed in the VM template's metadata?