[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC PATCH 2/2] qemu: Force capabilities cache read if libvirtd date is different




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 lists debian org&q=subject:%22Bug%23731815%3A+virsh%3A+Unable+to+start+any+VM+with+custom+cpu+model%22&o=newest&f=1


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]