<div dir="auto">Clark is right, trove does detect and try to use kvm where possible. The performance has been well worth the change (IMHO).<br><br><div data-smartmail="gmail_signature">-amrith</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 17, 2017 6:53 PM, "Clark Boylan" <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jan 17, 2017, at 03:41 PM, Jay Faulkner wrote:<br>
> Hi all,<br>
><br>
> Back in late October, Vasyl wrote support for devstack to auto detect,<br>
> and when possible, use kvm to power Ironic gate jobs<br>
> (<wbr>0036d83b330d98e64d656b156001dd<wbr>2209ab1903). This has lowered some job<br>
> time when it works, but has caused failures — how many? It’s hard to<br>
> quantify as the log messages that show the error don’t appear to be<br>
> indexed by elastic search. It’s something seen often enough that the<br>
> issue has become a permanent staple on our gate whiteboard, and doesn’t<br>
> appear to be decreasing in quantity.<br>
><br>
> I pushed up a patch, <a href="https://review.openstack.org/#/c/421581" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/421581</a>, which keeps<br>
> the auto detection behavior, but defaults devstack to use qemu emulation<br>
> instead of kvm.<br>
><br>
> I have two questions:<br>
> 1) Is there any way I’m not aware of we can quantify the number of<br>
> failures this is causing? The key log message, "KVM: entry failed,<br>
> hardware error 0x0”, shows up in logs/libvirt/qemu/node-*.txt.<wbr>gz.<br>
> 2) Are these failures avoidable or visible in any way?<br>
><br>
> IMO, if we can’t fix these failures, in my opinion, we have to do a<br>
> change to avoid using nested KVM altogether. Lower reliability for our<br>
> jobs is not worth a small decrease in job run time.<br>
<br>
Part of the problem with nested KVM failures is that in many cases they<br>
destroy the test nodes in unrecoverable ways. In which case you don't<br>
get any logs, and zuul will restart the job for you. I think that<br>
graphite will capture this as a job that resulted in a Null/None status<br>
though (rather than SUCCESS/FAILURE).<br>
<br>
As for collecting info when you do get logs, we don't index the libvirt<br>
instance logs currently and I am not sure we want to. We already<br>
struggle to keep up with the existing set of logs when we are busy.<br>
Instead we might have job cleanup do a quick grep for known nested virt<br>
problem indicators and then log that to the console log which will be<br>
indexed.<br>
<br>
I think trove has also seen kernel panic type errors in syslog that we<br>
hypothesized were a result of using nested virt.<br>
<br>
The infra team explicitly attempts to force qemu instead of kvm on jobs<br>
using devstack-gate for these reasons. We know it doesn't work reliably<br>
and not all clouds support it. Unfortunately my understanding of the<br>
situation is that base hypervisor cpu and kernel, second level<br>
hypervisor kernel, and nested guest kernel all come into play here. And<br>
there can be nasty interactions between them causing a variety of<br>
problems.<br>
<br>
Put another way:<br>
<br>
2017-01-14T00:42:00  <mnaser> if we're talking nested kvm<br>
2017-01-14T00:42:04  <mnaser> it's kindof a nightmare<br>
from<br>
<a href="http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-01-14.log" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/irclogs/%23openstack-<wbr>infra/%23openstack-infra.2017-<wbr>01-14.log</a><br>
<br>
Clark<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div></div>