Continous startup of libvirt service

Bug #2062168 reported by Francesco Di Nucci
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
puppet-nova
New
Undecided
Unassigned

Bug Description

Hello,
I'm using puppet-nova 2023.2 with Puppet runs every 30 minutes. At every run I get the notice that the libvirt service has been started {Stage[main]/Nova::Compute::Libvirt::Services/Service[libvirt]/ensure ensure changed 'stopped' to 'running' (corrective)}. It then exits with status=0/SUCCESS, and in the next run Puppet will try to start it again, causing unnecessary (?) notifications.

Should the libvirtd service be enabled & running, or is it enough that it has triggers (libvirtd-ro.socket, libvirtd.socket, libvirtd-admin.socket, libvirtd-tls.socket)? VMs on OpenStack seem to run fine

Relevant nova inclusions

  include nova
  include nova::cinder
  include nova::compute
  include nova::compute::libvirt
  include nova::compute::libvirt::libvirtd
  include nova::compute::libvirt::virtqemud
  include nova::compute::libvirt::virtnodedevd
  include nova::glance
  include nova::keystone::authtoken
  include nova::keystone::service_user
  include nova::logging
  include nova::migration::libvirt
  include nova::network::neutron
  include nova::placement

Revision history for this message
Takashi Kajinami (kajinamit) wrote (last edit ):

A few questions.
 - Which operating system are you using ?
 - What's the libvirt version in the compute node ?
 - Are you using monolithic libvirt (default) or modular libvirt ?
 - If you stop that periodic puppet run, do you see libvirt is periodically stopped and started ?

Revision history for this message
Takashi Kajinami (kajinamit) wrote :

Technically enabling sockets would be enough, but I intentionally avoided this switch because switching to socket service requires too tricky handling for service refresh. I really hate the fact we used sockets for modular libvirt services but that's how they implemented these modular daemons and we didn't have any other options.

My expectation was that libvirt is periodically polled by nova so the service may not stop really even though they change behavior of libvirtd to automatically shutfown after no activity.

Revision history for this message
Francesco Di Nucci (d1nuc0m) wrote :

Thanks, to answer the questions:
- Almalinux 9.3
- Libvirt 9.5.0
- It should be modular libvirt, as in addition to libvirtd there are additional daemons running, such as virtqemud and virtnodedevd. Probably because we included nova::compute::libvirt::virtqemud and nova::compute::libvirt::virtnodedevd, as it seemed necessary for VM migration
- No, with the periodic run stopped, journalctl does not report starts/stops for libvirtd, even if there are VMs running on that node

> they change behavior of libvirtd to automatically shutfown after no activity
If this is the desired behaviour, the module could have a parameter such as manage_service to make the service management optional? This might default to true to be in line with the current puppet-nova module behavior

Revision history for this message
Francesco Di Nucci (d1nuc0m) wrote :

Update

Upgraded to 2024.1, Almalinux 9.4 and libvirt 10.0.0 - no changes

Revision history for this message
Takashi Kajinami (kajinamit) wrote (last edit ):

If you are using modular daemons then libvirtd should not be started.
Maybe you have to make sure that the modular_libvirt parameter in nova::compute::libvirt::services and nova::migration::libvirt is set properly ?

Revision history for this message
Francesco Di Nucci (d1nuc0m) wrote :

Thank you, setting "nova::compute::libvirt::services::modular_libvirt: true" and "nova::migration::libvirt::modular_libvirt: true" fixed the issue. As in EL9 the modular libvirt seems to be the defult, I proposed it as a change in https://review.opendev.org/c/openstack/puppet-nova/+/920722. Let me know what do you think about it

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.