From the %post macro inside a kickstart file, I was able to get the latest libvirt* packages to install into CentOS 8.2, using the following:

# Install newer virt pkgs from advanced-virtualization repo
echo "module_hotfixes=true" >> /etc/yum.repos.d/advanced-virtualization.repo
yum clean all
yum -y --nogpgcheck group upgrade virtualization-client virtualization-hypervisor virtualization-tools


However, this seems like a real hackish way of dealing with it.

Hmm, this is not a bug in libvirt, it's more about the way libvirt or rather
the whole virt module is shipped. Danilo, can you help with this either
directly or by pointing to someone who can help?

For virt module on rhel8.2, there are 2 streams, one is virt:rhel provides libvirt with * 4.5.*, another is virt:8.2 provides libvirt with *6.0.0*. And the virt:rhel is enabled by default, this is why we can only install libvirt with version "4.5" by default. To update the default setting, you can:

1) run "yum module reset virt -y" to clear the default setting and make them not disabled or enabled;
2) run "yum module install virt:8.2 -y" directly;

or 
1) run "yum module reset virt -y" to clear the default setting;
2) run "yum module enable virt:8.2 -y";
3) run "yum module install virt -y"

(In reply to Jiri Denemark from comment #2)
> Hmm, this is not a bug in libvirt, it's more about the way libvirt or rather
> the whole virt module is shipped. Danilo, can you help with this either
> directly or by pointing to someone who can help?

Understood.  My apologies for putting it in the wrong category.

(In reply to yalzhang from comment #3)
> For virt module on rhel8.2, there are 2 streams, one is virt:rhel provides
> libvirt with * 4.5.*, another is virt:8.2 provides libvirt with *6.0.0*. And
> the virt:rhel is enabled by default, this is why we can only install libvirt
> with version "4.5" by default. To update the default setting, you can:
> 
> 1) run "yum module reset virt -y" to clear the default setting and make them
> not disabled or enabled;
> 2) run "yum module install virt:8.2 -y" directly;
> 
> or 
> 1) run "yum module reset virt -y" to clear the default setting;
> 2) run "yum module enable virt:8.2 -y";
> 3) run "yum module install virt -y"


Right, I understand this is how you'd do it post-install.  However, my ticket was about kickstart.  What is the supported method of achieving this inside of a kickstart?  In a massive server farm, I want all the servers to come up fully, correctly installed, rather than doing a lot of post-boot fixups.


My second problem with this solution is that, for CentOS 8.2 at least, it doesn't work.  There is no virt:8.2 module:

[root@gputest ~]# yum module reset virt -y
Last metadata expiration check: 0:00:39 ago on Wed 24 Jun 2020 08:46:29 AM EDT.
Dependencies resolved.
===============================================================================================================================================
 Package                           Architecture                     Version                            Repository                         Size
===============================================================================================================================================
Resetting modules:
 virt                                                                                                                                         

Transaction Summary
===============================================================================================================================================

Complete!

[root@gputest ~]# yum module list virt
Last metadata expiration check: 0:03:32 ago on Wed 24 Jun 2020 08:46:29 AM EDT.
AppStream
Name                          Stream                           Profiles                           Summary                                      
virt                          rhel [d]                         common [d]                         Virtualization module                        

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled


[root@gputest ~]# yum module enable virt:8.2 -y
Last metadata expiration check: 0:00:49 ago on Wed 24 Jun 2020 08:46:29 AM EDT.
Error: Problems in request:
missing groups or modules: virt:8.2

It works a bit differently in CentOS as the virt:8.* module is built for Virt
SIG as advanced-virtualization. And since Danilo is building this, he might
know how to properly consume the bits.

UPDATE:  so my apologies, but there does in fact seem to be a supported way of manipulating modules inside kickstart, as per section B.3.7. "module" of this guide: 

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_an_advanced_rhel_installation/kickstart-commands-and-options-reference_installing-rhel-as-an-experienced-user#module_kickstart-commands-for-system-configuration


So the only real issue that remains is that, for CentOS, the virt module appears to be broken for the 'advanced-virtualization' stream (i don't know if I'm using the right syntax yet, this is still so new to me).  But as I described above, there's no virt:8.* visible to us; unless I'm also doing that wrong.

Moving to distribution component for further discussion.

Jeff - this has been dormant now for a bit too long and seems it should end up with someone on your team or perhaps even be transferred to a different team for resolution per Danilo's comment 9.

So, there are at least three options

1- OP has to live with the fact that modularity is broken and keep using module_hotfix=true
2- We assign this to the DNF team to allow the instalation of a package with a higher NVR, at least when the available module stream are disabled.
3- We ask for modularity support for SIGs and then create a virt module there.

From my perspective: OP will have to deal with option 1 for the foreseeable future, no matter what.
Then we should pursue option two. Reassign this to DNF and expect them to provide a fix for this. Depending on how this is implemented, could be our way out of modularity.
But, as far as I know, this was mentioned as one of those 'by design' decisions that dnf/modularity won't change.

As for option 3: I don't even know who takes care of the build tools in centos, but my instinct tells me that want less modularity/modules, not more.

Summary: cannot override modular content with non-modular content
or
Summary: cannot build modular content with CentOS SIG build process

Problem: In CentOS, the virt:rhel stream contains qemu-kvm, libvirt and other components. The Advanced Virtualization stream, however, cannot be built in CentOS due to the fact that the CentOS SIG builds do not support modules. This forces the Advanced Virtualization SIG to build it's qemu-kvm, libvirt and other components outside of a module. But, these components do not override the modular content that is in the virt:rhel stream, even when the virt:rhel stream is disabled.

Solution 1: when a stream is disabled, dnf should allow the non-modular content to be selected
Solution 2: enhance the CentOS SIG build process to build modular content

Note that both solutions are independent and can--and probably should--coexist.

I'm going to reassign this to the dnf team for additional investigation for solution 1.

(In reply to Jonathan Mills from comment #7)
> But as I described above, there's no virt:8.* visible to us; unless I'm also doing that wrong.

Could you try disabling 'virt:rhel' stream and try again?
Disabling the stream should make the non-modular packages available again.

I am really sorry, I set needinfos without a proper explanation. I realized that in Comment 13 the question `Could you try disabling 'virt:rhel' stream and try again?` was asked without needinfo.

Did the suggestion from Comment 13 resolved your issue?

Hi Jaroslav,

Thanks for clarifying the needinfo. I'll let the original reporter, Jonathan Mills, answer the question that was asked in comment 13.

Not kicksart, but this helped me get past "missing groups or modules: virt:8.2": 
# subscription-manager repos --enable=advanced-virt-for-rhel-8-x86_64-rpms

Closing based on comment#17 which describes that dnf errors out when disabling a module that is not available, which is expected.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days