On 05/22/2015 08:26 AM, Daniel P. Berrange wrote: >> >> RPM preserves mtimes, not ctimes. >> We use ctimes since commit f5059a929e0db6689e908e354b13a60661c143e1 >> Change QEMU capabilities cache to check ctime instead of mtime >> CommitDate: 2014-03-11 10:52:29 +0000 >> >> http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=f5059a92 > > Oh, so it does. I thought it preserved both, but I was comparing the > wrong fields. In that case, I'm not clear on just what problem John > is seeing. Even if he installs an older maint release RPM, or > switches to an old maint branch and rebuilds, the ctime should > always get changed. So the cache should invalidate. > The "history" of this issue also includes some direct (internal Red Hat) email regarding using beaker systems where testing was having problems. I suppose while trying to consider both and my assumptions about ctime being creation time not change time, my theory has been this installation order processing that could cause the problem, but it seems that notion is no longer valid. Still given the various ways ctime can be changed - is it perhaps reasonable or desirable to add checks for versions as well? That is save both qemu & libvirtd versions and if they don't match, cause a refresh? John FWIW: Here's a cut-n-paste of a part of the email that I have. It doesn't give all the context, but it does show the process used to "work around" what was seen. ... Sojust worked this much out. This flow stops the error from happening: - Installing libvirt and the various other dependencies - setting memerships etc. - rm -rf /var/cache/libvirt/qemu/capabilities - systemctl restart libvirtd - <run code to create and start vm> ie: after installing libvirt I had to clear the cache and restart the service. Clearing the cache before, uninstalling libvirt and reinstalling libvirt didn't help. The cache had to be cleared right after installing libvirt but before launching the vm. The problem only showed up if we installed, launched a vm, removed the vm, uninstalled, reinstalled, launched a new vm. ... There was also a link to the following: https://www.mail-archive.com/search?l=debian-bugs-dist@xxxxxxxxxxxxxxxx&q=subject:%22Bug%23731815%3A+virsh%3A+Unable+to+start+any+VM+with+custom+cpu+model%22&o=newest&f=1 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list