Terminology

The phrase "running nested VMs" refers to running a VM inside another VM. The outer guest is the VM that runs on physical hardware. The inner guest (or nested guest) is the VM that runs within another VM. The host hypervisor is the hypervisor that runs on the physical hardware. The guest hypervisor is the hypervisor that runs within a VM. To avoid confusion, we will not consider deeper levels of nesting here.

Note that no Type 1 hypervisors are supported as guest operating systems under any VMware product.  In particular, ESXi is not supported as a guest operating system, and VMware discourages running ESXi as a guest hypervisor in production environments.  (See http://kb.vmware.com/kb/2009916 for VMware's official policy on running ESXi as a guest hypervisor.)

Running Guest Hypervisors with Virtualized HV

Most hypervisors require hardware-assisted virtualization (HV). VMware products require hardware-assisted virtualization for 64-bit guests on Intel hardware. When running as a guest hypervisor, VMware products also require hardware-assisted virtualization for 64-bit guests on AMD hardware.  The hardware-assisted virtualization features of the physical CPU are not typically available in a VM, because most hypervisors (from VMware or others) do not virtualize HV. However, Workstation 8, Player 4, Fusion 4, and ESXi 5.0 (or later) offer virtualized HV, so that you can run guest hypervisors which require hardware-assisted virtualization.

With virtualized HV enabled for the outer guest, you should be able to run any guest hypervisor that requires hardware-assisted virtualization. In particular, this means that you will be able to run 64-bit nested guests under VMware guest hypervisors.

ESXi 6.0

Virtualized HV is fully supported for virtual hardware version 9 or later VMs on hosts that support  Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, use the web client and navigate to the processor settings screen. Check the  box next to  "Expose hardware-assisted virtualization to the guest operating system."  This setting is not available under the traditional C# client.

Workstation 11 / Player 7 / Fusion 7

Virtualized HV is fully supported for virtual hardware version 9 or later VMs on hosts that support Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, select VM->Settings and navigate to the processor settings screen. Check the box next to  "Virtualize Intel VT-x/EPT or AMD-V/RVI."

Workstation 10 / Player 6 / Fusion 6

Virtualized HV is fully supported for virtual hardware version 9 or 10 VMs on hosts that support Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, select VM->Settings and navigate to the processor settings screen. Check the box next to  "Virtualize Intel VT-x/EPT or AMD-V/RVI."

ESXi 5.5

Virtualized HV is fully supported for virtual hardware version 9 or 10 VMs on hosts that support  Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, use the web client and navigate to the processor settings screen. Check the  box next to  "Expose hardware-assisted virtualization to the guest operating system."  This setting is not available under the traditional C# client.

Workstation 9 / Player 5 / Fusion 5

Virtualized HV is fully supported for virtual hardware version 9 VMs on hosts that support Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, select VM->Settings and navigate to the processor settings screen. Check the box next to  "Virtualize Intel VT-x/EPT or AMD-V/RVI."

ESXi 5.1

Virtualized HV is fully supported for virtual hardware version 9 VMs on hosts that support  Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, use the web client and navigate to the processor settings screen. Check the  box next to  "Expose hardware-assisted virtualization to the guest operating system."  This setting is not available under the traditional C# client.

Workstation 8 / Player 4

Virtualized HV is available for virtual hardware version 8 VMs on hosts that support Intel VT-x and EPT or AMD-V and RVI. To enable virtualized HV, select VM->Settings and navigate to the processor settings screen. Check the box next to "Virtualize Intel VT-x/EPT or AMD-V/RVI."  You will see a warning that virtualized HV will make this VM incompatible with other VMware products. In particular, if this VM is moved to an ESXi 5.0 host, virtualized HV will not be available without additional tweaking.

Fusion 4

Virtualized HV is available for virtual hardware version 8 VMs on hosts that support Intel VT-x and EPT or AMD-V and RVI, but it cannot be selected through the user interface. To enable virtualized HV, edit the outer guest's configuration file by hand and add the following line:

vhv.enable = TRUE

ESXi 5.0

On ESXi 5.0, virtualized HV is prohibited by default. This feature is used internally within VMware for testing purposes, but it is not recommended for production systems. It is available on hosts that support Intel VT-x or AMD-V, but it is not recommended for systems without second level address translation (EPT or RVI), because of its poor performance without SLAT. Unfortunately, this feature does not work on AMD "Bulldozer" CPUs running ESXi 5.0.

To allow the use of this feature, the ESXi administrator must add the following configuration option to the /etc/vmware/config file on the physical host:

vhv.allow = TRUE

Once allowed by the ESXi administrator, virtualized HV will be enabled by default for all hardware version 8 VMs with guest OS type "ESX Server 4" and "ESX Server 5." To enable virtualized HV for other guests, add the following lines to the outer guest's configuration file:

cpuid.1.ecx="----:----:----:----:----:----:--h-:----"
cpuid.80000001.ecx.amd="----:----:----:----:----:----:----:-h--"
cpuid.8000000a.eax.amd="hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"
cpuid.8000000a.ebx.amd="hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"
cpuid.8000000a.edx.amd="hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh"

Running Guest Hypervisors without Virtualized HV

VMware products prior to ESXi 5.0, Workstation 8 or Fusion 4 do not virtualize the hardware-assisted virtualization capabilities of the physical processor (or 64-bit segment limit checks on AMD processors). If the host hypervisor is an older VMware product, or if your host does not support EPT or RVI (but it does support Intel VT-x or AMD-V) you can still run nested guests without virtualized HV. However, you will only be able to run 32-bit nested guests using binary translation under a VMware guest hypervisor. You can also run 32-bit nested guests using the binary translation features of Windows Virtual PC or VPC2007.

Even in this configuration, running nested VMs requires host support for hardware-assisted virtualization.  Furthermore, the outer guest must be configured to use hardware-assisted virtualization.  For instructions on enabling hardware-assisted virtualization for the outer guest, see VMware Products and Hardware-Assisted Virtualization (VT-x/AMD-V).

Special Considerations

Networking in Nested Guests

For networking to work in a nested guest, the network interfaces of the outer guest must be put into promiscuous mode. For details, see KB 287 (Linux hosts) or KB 1004099 (ESX hosts). No special configuration is required for Windows hosts.

EVC Clusters

Virtualized HV may not work on hosts that are part of an EVC cluster, due to the feature masking that is performed to make all of the CPUs in the cluster look alike.

VMware Tools

Beginning with ESXi 5.0, Workstation 8 and Fusion 4, VMware hypervisors implement a handshake between the host hypervisor and the guest hypervisor which allows you to run VMware Tools in both the inner guest and the outer guest. Note that both hypervisors must be of this recent vintage for the handshake to work.

If either hypervisor is older than this, you will only be able to run VMware Tools in the inner guest. To ensure that VMware Tools work properly, you must either set the outer guest OS type to "ESX Server 4" or "ESX Server 5," or you must add the following line to the outer guest's configuration file:

monitor_control.restrict_backdoor = TRUE

Note that this setting is not available when your host hypervisor is ESX 3.0. You cannot use VMware Tools in the inner guest if your host hypervisor is ESX 3.0.

Guest Hypervisors

ESX(i)

ESX(i) may be used as a guest hypervisor to learn about VMware's server products, experiment with server setup, conduct training, show demos, and test configurations. VMware does not support running nested ESX(i) servers in production environments. Issues running ESX(i) in a nested configuration fall outside of  VMware's Support and Service Level Agreements. If you experience issues, VMware is under no obligation to acknowledge or investigate immediately or to provide a resolution. However, VMware is interested in obtaining  an easily reproducible scenario for our engineers to investigate through discussions in the Nested Virtualization community forum.

Windows Virtual PC (XP mode)

The files required to run an XP mode VM under Windows 7 are available from http://www.microsoft.com/windows/virtual-pc/download.aspx.  To use Windows Virtual PC with binary translation, all three downloads are needed. Without the binary translator, Windows Virtual PC requires hardware-assisted virtualization.

Windows Virtual PC has a bug related to power-saving states when running with Intel VT-x. If you try to sleep or hibernate the outer Windows VM while a nested Windows Virtual PC VM is running, you may run into a variety of issues when the outer guest is awakened. To solve this problem, you will have to install the hotfix from http://support.microsoft.com/?kbid=977632. Even if the description does not sound like it is applicable, this hotfix should help with any sleep/hibernate issues.

Hyper-V

Hyper-V requires hardware-assisted virtualization, so it can only be run under ESXi 5.0, Workstation 8, Player 4 or Fusion 4 (or later). Hyper-V performs relatively poorly as a guest hypervisor under ESXi 5.0, but it performs reasonably well under Workstation 8, Player 4 or Fusion 4 (or later).

Under Workstation 9, Player 5 or Fusion 5, you should set the guest OS type to "Hyper-V."

Under older products, Hyper-V requires the following additional configuration option for the outer guest:

hypervisor.cpuid.v0 = FALSE

Without this option, launching a nested VM under Hyper-V R2 will fail with the following error:

Failed to create partition: Unspecified error (0x80004005) 

Without this option, Hyper-V R3 will refuse to install, claiming:

Hyper-V cannot be installed: A hypervisor is already running.

Hyper-V R4 requires virtual hardware version 11 or greater.  Under older virtual hardware versions, Hyper-V R4 will fail with the following error:

Hypervisor launch failed; The hypervisor was unable to initialize successfully (phase 0x2), and was not started.  This initialization failure may be the result of a platform configuration or firmware issue.  Contact your system vendor for more information or updated firmware.>

Xen

Xen requires hardware-assisted virtualization, so it can only be run under ESXi 5.0, Workstation 8, Player 4 or Fusion 4 (or later). The version of Xen provided with most Linux distributions performs relatively poorly as a guest hypervisor. Citrix XenServer 5.6 performs reasonably well.

KVM

KVM requires hardware-assisted virtualization, so it can only be run under ESXi 5.0, Workstation 8, Player 4 or Fusion 4 (or later). KVM performs relatively poorly as a guest hypervisor on Intel CPUs using virtualized Intel VT-x. Performance is improved with Linux kernel versions 3.0 and greater.

Under some VMware products, libvirtd hangs awaiting completion of a dmidecode child process.  If this happens, you will be unable to connect to the local hypervisor.  A workaround is to disable CPU hot-add for the outer VM with the following configuration option:

vcpu.hotadd = FALSE

VMware as a Guest Hypervisor Under Foreign Hypervisors

If we detect that a VMware product is running under a foreign hypervisor, we will refuse to power on a nested guest. To bypass this constraint, add the following option to your nested guest's configuration file:

vmx.allowNested = TRUE

VMware Workstation under Hyper-V

You can run the VMware binary translator (for 32-bit guests) under Hyper-V if your host has SLAT support.  Without SLAT support, if you attempt to run a nested VM under VMware Workstation, Hyper-V will synthesize a machine check and BSOD the host.

The Workstation installer won't allow you to install Workstation while the Hyper-V role is active, so you will have to disable Hyper-V to do the installation.  See http://blogs.msdn.com/b/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx for instructions on how to boot Windows 2008 with Hyper-V disabled, without actually having to remove the Hyper-V role.

I am attempting to access vSphere API method CreateVvolDatastore in list of Managed Object "HostDatastoreSystem" methods.

New CreateVvolDatastore method should be available in HostDatastoreSystem since vSphere API 6.0:

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.host.DatastoreSystem.html

However method CreateVvolDatastore not showing up as an option. Note latest vijava pom.xml dependency entry is version 5.1:

              <dependency>

                     <groupId>com.vmware</groupId>

                     <artifactId>vijava</artifactId>

                     <version>5.1</version>

           </dependency>

Can anyone please advise how to successfully find / interface with vSphere 6.0 API class HostDatastoreSystem, method CreateVvolDatastore() ?

Is there any vijava SDK jar available containing this new method?

Thanks,

Elaine

This document pertains only to Intel VT-x on Intel hardware. It does not pertain to AMD-V (aka SVM) on AMD hardware. Some portions of this document may be relevant to Intel VT-x on VIA hardware.

Common Issues

VT is enabled in the firmware, but your VMware product says that VT is disabled

When a VMware product says that VT is disabled, it is referring to "Intel Virtualization Technology," otherwise known as VT-x.  Some firmware menus offer a separate setting for "VT-d," which is "Intel Virtualization Technology for Directed I/O."  Note that it is not sufficient to enable "VT-d."  You must enable "Intel Virtualization Technology." Moreover, the only VMware product that uses VT-d is ESX(i).  For other VMware products, the VT-d setting is irrelevant.

Because the VT-x setting is typically locked at power on, it is necessary to fully power down the system after changing any VT-x options in the firmware (BIOS/EFI). A simple reboot is not sufficient! After saving your firmware changes, I recommend that you either switch off the power supply itself or pull the power cord(s) out of the wall and wait ten seconds. For laptop systems, you may have to remove the battery as well, although such extreme measures are rarely necessary.

Note that VT-x is often unavailable to normal software if you have enabled "trusted execution," which may restrict the use of VT-x to "trusted" code. If you have enabled both VT-x and "trusted execution" in the firmware, but your VMware product still says that VT is disabled, disable "trusted execution" in the firmware and power-cycle the system again.  Your firmware menu may refer to "trusted execution" as "trusted computing."

Sometimes, buggy firmware fails to enable VT on all of the cores of the system. To diagnose this issue, see "Obtaining Detailed Diagnostics," below.

VT is disabled only after Windows 7 "Hybrid Sleep"

If VT is enabled after a power-cycle, but it is disabled after hybrid sleep, the likely cause is buggy firmware (BIOS/EFI). The best solution is to obtain updated firmware from your system vendor. If this is not possible, or if the latest firmware does not resolve the issue, you may have to disable hybrid sleep. If the firmware leaves VT unlocked after hybrid sleep, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

VT is disabled only after hibernate and/or sleep

If VT is enabled after a power-cycle, but it is disabled after hibernate and/or sleep, the likely cause is buggy firmware (BIOS/EFI). The best solution is to obtain updated firmware from your system vendor. If this is not possible, or if the latest firmware does not resolve the issue, you may have to disable hibernate and/or sleep. If the firmware leaves VT unlocked after hibernate and/or sleep, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

Your VMware product says that your host does not support VT

Some Intel processors are not VT-capable. (For example, the Q8200 Intel Core 2 Quad Processor is not VT-capable). You can check to see if your processor(s) are VT-capable  here.

If the Intel site says that your CPU(s) support VT, but your VMware product says that your host does not support VT, you may have encountered an Intel chip erratum (possibly AW67, AV69, AX64, AY64, AZ69 or AAA70, depending on the CPU). The effect of this erratum is that some CPU features are reported incorrectly by the CPU. The only solution to this problem is to obtain an updated BIOS from your system vendor.

If you have a multi-processor system with mixed-stepping CPUs and the Intel site says that all of your CPU(s) support VT, but your VMware product says that your host does not support VT, your CPUs may support incompatible revisions of VT-x. This is known to be an issue with the "B" and "G" steppings of Intel processors codenamed "Clovertown" and "Woodcrest." The only solution to this problem is to obtain an updated BIOS from your system vendor.

You are trying to run a nested VM with VT-x

VMware products prior to ESXi 5.0, Workstation 8, and Fusion 4 do not virtualize the VT-x features of the physical CPU, so the virtual CPU will always report that the "host" does not support VT. In this case, the "host" refers to the virtual machine. If you are using ESXi 5.0, Workstation 8, or Fusion 4, see Running Nested VMs for information on enabling virtualized VT-x.

You have McAfee Deep Defender installed on your host

McAfee Deep Defender installs a hypervisor between the physical hardware and your host OS.  Thus, when you have McAfee Deep Defender installed, you are actually running the host OS in a VM.  McAfee Deep Defender does not virtualize the VT-x features of the physical CPU, so the virtual CPU will always report that the "host" does not support VT. In this case, the "host" refers to the virtual machine running under McAfee Deep Defender.

Your firmware has no option to enable/disable VT

If your firmware leaves VT unlocked at power-on, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.  However, if your firmware locks VT off at power-on (e.g. some Sony VAIO firmware), you may be out of luck. Sony VAIO users may want to search the forums for relevant threads, but please be aware that editing your CMOS settings with third-party tools can render your computer useless.

You really are using SMX (trusted execution)

Maybe you work for the NSA, and you really are running a VMware product under SMX.  There is a different bit that reports whether or not VT-x is enabled under SMX.  Unfortunately, there is no way to tell if the host operating system is running under SMX, so we assume that it isn't.  This means that the VMware product may be checking the wrong bit to see if VT-x is enabled.  A workaround is to set the following configuration option:

hv.assumeEnabled = TRUE

With this option set, VMware hosted products will assume that VT-x is available, regardless of the system configuration.

Obtaining Detailed Diagnostics

To verify that VT-x is enabled and locked on each core/thread of your system, download the attached ISO, burn it to a CD, and boot your host from the CD. Note that you must boot the physical machine from this CD image. It will do you no good to boot a VM from this image, since running this in a VM reports on the capabilities of the virtual CPU rather than the physical CPU.

For each core on your system (or for each thread, if your CPU(s) support hyper-threading),  the ISO will report one or more of the following:

CPU <n>: This core does not support long mode
CPU <n>: This core does not support VT
CPU <n>: Feature control MSR is unlocked!
CPU <n>: VT is disabled in the feature control MSR!
CPU <n>: VT is enabled on this core.

This core does not support long mode

If the ISO reports that some core(s) do not support long mode, you will not be able to use VT-x with current VMware products. You can use VT-x for 32-bit guests with Workstation 5.5 or 6.0.x, Fusion 1.x, or ESX 3.0, but this configuration is not supported. See  VMware Products and Hardware-Assisted Virtualization (VT-x/AMD-V).

This core does not support VT

If the ISO reports that some core(s) do not support VT, you will not be able to use VT-x. There are Intel CPU errata which may result in this capability being reported incorrectly. See "Your VMware product says that your host does not support VT," above.

Feature control MSR is unlocked!

If the ISO reports that some core(s) leave the feature control MSR unlocked, current VMware hosted products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

VT is disabled in the feature control MSR!

If the ISO also reports that these core(s) leave the feature control MSR unlocked, current VMware hosted products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.  However, if the ISO reports that VT is disabled on some core(s) and it does not also report that the feature control MSR is unlocked on these core(s), then it is impossible to enable VT-x through software.

Enabling VT-x if Unlocked

This is already the default behavior for current VMware hosted products (Workstation 7.x, Player 3.x, and Fusion 3.x or newer). For older products, the following workaround may help if your firmware leaves VT-x unlocked, either at power-on, or after hibernate or sleep. Simply add the following option to your system-wide configuration file:

hv.enableIfUnlocked = TRUE

On Linux systems, the system-wide configuration file is /etc/vmware/config. On Windows systems, the system-wide configuration file varies according to VMware product and Windows version. For VMware Workstation on XP hosts, the system-wide configuration file is C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini. For VMware Workstation on Vista or Windows 7 hosts, the system-wide configuration file is C:\ProgramData\VMware\VMware Workstation\config.ini. For other VMware products, adjust the path appropriately.

Introduction

Both major x86 chip vendors now provide hardware-assisted virtualization (HV) support. Intel's x86 hardware virtualization technology is known as VT-x or, more commonly, simply VT (Virtualization Technology). Previously, it was code-named "Vanderpool." AMD's x86 virtualization technology is known as AMD-V. Previously, it was known as "SVM" (Secure Virtual Machine), and before that, it was code-named "Pacifica." These competing technologies are remarkably similar under the hood, particularly in the first generation. Performance of the first generation hardware was somewhat lackluster, and for that reason, VMware products still default where possible to binary translation without hardware assistance on older HV-capable hardware.

Both vendors have made incremental improvements to their hardware-assisted virtualization technology, and now both vendors offer a major advancement in the form of virtual MMU support, known as nested paging or second level address translation (SLAT). AMD was the first to come out with nested paging (SLAT) in their Family 10H (3rd Generation Opteron) processors, and they dub their nested paging (SLAT) technology Rapid Virtualization Indexing (RVI). Intel introduced a comparable feature in their Core i7 processors, and they dub their nested paging (SLAT) technology Extended Page Tables (EPT). With nested paging (SLAT) support, along with improvements in VM-entry/VM-exit latencies, hardware-assisted virtualization now outperforms binary translation in most situations. However, TLB misses are much more expensive in a nested paging (SLAT) environment, so workloads that over-subscribe the TLB are potentially still good candidates for binary translation without hardware assistance. 32-bit Windows XP is also a good candidate for binary translation, due to its frequent TPR accesses.

As the hardware has evolved, VMware software support of hardware-assisted virtualization has also evolved. The following sections detail the hardware-virtualization support in some of our products.

Workstation 5.5 and ESX 3.0

Intel VT-x support was first introduced in Workstation 5.5 to support 64-bit guests on Intel hardware. Since Intel does not provide segment limit checks in 64-bit mode, VT-x is a requirement to provide isolation between 64-bit guests and the virtual machine monitor (or hypervisor). Though unsupported, it is also possible to run a 32-bit guest using VT-x. The configuration option for running a 32-bit guest with VT-x is:

monitor_control.vt32 = TRUE

There is no support for EPT or AMD-V in these products.

Workstation 6.0 and Fusion 1.0

Workstation 6.0 has the same VT-x support as Workstation 5.5. Experimental support was added for AMD-V and RVI. The configuration option for running a guest (either 32-bit or 64-bit) with AMD-V is:

monitor_control.enable_svm = TRUE

RVI will be used by default on RVI-capable hardware. Note that this is the only VMware product that offers support for AMD-V on Family 0FH processors (2nd Generation Opteron) with AMD-V support. This support is experimental.

ESX 3.5

ESX 3.5 only supports VT-x for running 64-bit guests. The experimental 32-bit VT-x support was eliminated. ESX 3.5 also provides the first official AMD-V support, but only for chips with RVI. With this release, we dropped the monitor_control flags for hardware-virtualization. The configuration option for running a guest (either 32-bit or 64-bit) with AMD-V and RVI is:

monitor.virtual_mmu = hardware

Unlike the boolean monitor_control flags used previously, the monitor.virtual_mmu option has three settings: automatic, software and hardware. Selecting RVI implicitly selects AMD-V, since RVI cannot be used with binary translation.

Workstation 6.5 and Later, Server 2.x, ESX(i) 4.0 and Later, Fusion 2.0 and Later

These products add official support for VT-x and AMD-V for all guests, both 32-bit and 64-bit. EPT support is introduced for EPT-capable hardware. VT-x or AMD-V can be used in conjunction with a software MMU or with nested paging (SLAT) on hardware that supports it. Note, however, that hardware-assisted virtualization is only supported on 64-bit hardware, and there is no support for AMD-V on Family 0FH processors (2nd Generation Opteron).

The configuration option for selecting binary translation is:

monitor.virtual_exec = software

The configuration option for selecting VT-x/AMD-V is:

monitor.virtual_exec = hardware

The configuration option for selecting the software MMU (aka shadow paging) is:

monitor.virtual_mmu = software

The configuration option for selecting nested paging (SLAT) is:

monitor.virtual_mmu = hardware

Note that you cannot mix binary translation with nested paging (SLAT).

Workstation 6.5 (and later) and Fusion 3.0 (and later) allow you to make these selections through the UI, in the virtual hardware "Processors" configuration. ESX(i) 4.0 (and later) provides a configuration selection through the vSphere client. For the other products, you have to edit the VM configuration files by hand.

Whether you edit the configuration file by hand or use the UI, you should be careful to select an execution mode that is supported by your hardware. In particular, if you select nested paging (SLAT) on hardware without nested paging (SLAT) support, the execution mode may revert to binary translation. If you select binary translation for a 64-bit guest on Intel hardware, the execution mode will dynamically switch to VT-x as soon as the guest enters long mode (typically partway through the guest boot process).

If you do not select a particular execution mode, a default mode will be chosen for you. The defaults are incredibly complex, depending on your hardware capabilities and the guest OS type. In general, the default mode is likely to be the best (highest performing) mode for your hardware and guest OS, but the heuristics are not infallible. You should feel free to benchmark your workload using the execution modes available on your hardware and choose what works best for you.

Note that some products default to binary translation for 32-bit Windows 2003, due to the frequent TPR accesses of that guest. However, Service Pack 2 addresses this issue. If your guest is 32-bit Windows 2003 and you have installed Service Pack 2, you should change the execution mode to hardware-assisted virtualization on supported hardware for the best performance.

For more information, please see http://www.vmware.com/resources/techresources/10036.

I am trying to export the machines from Managed Machines and getting the below error. Did anyone face this issue? No problems with other tabs, I am able to browse the logs.

Service Temporarily Unavailable or HTTP Status 502 -

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

This is the out of the box feature from vCAC/VRA to pull the complete list of managed machines from UI

I am using vCAC 6.0.x with external vCO appliance. I am trying to change the process for the Disposal of VMs. I want it to call out to a vCO workflow to do a variety of steps. I want to capture the user that is making the request to dispose of the VM. During the Machine-Provision step I know you can grab the 'Owner'. In my case I will be allowing anyone in the Business Unit to dispose of any VM in their BU. So, sometimes the person requesting to delete the VM will not be the 'Owner'. Has anyone captured this before? Thanks for the help.

Hi,

I am curious if anyone else has seen this problem. I have seen this problem when trying to deploy NSX Manager 6.1.6, 6.2.1, & 6.2.2.

After I deploy the OVA I then start the VM and watch the boot process in the remote console. The VM appears to be booting fine and mounting the file systems. The VM gets to the point where it indicates, "Mounting  vdisk Switched to clocksource tsc", and then the boot process hangs for a bit.

Then there are messages indicating, "mptscsih: ioc0: attempting task abort!" followed by other messages (see images below) and then the NSX Manager VM never boots, and hangs at the message, "Beginning Domain Validation".

From what I can gather these messages are related to the LSI Logic Parallel controller on the NSX Manager VM and/or the underlying disks.

Now in fairness, this is in a home lab, running nested ESXi on a Dell R710 with plenty of resources, using an Openfiler VM for iSCSI targets on the R710's internal RAID 5 storage. But that said, the Nested ESXi VMs boot and run fine.There are Windows VMs booting and running fine. I have also attempted to deploy the NSX Manager OVA to the physical ESXi host running directly on the R710 but get the same results.

I am curious if anyone has any ideas or suggestions, or has ever run into something like this? Thank you! 

I'm on the latest version of the 5.5 appliance. When I add AD users to the Administrators group of Single Sign-on, some users show in the list and some don't.  The permissions work, so I know it's adding them.  But what I can't do is see who is in there and who isn't.  I've gone to using an AD group in place of adding explicit permissions (probably a better way to do it anyway) but I would like to know why this happens and if it's happening to anyone else.  Also, if anyone knows how to list out the members of a group using CLI of some kind, I'd appreciate that as well.  Thanks. 

I'm running vROPs 6.2, and installed the epops agent on a RHEL 6.4 server. This box is running vCD. I want to use vROPS to monitor the processes for vCD. I created the following object:

Name: vCD Watchdog

Adapter Type: EP Ops Adapter

Object Type: MultiProcess

Process.query: State.Name.eq=VMware-vcd-watchdog

Collection Interval: 5 mins

After the first collection interval, I receive the error "Object is not available" I cannot seem to find any other info about the error. I thought it might be something to do with the process.query so I checked the vROPs documentation and only found this:

Manually Create Operating System Objects

They talk about how to submit the query and provide an example. Searching google I can't find a list of classes or attributes that are acceptable other than the two I know of: State.Name.eq and Pid.PidFile.eq.

I'm looking for some guidance on this. Can anyone help?

I implemented the EUC Access Point and I have 1 issue. When a user logs in to the Webportal through the EUC Access Point, but doesn't connect to a desktop session and immediately selects log out on that interface, it redirects to the internal address of the connection server: https://<internal ip of connection server>/portal. Is this a bug? Anyone else experiences this? I used the VMware Access Point Deployment Utility to deploy the Access Point and everything else is working. When a user does log in to a desktop session and then logs out, it redirects to the correct url.

Hello,

I am having issues to run ssh commands on HP onboard administrator, I'm getting the following error:

Unable to execute command: InternalError: SSH_MSG_DISCONNECT: 2 Too many authentication failures for Administrator  (Workflow:Run SSH command / Execute SSH Command (item6)#20) (Workflow:Run SSH command / Execute SSH Command (item6)#36)

Did some of you got the same? any ideas ?

Thank you

I don't have a lab/non-prod environment. I am using vCAC 6.0 and vCO 5.5.1. When I built the environment I ran the Library/vCloud Automation Center/Infrastructure Administration/Extensibility/Installation/Install vCO customization workflow. I changed the WFstubBuildingMachine and the WfStubMachineProvisioned. I want to run this workflow again to change the WFStubMachineDisposing. If I run it again and set everything to 'No' besides WFStubMachineDisposing will have any issues? I think I should be okay but would like to be safe.

Hi,)

I've been trying to grasp my head around the excellent script (orignally created by William Lam) to be able to vMotion a running VM from one Datacenter to another in different vSphere enviroments.

However all I end up with is the following:

Exception calling "RelocateVM_Task" with "2" argument(s): "

Required property key is missing from data object of type ServiceEndpoint

while parsing serialized DataObject of type vim.ServiceDirectory.ServiceEndpoint

at line 1, column 303

while parsing property "service" of static type ServiceEndpoint

while parsing serialized DataObject of type vim.vm.RelocateSpec

at line 1, column 297

while parsing call information for method RelocateVM_Task

at line 1, column 218

while parsing SOAP body

at line 1, column 207

while parsing SOAP envelope

at line 1, column 38

while parsing HTTP request for method relocate

on object of type vim.VirtualMachine

at line 1, column 0"

At C:\Users\anders.johansson\Desktop\MoveVMAcrossSSO.ps1:69 char:1

+ $task = $vm.extensiondata.RelocateVM_Task($rspec,"defaultPriority")

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

    + FullyQualifiedErrorId : VimException

I'm not a PS guru, but it seems some property has either changed or is missing. I can do RelocateVM within the same Datacenter (both source and target) from PowerCLI without any problem, it's the ServiceEndPoint that does not work.

I have included the $rspec variable:

Service

Folder

Datastore                      

Host

DeviceChange (Convert to dVS)

Source vSphere is 5.5 (Windows) and destination is Linux appliance (6.0.0)

Has anyone had success with this lately? 

Unfortunately I have only a single ESXi host for testing right now, but I will eventually be running this script on a vSphere setup with multiple hosts.

I want to get a VMs total committed size across all data stores.

I only have a single datastore on a single host to test right now so I want to be sure this will do the trick:

$VMView = Get-View -ViewType virtualmachine -filter @{'name' = 'MyVM'}

$DS = $VMView.Storage.PerDatastoreUsage

$DS.Committed | Measure-Object -Sum

I have two applications that I have packaged as AppStacks. I am using AppVolume 2.10, on Win7 64bit non-persistent desktops managed by VMware View 6.2.0. The applications, one of them is SnagIt, seem to work fine and are fully functioning with this exception. If you try and start the applications from a shortcut or the start menu the setup/install starts rather than the application itself.

If someone can point me to some logs or any possible solution I would appreciate it.

I just finished upgrading our three hosts from esxi 5.5 to 6. (blades in an IBM Blade S)

I upgraded the four vmfs volumes from 3 to 5 but two of the hosts are giving a warning of: Deprecated VMFS volumesfound on host.

Why is that?

thanks

Tracy

I recently built a new vRO 7.0 appliance in my environment so that I could evaluate rolling it out in my organization.  After setting the device up, I noticed the following error coming from several workflows:

ch.dunes.model.type.ConvertorException: Missing class to decode object

I had no idea what this meant so I had to open a case with Vmware Tech support.

Turns out, it's a known issue with a simple fix:

• Log onto the Appliance via SSH
• Run this command

   vi /usr/lib/vco/app-server/bin/setenv.sh

• Edit the JVM_OPS variable and add the following to the end: 

-Dsun.lang.ClassLoader.allowArraySyntax=true

The end result should look like this:

- Reboot the appliance

Hopefully this saves someone some time down the road.

I'm having an issue putting Docuware 6.7 Hotfix 44 in an app stack. The issue we are having is there is a web client and desktop apps. They use Certificates to allow the web client and desktop apps to communicate on Port 8090 for HTTP and port 8091 for HTTPS  using the local loopback address 127.0.0.1. When trying to use HTTPS we get and error that the web page cannot be displayed If we put DocuWare in the image it works fine and it also works fine after its been installed in an app stack during capturing. Once the App Stack is attached it doesn’t work. Our internal support team for DocuWare thinks it could be an issue with the certs, but they are really not sure. We have verified the certs are installed in the app stack.

Curious if anyone else has experience with DocuWare or putting certs in an app stack.

Thanks

Jeff

This document is a detail page for the VMware vExpert Directory.

Expert Information

View all vExpert entries

Hi there,

i just tried to update my ESXi Server to version 6.0 but it always stops complaining it has no network adapter.

Under 5.1 the system shows the onboard adapter as Realtek 8168 and it runs fine.

Is this chipset not supported anymore?

Thanx a lot for your support ...

Greetings from Düsseldorf, Germany