Eduardo Habkost <ehabk...@redhat.com> writes: > > If libvirt is involved, it's much simpler and safer to use > something like <cpu mode="host-model">, which generates a > migration-safe CPU configuration based on the current host. Live > migration support with "-cpu host" is only useful for experiments > and carefully controlled environments. > > Is there a real need to make hv-all migratable? What would be > the use case, exactly? If there's no clear use case, I would > recommend making it a migration blocker.
There's no clear use-case; I noticed that we keep adding Hyper-V enlightenments and these make Windows' life on KVM easier so we recommend enabling them all (and, with an exception for hv-evmcs, which I also don't enable with hv-all, I'm unawere of cases which would require disabling certain Hyper-V enlightenments). hv-all is mostly a convenience feature. I plan to take a look at 'host-model' to see if we can borrow some ideas from there (that would actually be ideal - build a set of 'hv-*' enlightenments based on capabilites of the current host) but I'm also not totally against keeping it the way it is and making it a migration blocker for the time being (and making it a 'developer-only' feature). -- Vitaly
