Adds seapath provided generic qemu hook

[insatomcat]

This hook will run tasks that needs to be run everytime a guest is started:

• parse the guest xml
• override the network speed of all declared network interfaces to 1Gb (instead of the default 10Mb that make all supervision software believe they use more than 100%)
• set all vhost- threads to RR1 if guest is realtime (= use vcpusched)
• set cpu affinity of those threads to the same as main qemu thread if guest is realtime

[ebail]

Hi, I think that is a great to streamline the priority setting.

I think that functions should be documented.
Also I would consider adding units tests specially considering that it is a critical component.

Also I am wondering if we could plug this tool to vm-manager (https://github.com/seapath/vm_manager/tree/main) so that Ansible could be optionally used.
Once a VM is started with vm-manager, correct priorities could be applied.

[ebail]

Hi @insatomcat, I am surprised to see this PR closed. I think that it is a good idea.
Do I miss something ?

[eroussy]

Hi all
I would like to re-open the discussions around this qemu hook.
This is honestly very useful to me when dealing with OVS bridges. I think it would be valuable to be included in SEAPATH, but I see two minor problems:

1. the vhost-thread of the br0 administration bridge is also put to RT priority which is not useful, we should find a way to avoid it
2. This script is not needed if you don't used any bridges for time-critical data (SV). I advise to not apply it by default and make it available with a variable in the inventory.

What do you think of that ?

[eroussy]

Also I am wondering if we could plug this tool to vm-manager (https://github.com/seapath/vm_manager/tree/main) so that Ansible could be optionally used. Once a VM is started with vm-manager, correct priorities could be applied.

This cannot be done by vm-manager, because the script has to be run everytime the VM starts/restarts.

[eroussy]

I pushed the modifications and add some molecule tests.
We could also add some test directly to the script, but it still not done right now.

The last thing that troubles me is this br0 related vhost thread that is also caught by the script and put to RR 41. I would like to put only the correct vhost thread to RR 41.
The only way I know to detect that is to match the sequence of bridges declared in the XML with the sequence of vhost thread associated to the VM (ex: if br0 is declared first, it will be the first vhost of the VM)
But then this will only be compatible with people using the seapath guest.xml.j2 template. And what happen if someone declare another non-critical bridge inside the VM ?

What is your opinion on that ?

[insatomcat]

Hi @eroussy, thanks for reviving this. The need is real, and I hit exactly the two limits you describe. I would rather attack them at the cause, which is what I proposed in #996: the VM declares an intent (isolation, scheduler, priority per thread group) and a libvirt hook resolves it at start and on incoming migration, against the live state of the node.

Compared to this PR that gives your point 2 for free and without a new host flag (a VM with no profile is not touched at all), vhost policy and priority stated separately from the emulator (<emulatorpin> covers both with one cpuset and there is no <emulatorsched> for vhost, which is exactly why a hook is needed), live migration, and cores chosen against real occupancy instead of pre-reserved on every node.

Being honest about your point 1: #996 does not solve it either. Its vhost intent is per group, not per interface, and thread discovery is a comm scan of the QEMU tasks, so it knows no more than your script which thread belongs to br0. Indexing a per-vhost list would just re-introduce the XML ordering assumption you rightly refuse. It only makes it cheaper: put the vhost group on a shared slot and the br0 thread stops costing a dedicated isolated core. A real interface to vhost thread mapping deserves its own issue rather than blocking this.

So I would suggest closing this PR in favour of #996, where the vhost part lands in step 4. Nothing is lost, this PR is why vhost handling is a first-class requirement there. One exception: the 1 Gb link speed override is orthogonal to pinning and is not covered by #996, it deserves its own small hook drop-in and its own PR.