WilliamLam.com

Project Nanosphere

by // 5 Comments

The #NotSupported event at the VMworld Community Lounge ended with a very special presentation by our very own Randy Keener about a project that a few VMware engineers have been working on called Nanosphere. For those of you who could not make the session or attend VMworld this year, here is some additional information about what Project Nanosphere is all about.

What is Nanosphere?

First off, Nanosphere is not a product, it is a proof-of-concept. The idea is to make ESXi easier to deploy and manage for non-technical users in small environments (SOHO, remote/branch office, family) to get the same benefits of virtualization that enterprises have. Nanosphere provides an ultra-lightweight management layer on top of an ESXi host that will offer a basic set of features including self-configuration, VM provisioning, VM lifecycle management, and console access.Today, connecting to a VM console typically requires both server-side dependencies (a VDI broker, a Windows stack, or specialized guest customization) and client side dependencies (installing a special ActiveX browser plugin that works only on Windows, and only in IE or Firefox browsers). By deploying WSX on ESXi, it makes it possible to connect to any VM (any guest OS) with any modern browser (e.g. including iPad) without any special software.

What can Nanosphere do?

  • Network auto-configuration
    • Automatic network configuration without ever typing an IP address
  • Web Management Interface
    • Provision, Delete, Power On/Off Virtual Machines with pure HTML5 interface
  • Console access without special apps or plugins
  • Dead-simple installation
    • Just install a tiny VIB onto any ESXi host and you’re good to go. The VIB can also be integrated into a vanilla ESXi ISO image
During Randy’s session, a demo of the network autoconfiguration of Nanosphere and its web interface was given and here is how it works.Assuming you have a simple cable-model-like setup:

  1. The physical host has ESXi and Nanosphere installed.
  2. You "unbox" it (take it home from Staples) and plug it in on your home LAN, headless.
  3. It gets DHCP but you have no idea what the address is because it's headless.
  4. Nanosphere "phones home" to a broker running at nanosphere.cloudfoundry.com (custom application written on Cloudfoundry) to report its local LAN address (e.g. '192.168.0.4') and its UUID. The broker also records the WAN address.
  5. You use a plain browser on any device on the same LAN - we used an iPad - to connect to the same broker. It matches the WAN addresses and redirects the browser to the Nanosphere’s LAN address.
Here are a few screenshots of the Nanosphere web interface:

What's next for Nanosphere?

As mentioned earlier, nanosphere is still a proof-of-concept but the VMware engineers have some interesting ideas on where it could go and would love to get your feedback if the following use cases interests you.

  • Early adopters and hobbyists playing with ESXi for fun
  • VARs delivering Nanosphere-based servers in selected vertical markets
  • Nanosphere-based appliances delivering NAS and media streaming
  • Nanosphere-based servers for developing markets and nonprofit organizations
  • Hybrid public/Nanosphere clouds with bidirectional app portability
  • OEMs delivering Nanosphere-based servers through a retail channel
  • Value-added services like cloud backup and remote admin (including VMware GO)
Other work includes tracking ongoing WSX improvements. If any of these use cases interests you, please leave a comment below or if you have other ideas/feedback for Nanosphere, feel free to leave a comment as well.I think the Nanosphere project is a really cool initiative and hopefully we will get to see more in the future. I wanted to also give a big thanks to folks who worked on the Nanosphere project and made it possible to show off at the #NotSupported event: Steve Strassmann (VMware Staff Engineer), Shivam Tiwari (VMware Intern) and of course Randy Keener (VMware TechOps) for presenting on Project Nanosphere!

How to Enable Nested ESXi & Other Hypervisors in vSphere 5.1

by // 88 Comments

There are a ton of new features with the latest release of vSphere 5.1, but the one "unsupported" feature I always test first is "Nested Virtualization" (aka Nested ESXi) and with the latest release, it seems to have gotten even better. You will still need to have the same physical CPU prerequisites as you did in the past to run "Nested Virtualization" as well as nesting 64-bit VMs.

  • Intel VT-x or AMD-V is required for running "Nested Virtualization" which supports nested 32-bit VMs
  • Intel EPT or AMD RVI is required for running nested 64-bit VMs.

A quick way to verify whether your CPU truly supports both Intel-VT+EPT or AMD-V+RVI, you can paste the following into a browser:  

https://[your-esxi-host-ip-address]/mob/?moid=ha-host&doPath=capability

You will need to login with your root credentials and then look for the "nestedHVSupported" property and if it states false, it means you maybe able to install nested ESXi or other hypervisor, but you will not be able to run nested 64-bit VMs, only 32-bit VMs, assuming you have either Intel-VT or AMD-V support on your CPUs.

For more details, take a look at this article for troubleshooting: Having Difficulties Enabling Nested ESXi in vSphere 5.1?

Disclaimer: This is not officially supported by VMware, please use at your own risk.

There are some changes with Nested Virtualization in vSphere 5.1 also officially known as VHV (Virtual Hardware-Assisted Virtualization). If you are using vSphere 5.0 to run Nested ESXi or other nested Hypervisors, then please take a look at the instructions in this article. With vSphere 5.1, there have been a few minor changes to enable VHV.

  1. The new Virtual Hardware 9 compatibility will be required when creating your nested ESXi VM, Virtual Hardware 8 will not work if you are running ESXi 5.1 on your physical host. You will still need to enable promiscuous mode on the portgroup that will be used for your nested ESXi VM for network connectivity.
  2. vhv.allow = "true" is no longer valid for ESXi 5.1 to enable VHV. A new parameter has been introduced called vhv.enable = "true" that is now defined on a per VM basis to provide finer granularity of VHV support. This also allows for better portability between VMware's hosted products such as VMware Fusion and Workstation as they also support the vhv.enable parameter.
  3. You can now enable VHV on a per VM basis and using the new vSphere Web Client which basically adds the vhv.enable = "true" parameter to the VM's .VMX configuration file.

Note: You can run a nested ESXi 5.1 VM on top of a physical ESXi 5.0 host, just follow the instructions here.

Enabling VHV (Virtual Hardware-Assisted Virtualization)

Step 1 - Create a new Virtual Hardware 9 Virtual Machine using the new vSphere Web Client that's available with vCenter Server 5.1.

Step 2 - Select "Linux" as the guestOS Family and "Other Linux (64-bit)" as the guestOS Version.

Step 3 - During the customize hardware wizard, expand the "CPU" section and select "Hardware Virtualization" box to enable VHV.

Note: If this box is grayed out, it means that your physical CPU does not supported Intel VT-x + EPT or AMD-V + RVI which is required to run VHV OR that you are not using Virtual Hardware 9. If your CPU only supports Intel-VT or AMD-V, then you can still install nested ESXi, but you will only be able to run nested 32-bit VMs and not nested 64-bit VMs.

Step 4 - It is still recommended that you change the guestOS Version to VMware ESXi 5.x after you have created the VM shell, as there are some special settings that are applied automatically. Unfortunately with the new vSphere Web Client, you will not be able to modify the guestOS after creation, so you will need to use the C# Client OR manually go into the .VMX and update guestOS = "vmkernel5"

Now you are ready to install nested ESXi VMs as well as run nested 64-bit VMs within.

If you have followed my previous article about How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5 you may recall a diagram about the levels of "Inception" that can be performed with nested ESXi. That is, the number of times you could nest ESXi and still have it be in a "functional" state. With vSphere 5.0, the limit that I was able to push was 2 levels of nested ESXi. With latest release of vSphere 5.1, I have been able to push that limit now to an extraordinary 3 levels of inception!

You might ask why would someone want to do this ... well I don't have a good answer other than ... because I can? 😉 VHV is one of the coolest "unsupported" feature in my books and I'm glad it is working beyond what it was designed for.

For proper networking connectivity, also ensure that either your standard vSwitch or Distributed Virtual Switch has both promiscuous mode and forged transmit enabled either globally on the portgroup or distributed portgroup your nested ESXi hosts are connected to.

Nesting "Other" Hypervisors

For those of you who feel inclined to run other hypervisors such as Hyper-V, you can do so with latest release of ESXi 5.1. The process if very straight forward just like running nested ESXi host.

Step 1 - Create a Virtual Hardware 9 VM and select the appropriate guestOS. In this example, I selected Windows Server 2012 (64-bit) as the guestOS version.

Step 2 - Enable VHV under the CPU section if you wish to create and run nested 64-bit VMs under Hyper-V

Step 3 - You will need to add one additional .vmx parameter which tells the underlying guestOS (Hyper-V) that it is not running as a virtual guest which in fact it really is. The parameter is hypervisor.cpuid.v0 = FALSE

How to Enable Nested ESXi & Other Hypervisors in vCloud Director 5.1

by // 5 Comments

The process to enable  "Nested Virtualization" in the latest release of vCloud Director 5.1 and create your own virtual lab similar to VMware's vSEL (Virtual Sales Enablement Cloud) is very similar to the previous steps outlined for vCloud Director 1.5 release. The only change is how VHV (Virtual Hardware-Assisted Virtualization) aka "Nested Virtualization" is enabled in vCloud Director 5.1 and ESXi 5.1.

In the vCloud Director 1.5, to enable VHV, you needed to add a special SQL statement that would enable VHV for the underlying ESXi 5.0 hosts. With the latest release of vCloud Director 5.1, that is no longer necessary and you now enable it on a Per VM basis within the vCloud Director 5.1 UI.

Here are the steps for enabling VHV for vCloud Director 5.1

  • Insert SQL statements into VCD Database that perform the following:
    • Enable new "VMware" guestOS Family
    • Enable new guestOS Type ESXi 4.x and 5.x
    • Enable host preparation to enable VHV (vSphere 5.0 & vCloud 1.5 only)
  • Enable promiscuous mode
    • Insert SQL statement into VCD Database for Network Pool that is being used for your ESXi VMs
    • Enable both Promiscuous Mode and Forged Transmit for vSphere Backed Portgroup within vCenter Server or ESXi host

The SQL statements can be found in this article and have not changed for vCloud Director 5.1

Here is a screenshot of what you should see in the vCloud Director 5.1 UI for creating a new VM and you should now have the ability to select a new guestOS Type called "VMware" and select either an ESXi 4.x or ESXi 5.x guestOS Version.

To enable VHV for the VM, you will need to also check the box "Exposed hardware-assisted CPU virtualization to guestOS" and this will allow you to run a nested ESXi VM as well as 64-bit nested VMs, assuming your physical CPUs support it. To learn more about running VHV on ESXi 5.1, take a look at this article here for more details.