[RFC] x86 Host CPU features detection by MSRs
Hello, This mail is a Request for Comment. On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures) are listed and controlled via the MSRs (Model Specific Registers) instead of the traditional CPUID instruction method. Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by the msr kernel module. src/cpu/cpu_x86.c: ... /* This is best effort since there might be no way to read the MSR * when we are not running as root. */ for (i = 0; i < nmsrs; i++) { if (virHostCPUGetMSR(msrs[i], &msr) == 0) { virCPUx86DataItem item = { .type = VIR_CPU_X86_DATA_MSR, .data.msr = { ... There are 2 potential issues: 1) As stated in the source code comment above, MSR values read might fail when libvirt is not run as root. 2) MSR values read might fail if the MSR kernel module is not loaded, this is still the case in some of the Linux distros. The issue 2) has been brought up in Ubuntu/Debian : https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/271 but the feedback was to try to fix the issue in the libvirt source code itself. Indeed, libvirt already loads some kernel modules it depends on. For example the NBD kernel module in src/util/virtfile.c ... static bool virFileNBDLoadDriver(void) { if (virKModIsProhibited(NBD_DRIVER)) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to load nbd module: administratively prohibited")); return false; } else { g_autofree char *errbuf = NULL; if ((errbuf = virKModLoad(NBD_DRIVER))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Failed to load nbd module")); ... Andrea Bolognani's proposal of an approach that could work: 1. try using the unprivileged KVM API is available (or maybe the necessary information is exposed via QMP too?) like how QEMU does; 2. if that fails, try using the privileged /dev API; 3. if that fails too, load the msr module and try again; I would like to have some feedback from the libvirt community about if that is worth tackling these issues and the right way to do that. If we can end up with an agreement in this mail thread, I can work on the solution implementation and send it in a separate submission. Best regards, Hector
On Wed, Jul 09, 2025 at 10:03:26AM +0200, Hector Cao wrote:
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures) are listed and controlled via the MSRs (Model Specific Registers) instead of the traditional CPUID instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by the msr kernel module.
src/cpu/cpu_x86.c: ... /* This is best effort since there might be no way to read the MSR * when we are not running as root. */ for (i = 0; i < nmsrs; i++) { if (virHostCPUGetMSR(msrs[i], &msr) == 0) { virCPUx86DataItem item = { .type = VIR_CPU_X86_DATA_MSR, .data.msr = { ...
There are 2 potential issues:
1) As stated in the source code comment above, MSR values read might fail when libvirt is not run as root. 2) MSR values read might fail if the MSR kernel module is not loaded, this is still the case in some of the Linux distros.
Neither of these should happen. virHostCPUGetMSR will try /dev/cpu/0/msr and if that fails to be opened, it should always fallback to /dev/kvm.
Andrea Bolognani's proposal of an approach that could work:
1. try using the unprivileged KVM API is available (or maybe the necessary information is exposed via QMP too?) like how QEMU does; 2. if that fails, try using the privileged /dev API;
Those steps need to be in the reverse order. /dev/kvm does not give full MSR information - it only reports a subset of MSRs.
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat. With 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 :|
Thanks Daniel, On Wed, Jul 9, 2025 at 10:17 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
Hello,
This mail is a Request for Comment.
On recent Intel CPUs, some of the CPU features (mostly vmx-* subfeatures) are listed and controlled via the MSRs (Model Specific Registers) instead of the traditional CPUID instruction method.
Right now, libvirt reads the MSR's values via /dev/cpu/*/cpu populated by the msr kernel module.
src/cpu/cpu_x86.c: ... /* This is best effort since there might be no way to read the MSR * when we are not running as root. */ for (i = 0; i < nmsrs; i++) { if (virHostCPUGetMSR(msrs[i], &msr) == 0) { virCPUx86DataItem item = { .type = VIR_CPU_X86_DATA_MSR, .data.msr = { ...
There are 2 potential issues:
1) As stated in the source code comment above, MSR values read might fail when libvirt is not run as root. 2) MSR values read might fail if the MSR kernel module is not loaded,
On Wed, Jul 09, 2025 at 10:03:26AM +0200, Hector Cao wrote: this
is still the case in some of the Linux distros.
Neither of these should happen. virHostCPUGetMSR will try /dev/cpu/0/msr and if that fails to be opened, it should always fallback to /dev/kvm.
My bad, I missed the fallback to /dev/kvm. Indeed, libvirt will fallback to use /dev/kvm if it cannot read /dev/cpu/* Let me check again why the fallback did not work for me, and report back (probably, the libvirt user does not belong to the kvm group ...)
Andrea Bolognani's proposal of an approach that could work:
1. try using the unprivileged KVM API is available (or maybe the necessary information is exposed via QMP too?) like how QEMU does; 2. if that fails, try using the privileged /dev API;
Those steps need to be in the reverse order. /dev/kvm does not give full MSR information - it only reports a subset of MSRs.
Got it. Thanks.
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Is this modules-load file deployed by libvirt itself or are you thinking it should be handled by the distro package ?
With 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 :|
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Is this modules-load file deployed by libvirt itself or are you thinking it should be handled by the distro package ?
I don't have a strong opinion either way on that. If it is broadly useful across multiple distros, it probably tends towards having it in libvirt upstream. With 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 Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully. The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible. -- Andrea Bolognani / Red Hat / Virtualization
On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully.
The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible.
IMHO an inability to read the msr info is a distro integration bug. Given the /dev/kvm fallback, the most common failure scenario will be on distros where /dev/kvm is restricted access. At that point though you can't run KVM enabled guests anyway, so the MSR problem is the least of your worries, as the info obtanied from MSRs is not especially relevant to TCG usage. With 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 Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully.
The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible.
IMHO an inability to read the msr info is a distro integration bug.
Given the /dev/kvm fallback, the most common failure scenario will be on distros where /dev/kvm is restricted access. At that point though you can't run KVM enabled guests anyway, so the MSR problem is the least of your worries, as the info obtanied from MSRs is not especially relevant to TCG usage.
Hello Daniel, You are right about the fallback. I did the verification on an Intel Granite Rapids (GNR) platform and the fallback to /dev/kvm works for me (under the condition that this issue is fixed : https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU... ) However, since you mentioned that /dev/kvm might be incomplete for MSR features (depending on the kernel version), do you consider it still useful to try to load the MSR module ? If that is the case, I can work on submitting something for that. With 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 :|
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
On Wed, Jul 23, 2025 at 08:15:25PM +0200, Hector Cao wrote:
On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
> 3. if that fails too, load the msr module and try again;
It seems like a modules-load file is simpler than having this manual kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully.
The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible.
IMHO an inability to read the msr info is a distro integration bug.
Given the /dev/kvm fallback, the most common failure scenario will be on distros where /dev/kvm is restricted access. At that point though you can't run KVM enabled guests anyway, so the MSR problem is the least of your worries, as the info obtanied from MSRs is not especially relevant to TCG usage.
Hello Daniel,
You are right about the fallback. I did the verification on an Intel Granite Rapids (GNR) platform and the fallback to /dev/kvm works for me (under the condition that this issue is fixed : https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU... )
However, since you mentioned that /dev/kvm might be incomplete for MSR features (depending on the kernel version), do you consider it still useful to try to load the MSR module ? If that is the case, I can work on submitting something for that.
I don't think we need code todo that, but if a modules-load file can do that, we could ship one. With 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 Fri, Jul 25, 2025 at 11:22 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 23, 2025 at 08:15:25PM +0200, Hector Cao wrote:
On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote:
> > 3. if that fails too, load the msr module and try again; > > It seems like a modules-load file is simpler than having this manual > kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully.
The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible.
IMHO an inability to read the msr info is a distro integration bug.
Given the /dev/kvm fallback, the most common failure scenario will be on distros where /dev/kvm is restricted access. At that point though you can't run KVM enabled guests anyway, so the MSR problem is the least of your worries, as the info obtanied from MSRs is not especially relevant to TCG usage.
Hello Daniel,
You are right about the fallback. I did the verification on an Intel Granite Rapids (GNR) platform and the fallback to /dev/kvm works for me (under the condition that this issue is fixed :
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU...
)
However, since you mentioned that /dev/kvm might be incomplete for MSR features (depending on the kernel version), do you consider it still useful to try to load the MSR module ? If that is the case, I can work on submitting something for that.
I don't think we need code todo that, but if a modules-load file can do that, we could ship one.
I see and agree What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/ Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ? - Do you think it is necessary to modify virt-host-validate to check if the msr module is loaded Best regards,
With 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 :|
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
On Fri, Jul 25, 2025 at 11:46:54AM +0200, Hector Cao wrote:
On Fri, Jul 25, 2025 at 11:22 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 23, 2025 at 08:15:25PM +0200, Hector Cao wrote:
On Wed, Jul 9, 2025 at 12:01 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Jul 09, 2025 at 05:58:03AM -0400, Andrea Bolognani wrote:
On Wed, Jul 09, 2025 at 09:53:40AM +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 09, 2025 at 10:29:32AM +0200, Hector Cao wrote: > > > 3. if that fails too, load the msr module and try again; > > > > It seems like a modules-load file is simpler than having this manual > > kmod load + repeat.
Well, we can perform the load unconditionally too. I was concerned that doing so would result in a failure on Fedora and other distros that have msr built-in, but I just tried and it seems that modprobe is smart enough to handle that scenario gracefully.
The other question is what to do if we can't read the msr information. It seems that right now we report the incorrect CPU model, which is obviously not ideal. Raising an error would probably be better, but I'm not sure whether the APIs are really designed in a way that makes that possible.
IMHO an inability to read the msr info is a distro integration bug.
Given the /dev/kvm fallback, the most common failure scenario will be on distros where /dev/kvm is restricted access. At that point though you can't run KVM enabled guests anyway, so the MSR problem is the least of your worries, as the info obtanied from MSRs is not especially relevant to TCG usage.
Hello Daniel,
You are right about the fallback. I did the verification on an Intel Granite Rapids (GNR) platform and the fallback to /dev/kvm works for me (under the condition that this issue is fixed :
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/XNOHU...
)
However, since you mentioned that /dev/kvm might be incomplete for MSR features (depending on the kernel version), do you consider it still useful to try to load the MSR module ? If that is the case, I can work on submitting something for that.
I don't think we need code todo that, but if a modules-load file can do that, we could ship one.
I see and agree
What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/
Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it.
- Do you think it is necessary to modify virt-host-validate to check if the msr module is loaded
I don't need to check the module directly, but we could do a simple path check for the MSR device node and add "load msr.ko" as a hint on failure With 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 Fri, Jul 25, 2025 at 11:10:15AM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 25, 2025 at 11:46:54AM +0200, Hector Cao wrote:
What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/
Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it.
The other thing to keep in mind is that the file needs to be shipped conditionally, on x86 only. Remind me again, why don't we just use virKModLoad() for this? It's functionality that already exists and can easily be reused, and it would make for an overall cleaner solution IMO. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Jul 25, 2025 at 04:30:40AM -0700, Andrea Bolognani wrote:
On Fri, Jul 25, 2025 at 11:10:15AM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 25, 2025 at 11:46:54AM +0200, Hector Cao wrote:
What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/
Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it.
The other thing to keep in mind is that the file needs to be shipped conditionally, on x86 only.
Remind me again, why don't we just use virKModLoad() for this? It's functionality that already exists and can easily be reused, and it would make for an overall cleaner solution IMO.
The modules-load.d file is processed at system startup in a well defined context. This is more appropriate than changing global system state in the middle of a libvirt API process to start a guest. With 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 :|
What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/
Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it.
The other thing to keep in mind is that the file needs to be shipped conditionally, on x86 only.
Remind me again, why don't we just use virKModLoad() for this? It's functionality that already exists and can easily be reused, and it would make for an overall cleaner solution IMO.
The modules-load.d file is processed at system startup in a well defined context. This is more appropriate than changing global system state in the middle of a libvirt API process to start a guest.
One thing I'm worried about with modules-load.d approach is that at libvirt installation, the module is not actually loaded, a reboot is necessary to make it happen.
With 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 :|
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
On Fri, Jul 25, 2025 at 01:45:51PM +0200, Hector Cao wrote:
What do you think of this design: 1) Create a file msr.conf inside src/util/modules-load.d/ 2) Modify src/util/meson.build to install this file to /etc/modules-load.d/
Optional: - Do you think it is necessary to add the configuration option to enable this modules-load file installation ?
We should probably have a meson_options.txt entry as some distros have it as a built-in, so it would be wierd to see a file installed to load it.
The other thing to keep in mind is that the file needs to be shipped conditionally, on x86 only.
Remind me again, why don't we just use virKModLoad() for this? It's functionality that already exists and can easily be reused, and it would make for an overall cleaner solution IMO.
The modules-load.d file is processed at system startup in a well defined context. This is more appropriate than changing global system state in the middle of a libvirt API process to start a guest.
One thing I'm worried about with modules-load.d approach is that at libvirt installation, the module is not actually loaded, a reboot is necessary to make it happen.
You need that to make systemd service activation happen too, so the need for a reboot isn't new. With 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 Fri, Jul 25, 2025 at 01:25:47PM +0100, Daniel P. Berrangé wrote:
On Fri, Jul 25, 2025 at 01:45:51PM +0200, Hector Cao wrote:
One thing I'm worried about with modules-load.d approach is that at libvirt installation, the module is not actually loaded, a reboot is necessary to make it happen.
You need that to make systemd service activation happen too, so the need for a reboot isn't new.
Unlike Fedora/RHEL, on Debian/Ubuntu services are automatically started right after the package is installed. So a reboot is generally not needed. -- Andrea Bolognani / Red Hat / Virtualization
Hello Andrea, Daniel, I would like to understand how we can give some momentum to this topic, @Daniel P. Berrangé <berrange@redhat.com> : Are you still convinced that libvirt should only deploy the modules-load.d file as part of the installation ? If we take this route, one solution to work-around the reboot need is to call the /usr/lib/systemd/systemd-modules-load binary on the installed conf file (example : /usr/lib/systemd/systemd-modules-load /etc/modules-load.d/msr.conf) at installation. If you both agree on this design, I will go ahead and submit something. On Fri, Jul 25, 2025 at 3:48 PM Andrea Bolognani <abologna@redhat.com> wrote:
On Fri, Jul 25, 2025 at 01:45:51PM +0200, Hector Cao wrote:
One thing I'm worried about with modules-load.d approach is that at
On Fri, Jul 25, 2025 at 01:25:47PM +0100, Daniel P. Berrangé wrote: libvirt
installation, the module is not actually loaded, a reboot is necessary to make it happen.
You need that to make systemd service activation happen too, so the need for a reboot isn't new.
Unlike Fedora/RHEL, on Debian/Ubuntu services are automatically started right after the package is installed. So a reboot is generally not needed.
-- Andrea Bolognani / Red Hat / Virtualization
-- Hector CAO Software Engineer – Partner Engineering Team hector.cao@canonical.com https://launc <https://launchpad.net/~hectorcao>hpad.net/~hectorcao <https://launchpad.net/~hectorcao> <https://launchpad.net/~hectorcao>
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Hector Cao