There also was the discussion (on this bug) to re-probe on reboots in general.
That was already discussed upstream multiple times, but didn't happen to be implemented so far.
There is some pro (more reliable data) and con (this is really a heavy task) to this.
For all the MDS and its predecessors I wonder if "/proc/cpuinfo flags" would be another good candidate going forward to polish the existing caching mechanism even further. I might send an RFC about that, but will look at back-portability of the existing first.
There also was the discussion (on this bug) to re-probe on reboots in general.
That was already discussed upstream multiple times, but didn't happen to be implemented so far.
There is some pro (more reliable data) and con (this is really a heavy task) to this.
See discussions on: /www.redhat. com/archives/ libvir- list/2017- October/ msg00916. html /www.redhat. com/archives/ libvir- list/2018- January/ msg00657. html
=> https:/
=> https:/
So far the outcome always was to add just another minor check for whatever new case was identified instead of really probing all again on each reboot.
For some stuff that was mentioned in IRC discussions: /www.redhat. com/archives/ libvir- list/2018- December/ msg00722. html /www.redhat. com/archives/ libvir- list/2019- January/ msg00061. html /www.redhat. com/archives/ libvir- list/2018- September/ msg00662. html
In no way seems "refresh on libvirtd restart" an option.
=> https:/
=> https:/
=> https:/
Nor "provide something nicer than rm xml files" /www.redhat. com/archives/ libvir- list/2018- November/ msg00614. html
=> https:/
For all the MDS and its predecessors I wonder if "/proc/cpuinfo flags" would be another good candidate going forward to polish the existing caching mechanism even further. I might send an RFC about that, but will look at back-portability of the existing first.