From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Pilcher <arequipeno@gmail.com>
Subject: Nested VMX stability - module parameters?
Date: Fri, 23 Nov 2012 15:08:28 -0600
Message-ID: <k8oojt$9i8$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
To: kvm@vger.kernel.org
Return-path: <kvm-owner@vger.kernel.org>
Received: from plane.gmane.org ([80.91.229.3]:45508 "EHLO plane.gmane.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756302Ab2KWVKC (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 23 Nov 2012 16:10:02 -0500
Received: from list by plane.gmane.org with local (Exim 4.69)
	(envelope-from <gcekd-kvm-devel@m.gmane.org>)
	id 1Tc0Vg-0007io-3g
	for kvm@vger.kernel.org; Fri, 23 Nov 2012 22:10:04 +0100
Received: from pool-71-170-109-80.dllstx.fios.verizon.net ([71.170.109.80])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <kvm@vger.kernel.org>; Fri, 23 Nov 2012 22:10:04 +0100
Received: from arequipeno by pool-71-170-109-80.dllstx.fios.verizon.net with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <kvm@vger.kernel.org>; Fri, 23 Nov 2012 22:10:04 +0100
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

I am trying to use nested KVM (VMX) to set up Red Hat Enterprise
Virtualization (RHEV) on a single Fedora 17 host.  The host hardware is
an Intel DQ67SW board with a Core i7 2600 processor.

I have successfully set up the environment, but I have experienced at
least 2 host kernel panics.

    https://bugzilla.kernel.org/show_bug.cgi?id=42980

I'm not 100% sure, but I believe that both panics have occurred when
there was a lot of network traffic between nested guests running on
separate virtualized hypervisors.  (See high-quality ASCII art.)

+----------------------------------------------------------------------+
|                                                                      |
|  +------------------+   +------------------+                         |
|  |                  |   |                  |                         |
|  |   +----------+   |   |   +----------+   |                         |
|  |   |          |   |   |   |          |   |                         |
|  |   |  Nested  |   |   |   |  Nested  |   |                         |
|  |   |  Guest   |   |   |   |  Guest   |   |                         |
|  |   |          |   |   |   |          |   |                         |
|  |   +----------+   |   |   +----------+   |   +------------------+  |
|  |                  |   |                  |   |                  |  |
|  |     Virtual      |   |     Virtual      |   |       RHEV       |  |
|  |    Hypervisor    |   |    Hypervisor    |   |     Manager      |  |
|  |    (RHEL 6.3)    |   |    (RHEL 6.3)    |   |    (RHEL 6.3)    |  |
|  |                  |   |                  |   |                  |  |
|  +------------------+   +------------------+   +------------------+  |
|                                                                      |
|                      Physical host (Fedora 17)                       |
|                                                                      |
+----------------------------------------------------------------------+

After the first panic, I did two things to try to make the environment
more stable.

* Disabled VT-d in BIOS

* Changed processor type of the virtual hypervisors (as defined on the
  host) to "Conroe":

  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Conroe</model>
    <vendor>Intel</vendor>
    <feature policy='require' name='vmx'/>
  </cpu>

Unfortunately, those changes did not prevent me from experiencing the
host kernel panic again.

I see that the kvm and kvm_intel modules have a number of parameters.
Are any of these likely to affect the stability of nested VMX?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================