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:
-> 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 <py0xc3@xxxxxxxxxx>: ... 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 in https://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 PeterOn 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 pboy@xxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
