You might find yourself needing to run a Solaris 11 host with non-global zones running as a VMWare guest for a number of reasons. Generally, I would run a Solaris zone host on bare metal for production, but it can work under VMWare as well in more limited deployment. Still, this might be more common in a lab environment.
A zone host running non-global zones doesn’t require any special changes, other than to networking. For zones to operate correctly, the interface at the global zone level must be running in promiscuous mode. You can see this most easily if you have a simple network configuration at the global zone level:
NAME CLASS/TYPE STATE UNDER ADDR lo0 loopback ok -- -- lo0/v4 static ok -- 127.0.0.1/8 lo0/v6 static ok -- ::1/128 net0 ip ok -- -- net0/v4 dhcp ok -- 192.168.1.179/24 net0/v6 addrconf ok -- xxxxxxx root@solzhtest:~# dladm LINK CLASS MTU STATE OVER net0 phys 1500 up -- testz/net0 vnic 1500 up net0
A simple non-global zone configuration (the default) would then have an anet device which will default to using net0 as its underlying device:
anet: linkname: net0 lower-link: auto
At this point, a “stock” Solaris 11 install with a simple non-global zone will not work. Your first sign of trouble will be if your non-global zone has DHCP addresses configured; they won’t be assigned an address.
VMWare — Allow Promiscuous Network
Your first step at this point is to check VMWare to ensure that promiscuous network connections are allowed. This can vary a bit depending upon the complexity of your VMWare setup. For a simple stand-alone ESXi server, you’ll need to edit the standard switch security settings to allow promiscuous interfaces.
snoop To the Rescue
If you’ve made the appropriate changes to VMWare, you can test whether setting the interface to promiscuous mode will now work by using snoop on the net0 interface. In the global zone:
snoop -r -d net0 >/dev/null &
Now, you can return to the console of your non-global zone and try to refresh your DHCP lease (or simply using the network if you have a statically configured interface). It should work. If you kill snoop, it should stop working.
A Permanent Solution
One permanent solution is to put the above snoop command into a startup script. It works.
Perhaps a better option is to setup a bridged interface in the global zone. You’ll need to install the bridging package if it isn’t already present, and then add net0 to the bridge:
pkg install pkg://solaris/network/bridging dladm create-bridge -l net0 mybridge
That’s it. Once the above steps are done, net0 is operating in promiscuous mode and your zone networking should work as expected.
Reasonably well documented in most other places is that in order for kernel-zones to work, you’ll need to ensure that your VMWare guest has virtual-extensions enabled. You can use the virtinfo command in the global zone to see whether these extensions are available:
root@solzhtest:~# virtinfo NAME CLASS vmware current non-global-zone supported
The lack of a line mentioning kernel zones is your indication that they aren’t supported. You can also run virtinfo with specific options:
root@solzhtest:~# virtinfo -c supported list kernel-zone kernel-zone: no such supported virtual environment found
In order to enable this support, shutdown your VMWare guest and enable VT-x extensions. In VMWare Fusion, this is done under the Advanced options, Enable hypervisor applications in the virtual machine. In vCenter 6, you can edit the VM settings, then expand CPU, looking for this setting Expose hardware assisted virtualization to the guest. Once you check this option and start your guest VM, you should see kernel zone support provided:
root@solzhtest:~# virtinfo NAME CLASS vmware current non-global-zone supported kernel-zone supported root@solzhtest:~# virtinfo -c supported list kernel-zone NAME CLASS kernel-zone supported
This should get your non-global zones and kernel zones up and running under your VMWare guest.