On 2/6/19 10:57 AM, Pavel Hrdina wrote: > On Wed, Feb 06, 2019 at 10:20:38AM -0500, Cole Robinson wrote: > > On 2/5/19 6:19 PM, Hetz Ben Hamo wrote: > > > Is it possible to add in the virt-manager the "host-passthrough" to the > > > CPU models please? > > > > > > > You can type 'host-passthrough' into the field and it will work. The reason > > we don't advertise it is because it's considered to have some mild > > supportability issues with libvirt. For the vast majority of use cases > > though it's completely fine > > Maybe we can reconsider this decision, the only thing that would not > work is live migration to destination with different CPU and we can > have a warning/info about it in the UI. > > Possibly we could allow to set 'host-passthrough' as the default guest > CPU in virt-manager config. > Nowadays with host-model being much smarter, is there much functional difference between host-model and host-passthrough? I don't really know the answer. > Most workstation/desktop users of virt-manager probably doesn't care > about live migration and it would copy the host CPU as closely as > possible. Since we allow to manually type in 'host-passthrough' I > personally don't see any reason why it cannot be selectable. > The problem I see is that host-passthrough sets the libvirt 'taint' flag on the VM. While it doesn't have any real impact on end users generally I took that to mean 'you are doing something that is unsupported'.

On 2/6/19 11:34 AM, Daniel P. Berrangé wrote: > On Wed, Feb 06, 2019 at 11:22:01AM -0500, Cole Robinson wrote: > > On 2/6/19 10:57 AM, Pavel Hrdina wrote: > > > On Wed, Feb 06, 2019 at 10:20:38AM -0500, Cole Robinson wrote: > > > > On 2/5/19 6:19 PM, Hetz Ben Hamo wrote: > > > > > Is it possible to add in the virt-manager the "host-passthrough" to the > > > > > CPU models please? > > > > > > > > > > > > > You can type 'host-passthrough' into the field and it will work. The reason > > > > we don't advertise it is because it's considered to have some mild > > > > supportability issues with libvirt. For the vast majority of use cases > > > > though it's completely fine > > > > > > Maybe we can reconsider this decision, the only thing that would not > > > work is live migration to destination with different CPU and we can > > > have a warning/info about it in the UI. > > > > > > Possibly we could allow to set 'host-passthrough' as the default guest > > > CPU in virt-manager config. > > > > > > > Nowadays with host-model being much smarter, is there much functional > > difference between host-model and host-passthrough? I don't really know the > > answer. > > > > > Most workstation/desktop users of virt-manager probably doesn't care > > > about live migration and it would copy the host CPU as closely as > > > possible. Since we allow to manually type in 'host-passthrough' I > > > personally don't see any reason why it cannot be selectable. > > > > > > > The problem I see is that host-passthrough sets the libvirt 'taint' flag on > > the VM. While it doesn't have any real impact on end users generally I took > > that to mean 'you are doing something that is unsupported'. > > We should probably remove that, or at least only taint /after/ a live > migration. > Okay, interesting. I filed an upstream libvirt bug to track that: https://bugzilla.redhat.com/show_bug.cgi?id=1673098 I was under the impression migration is rejected for cpu mode=host-passthrough but that doesn't seem to be the case. Is the issue that since libvirt doesn't know the full CPU config, we can't validate the remote host supports the CPU, so migration could appear to succeed but then the guest will malfunction on the new host?