Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Wed, 28 Sep 2016 07:14:20 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12969389.1463083830000.683804.1475046860715@Atlassian.JIRA>
In-Reply-To: <JIRA.12969389.1463083830000@Atlassian.JIRA>
References: <JIRA.12969389.1463083830000@Atlassian.JIRA> <JIRA.12969389.1463083830910@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization
 at VM level on VMware Hypervisor
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 28 Sep 2016 07:14:22 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528683#comment-15528683 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:
--------------------------------------------

Github user rhtyd commented on the issue:

    https://github.com/apache/cloudstack/pull/1542
  
    @jburwell nested VM is something tricky to test, we can support this as a subtle feature but not a generally supported one. In our test/trillian environment, we're already running nested virtualization. I'm not sure investing time on inception of a test environment is useful. The feature is specific to vmware, I don't understand why KVM needs to be involved.
    
    A quick test could be to run a guest VM on VMware with specific cpu flags (say vmx, smx, ht) and verify that the VM launched with these flags have the cpu features for example, the test could do: (1)ssh into the vm, (2) cat /proc/cpuinfo and (3) grep `flags` for specific cpu flags such as vmx, ht etc. I think such a test should work with the default centos template or with macchanina.
    
    The feature could also be written and tested in such a way to add `any` key/value details on a VM and be interpreted by the hypervisor specific resource.


> Support nested virtualization at VM level on VMware Hypervisor
> --------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9379
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: VMware
>    Affects Versions: 4.9.0
>            Reporter: Nicolas Vazquez
>            Assignee: Nicolas Vazquez
>             Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware hypervisor. Current behaviour supports enabling/desabling global nested virtualization by modifying global config {{'vmware.nested.virtualization'}}. It is wished to improve this feature, having control at VM level instead of a global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)