So far I’ve concentrated on getting vESX, vCenter, pStorage and vStorage (in the shape of NetApp’s VSA) working within the construct of vApp (vINCEPTION1). What I have yet to do is create VMs on vINCEPTION1, to create vINCEPTION2 guest. If you recall I’m using the term vINCEPTION0 to describe the physical layer of physical servers running pESX, and vINCEPTION1 to refer to running vESX inside a VM on top of pESX. vINCEPTION2 is where you run a VM on vESX on pESX… you can think of these different layers as like the circles of Inferno in Dante’s Divina Comedia if you like. 😉
As you might recall in previous posts I’d mounted my “ISOs” and “Templates” NFS datastores (NetApp) from the vESX to the physical storage layer – and I also gave my vESX host access to my ISCSI Targets too (Dell Equallogic). I was pretty impressed with the disk IO cloning times. If you remember my vESX hosts connect directly to “storage” Organization Network, and then on to the External Network where my pStorage is located.
So it was a relatively trivial affair to browse the “templates” datastore and register one of my VMTX (template) files, and hit the “Deploy VM from this Template” option. Of course I forgot those templates were associated with networking from a totally different vCenter (the pvCenter if you like – I’m joking!).
By default although the virtual NIC in the nested VM will sense a network it won’t get an IP address from the vCNS Edge Gateway, and even if its configured with a static IP address it won’t be able to communicate to the wider world.
That’s because of the security settings backing the network at the vINCEPTION0 level. If you remember my networking is nested as well, and remember there’s the vCloud Director network layers to consider as well. I often call this the “Dem Bones” scenario – because vApp Networks connect to Organization Networks and Organization Networks connect to External Networks (and hear the word of the de Lord!)…
In my case the vESX hosts (vmnic0/1/2) are connected directly to the Organization Network called CorpHQ-CorpOrgNetwork, whereas vmnic3 is connected to the CorpHQ-StorageOrgNetwork like so:
So to allow the comms to flow from the nested VM through the nested-vESX host onto the pESX host and the pNetwork – I need to change the security settings backing the portgroup servicing CorpHQ-CorpOrgNetwork much in the same way I did for CorpHQ-StorageOrgNetwork for accessing the pStorage layer. The default out-of-the-box security for portgroups made by the vCNS Edge Gateway is reject;reject;reject and so I need to loosen that policy up.
I little bit of ipconfig /renew and my nested VM running on my nested ESX was ready to rumble…
So far I think this configuration series as been (relatively) simple. The one thing I’ve been fearing is the vCloud Director layer – being placed on top of nested vESX environment. I’m planning on pinging a couple of emails out to my colleagues to ask them for a sanity check before I loose my silver foil unicorn altogether…!