I have just checked current Docs of libvirt (which I consider most
representative/relevant) about host-passthrough and host-model (and a
related SuSE page for comparison with RHEL concerning host-passthrough):
host-passthrough/-model are still different and both are what they used
to be.
Concerning host-passthrough etc. see:
https://libvirt.org/formatdomain.html
https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-libvirt-config-virsh.html
-> concerning host-passthrough, both can be transferred to your Quick
Docs article about nested virt -> the considerations about
host-passthrough/-model are the same.
Be aware that host-passsthrough is not a real hardware passthrough like
pci-passthrough. It only imitates the exact host CPU. Therefore, it is a
passthrough of "hardware properties/behavior", not of hardware itself.
You could also argue that host-passthrough = "imitation". This has
positive performance outcomes: better CPU performance for the guest, and
less emulation overhead for the host. The general performance advantages
are the reason why I disagree with the second sentence of the current
Note box (see my last mail).
Concerning the migration issue: the issue applies mostly to environments
that contain extraordinary CPUs, and are critical, complex and/or
automated and need to provide constant predictable hardware behavior
(which therefore, has to be officially supported and explicitly tested).
Fedora is not intended for critical infra anyway. Additionally, the
issue is increasingly likely to apply to those who further customize the
host-passthrough in the configuration file.
Maybe you can add a Note box that makes somehow aware of the following:
generally, you can say with host-passthrough, the migration issue for
the guest is mostly equal to the migration issue of the host: the CPU
has changed, so everything that runs on top of that CPU has to adjust
correspondingly. Mainstream guests possibly do not even care and are
able to tailor automatically at boot (but I guess a paused VM should not
be migrated while at pause, including snapshots of running systems :).
ADDITION: depending on the host-passthrough configuration, it might be
possible that it becomes necessary to adjust the xml config file when
the host CPU changes (might apply mostly to those who customized the
configuration file). Adjustments, if necessary, should be easy and are
not "nested virtualization" specific.
The point of libvirt's bug warning is: host-passthrough imitates exactly
what the host CPU does/contains, not what has been explicitly
tested/integrated in the software. This means that the user can enter
formally untested grounds. You can make the user aware that
host-passthrough-based "testing" of VM that has been conducted on one
CPU cannot be automatically transferred to another CPU. On mainstream
hardware, I have never experienced or seen an issue since libvirt/kvm
have reached "maturity", but formally, the point might be noted for
cases where the hardware is not fully known by the virt software. But be
careful to not "threaten" users, since in most cases, host-passthrough
should work properly... Since the "audience level" might be comparable,
feel free to let yourself inspire by the RHEL and SuSE Docs when it
comes to what to mention and what not.
My arguments about host-passthrough/-model are valid. But I cannot help
with modprobe <-> nested virtualization: for that, I suggest to search
for topics on ask.fedora and if necessary, open a topic there. We had
nested virtualization topics in the past, so maybe someone there can
help you with that.
Cheers,
Chris
On 28/12/2022 09:34, Peter Boy wrote:
Hi Chris,
Am 27.12.2022 um 23:01 schrieb Christopher Klooz<py0...@my.mail.de>:
...
The Red Hat Docs you refer to differ to the Quick Docs page: see 1. II. of the
procedures of both Intel and AMD at the RHEL link (as you indicated, it seems
that RHEL 9 has not yet anything online about the topic, at least not on the
publicly available pages).
Yes, the RHEL documentation is more specific. However, there remains the
inconsistency regarding the information in the /etc/modprobe.d/kvm.conf file in
Fedora (don’t know if it exist in RHEL, too). Is this a remnant of old ways of
configuration or some kind of fallback? It would be helpful to get some
information about this.
The RHEL8 Docs page makes use only of "host-passthrough", whereas the Quick Docs article seems to assume that "host-passthrough" and
"host-model" are equal and thus, the user can use any of the two without a difference. At least as I was working with that the last time (maybe
something has changed? * ), these were two different things (host passthrough <-> host model), and for performance reasons, I suggest to stick with
"host-passthrough" and not "host-model" in the nested use case, except there is clear indication towards the other (see the openstack
link below for an example). At least, the quick docs article should make clear the difference if it also notes "host-model". Or alternatively,
duplicate the RHEL8 Docs page approach and refer only to "host-passthrough", which makes most sense for that use case imho.
Additionally, I disagree a bit with the "Note" box
inhttps://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/#proc_configuring-nested-virtualization-in-virt-manager
" Using host-passthrough is not recommended for general usage. It should only be
used for nested virtualization purposes."
I am not sure if nested virtualization is the only reason to enable host-passthrough. So
at least the second sentence ("It should only be used for nested virtualization
purposes") should be removed imho. I think implicit assumptions should be avoided at
all.
Concerning the difference of host-passthrough and host-model, the following link contains some information about the
two that corresponds to what I know:https://wiki.openstack.org/wiki/LibvirtXMLCPUModel (just search on that page for
"host-passthrough" and "host-model"). If you search on the Internet for further information, be
aware that the terms "host-passthrough" and "pci-passthrough" are not synonymous (you will maybe
get many pages about both when querying a search machine about one of them).
Question is, what are the disadvantages of passthrough?
The OpenStack article only mentions that migration to other hardware is limited to the
exact processor model. I haven't worked on this topic for a long time, but "in the
past" the hardware proximity of the VMs led to general performance losses of the
overall system. But that may no longer be true today, both in general and for this
particular case.
Again, it would be helpful to get valid information.
Thanks
Peter
On 27/12/2022 12:59, Peter Boy wrote:
In order to use nested virtualization, Fedora Quick Docs[1] advises to activate
that feature in the host kernel using modprobe and editing the file
/etc/modprobe.d/kvm.conf. The comment in this file provides the same
information. Additionally, you are to configure the processor of the VM hosting
a nested VM as passthrough. The RHEL 8 documentation [2] provides the same
information as various articles on other Web pages. In RHEL 9 documentation I
couldn’t find anything about this. Additionally, you are to configure the
processor of the VM hosting a nested VM as passthrough.
According to my findings these informations seem to be obsolete or in need of
supplementation. At least everything works fine without any additional
configuration at all (at least if the host processor as well as the processor
configured in the VM support virtualization).
The Fedora docs team is in the process to check and update Fedora documentation.
It would be really helpful if someone with more technical knowledge about that
matter than me would provide me with more detailed information und maybe links
to current information. Even better if someone familiar with the matter would
be willing to review an updated article.
[1]https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/
[2]https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_virtualization/creating-nested-virtual-machines_configuring-and-managing-virtualization
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
_______________________________________________
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
