IMPORTANT: configure Pegasus with "forceProviderProcesses=true"
Hi all, due to the changes made to the associations (registering the Virt_ provider for each subclass), it is now very important that Pegasus is configured for "forceProviderProcesses=true". Otherwise only strange things are happening ... ... Heidi -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
HE> due to the changes made to the associations (registering the Virt_ HE> provider for each subclass), it is now very important that Pegasus HE> is configured for "forceProviderProcesses=true". Otherwise only HE> strange things are happening ... Can you explain why you think this? I have forceProviderProcesses=false and I haven't noticed any weird behavior thus far (aside from the libvirt init race, which is still not fully resolved). There's nothing about the std_association approach that should be any less thread-safe than the "conventional" approach, other than if Pegasus itself has issues with multiple calls into the broker at once. If this is the case, we should be able to work around it by preparing additional context objects as you do when you prepare a thread to run, or we could provide mutual exclusion at the std_association layer. Before I could be convinced that we've got a thread-safety issue, I would want to know what behavior you're seeing, and hear from someone familiar with the Pegasus internals on why what we're doing is not safe. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
HE> due to the changes made to the associations (registering the Virt_ HE> provider for each subclass), it is now very important that Pegasus HE> is configured for "forceProviderProcesses=true". Otherwise only HE> strange things are happening ...
Can you explain why you think this? I have forceProviderProcesses=false and I haven't noticed any weird behavior thus far (aside from the libvirt init race, which is still not fully resolved).
These are good news :).
There's nothing about the std_association approach that should be any less thread-safe than the "conventional" approach, other than if Pegasus itself has issues with multiple calls into the broker at once. If this is the case, we should be able to work around it by preparing additional context objects as you do when you prepare a thread to run, or we could provide mutual exclusion at the std_association layer.
Before I could be convinced that we've got a thread-safety issue, I would want to know what behavior you're seeing, and hear from someone familiar with the Pegasus internals on why what we're doing is not safe.
I was experiencing different behavior with Pegasus between setting forceProviderProcesses to false or true. With set to false, a provider request took around 5 seconds until a first output was printed out on stdout (CU_DEBUG) and none of the association calls have been successful. All request returned with "Handler not found" (CU_DEBUG), which was really strange, as all request have been valid ones. With forceProviderProcesses set to true this behavior disappeared. But after some more extensively testing it returned and also occurred with this setup :(. So if no one else noticed such strange things, its more reasonable that something in my local machine setup is completely broken. I will investigate further into it and hopefully find some explanation for it. Thank you for your feedback. I'm extremely happy to hear, that you haven't encountered similar issues. -- Regards Heidi Eckhart Software Engineer Linux Technology Center - Open Hypervisor heidieck@linux.vnet.ibm.com ************************************************** IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Herbert Kircher Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
HE> I was experiencing different behavior with Pegasus between setting HE> forceProviderProcesses to false or true. With set to false, a HE> provider request took around 5 seconds until a first output was HE> printed out on stdout (CU_DEBUG) I am *definitely* not seeing that kind of behavior :) HE> and none of the association calls have been successful. All HE> request returned with "Handler not found" (CU_DEBUG), which was HE> really strange, as all request have been valid ones. Actually, both Zhengang and I have seen this behavior, but it was related to all of the association and registration changes that have been flying around recently. A full preuninstall, uninstall, restart the CIMOM, build, install, postinstall, restart CIMOM seemed to clear it up for both of us right away. I'm guessing that Pegasus may have been caching some stale information somewhere. Let us know if the above procedure clears things up. I might also point out that we still appear to have a bit of a libvirt initialization race when forceProviderProcesses=false. I had assumed that Pegasus was loading the providers serially, which does not seem to be the case. Thus, we will probably need to provide a mutex for the thread case in the initialization routine. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
participants (2)
-
Dan Smith -
Heidi Eckhart