[libvirt] exposing host-passthrough in virt-manager ui? (was: Re: [virt-tools-list] small suggestion)
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'. I don't personally don't have strong feelings against it but I've just followed the advice I've been given here. Things have changed quite a bit in the cpu config space in the past few years so maybe things are different. changing subject and ccing libvir-list for wider audience Thanks, Cole
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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
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? Thanks, Cole
On Wed, Feb 06, 2019 at 12:02:16PM -0500, Cole Robinson wrote:
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?
I'm not sure why we don't test it. The QEMU migration cookie XML could be made to include the host CPU model, so the target libvirtd could validate it during the prepare step. It wouldn't catch all possible screw ups, but would save you from the worst Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (2)
-
Cole Robinson -
Daniel P. Berrangé