The CPU model shown is

  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Haswell-noTSX</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='rdrand'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='abm'/>
  </cpu>


The Haswell-noTSX model does not include 'vmx' and nor is it listed explicitly. So this is simply a configuration problem.

I don't know whether virt-manager explicitly leaves out vmx or not.

Is it really problem of virt-manager, when the cpu tag looks like

  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

before the VM is started and is changed to the block mentioned in comment 1 only for the time of run of the VM? Or am I missing something?

It looks like replacing block mentioned in comment 2 by

  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Haswell-noTSX</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='vmx'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='rdrand'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='abm'/>
  </cpu>

when VM is down is a workaround (for Haswell-noTSX CPUs).

Moving back to libvirt since this has nothing to do with virt-manager.  Libvirt is the one who replaces the

  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

with

  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>Haswell-noTSX</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vme'/>
    <feature policy='require' name='ss'/>
    <feature policy='require' name='f16c'/>
    <feature policy='require' name='rdrand'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='arat'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='xsaveopt'/>
    <feature policy='require' name='pdpe1gb'/>
    <feature policy='require' name='abm'/>
  </cpu>

What happens with libvirt is that you've probably started libvirtd before the
nested virtualization was enabled.  To speedup libvirtd startup it caches
capabilities into "/var/cache/libvirt/qemu/capabilities/" and these cached
capabilities are valid until you update/downgrade libvirt/qemu.

Even though you've enabled nested virtualization the cached capabilities are
still valid, because there was no change of libvirt/qemu binaries, libvirt uses
these cached capabilities where "vmx" feature is marked as unavailable.

To fix this issue you can simply remove all files inside the cache folder
"/var/cache/libvirt/qemu/capabilities/" and restart libvirtd.  After this step
the:

  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

should work as expected.

(In reply to Pavel Hrdina from comment #5)
> What happens with libvirt is that you've probably started libvirtd before the
> nested virtualization was enabled.  To speedup libvirtd startup it caches
> capabilities into "/var/cache/libvirt/qemu/capabilities/" and these cached
> capabilities are valid until you update/downgrade libvirt/qemu.
> 
> Even though you've enabled nested virtualization the cached capabilities are
> still valid, because there was no change of libvirt/qemu binaries, libvirt
> uses
> these cached capabilities where "vmx" feature is marked as unavailable.
> 
> To fix this issue you can simply remove all files inside the cache folder
> "/var/cache/libvirt/qemu/capabilities/" and restart libvirtd.  After this
> step
> the:
> 
>   <cpu mode='host-model' check='partial'>
>     <model fallback='allow'/>
>   </cpu>
> 
> should work as expected.

I had the same issue. I can verify that this solution works. Clearing the cache worked for me.

Deleting files in "/var/cache/libvirt/qemu/capabilities/" and restarting libvirtd as mentioned in comment 5 works for me as well.

By 'enabling nested' are you guys talking about the /etc/modprobe.d/kvm.conf kvm_intel nested=1 bit? If so, seems like this is going to be a recurring problem that would be nice to find a fix, but not sure how we are going to know to recache CPU data when a module parameter changes...

Hi Cole, yes 'enabling nested' refers to re-inserting kvm_intel module with 'nested' bit set, provided host CPU already has virtualization enabled in BIOS. A solution checking could be checking '/sys/module/kvm_intel/parameters/nested' and invalidating cache in case of change.

In any case it is worth documenting that one needs to delete the cache once the module is reinserted. I find that quite difficult to expect.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.