<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> Perhaps I phrased it the wrong way.<br>
><br>
> *Excluding the multi-fact exceptions* is it ever a problem to output the<br>
> fact and immediately exit?<br>
<br>
</div></div>I think you're missing the point that there might not be "a"<br>
hypervisor.  It's entirely possible for the hypervisor to offer two<br>
distinct sets of services, or even to look like two different<br>
platforms (Azure + Xen).  I'm wondering why this is important.<br>
<span class=""><br></span></blockquote><div><br>Why it's important? Because (1) it's inefficient, and I care about efficiency, and (2) because it leads to possibly incorrect results with unpredictable consequences. <br><br></div><div>I came to this project because our datacenter runs RedHat Virtualization and we use Puppet to configure hosts; Puppet uses facter. The facter fact which runs virt-what stopped working properly in RHEL7. Why? Because the RHEL7-based puppet package added virt-what as a dependency. But obviously "rhev" is not yet supported. This broke the fact. But because virt-what exits with error when run as non-root, the fact broke conditionally.<br><br>Now consider this: facter runs virt-what and discards all but the last line of output. So in such a system as you describe above, facter would provide either wrong, incomplete, or varying facts. <br><br>Also, back to my point (1) above, facter runs on our systems every 30 minutes. At least. (That's another battle of mine; to get that default changed). At any rate, I had in mind to make several optimizations.<br><br>I am fully prepared to accept the argument that facter's use/reliance on this tool is incorrect. <br><br>I suppose virt-what is key in implementing your virt-top and other virt-tools?<br><br></div></div>
</div></div>