Comment 46 for bug 1561019

(In reply to Richard W.M. Jones from comment #27)
> (In reply to Zeeshan Ali from comment #26)
> > Any update on this? We moved from 'host-model' to 'host-passthrough' to
> > avoid this in Boxes and only now realized that that breaks support of
> > non-KVM CPUs. :(
>
> Still a bug. It only happens on certain hardware (which
> unfortunately I own) so it's rather hard to reproduce.
>
> You should use host-passthrough, but disable it when the
> <domain type="qemu">. This is the logic used by libguestfs:
>
> https://github.com/libguestfs/libguestfs/blob/master/src/launch-libvirt.
> c#L1012

Hmm.. Ah thanks. So by 'disable' you mean you just leave the model to libvirt? I was thinking of following the advice in libvirt docs:

"Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work. Until these issues are fixed, it's a good idea to avoid using host-model and use custom mode with just the CPU model from host capabilities XML."

> I would say your biggest problem with using host-passthrough
> is surely that live migration doesn't work? (Of course we
> don't care about that in libguestfs)

It certainly would be nice to have 'live migration' since Boxes always suspends VMs on exit and if you change your CPU in between, your only choice is to loose the saved state (which could easily mean lose of important data) but thats not currently my issue. Boxes unable to start the created VM on on-kvm hosts, is. :)