Enabling nested 64-bit virtual hosts on vCloud Director 1.5 using MSSQL

After a crash of the database inside of my lab, I was forced to setup my vCloud Director environment once more. Before you ask, yes, I did have a backup of my database. But as Murphy would have it, it wasn’t usable for a restore.

Anyway, this allowed me to actually re-create my environment, which wasn’t a bad thing. My idea was to create an easy to use nested 64-bit vSphere environment, where I could actually quickly deploy a vSphere lab to work/test/play with.

First off, I had to enable my hosts to allow nested 64-bit vSphere guests to be installed. A way to set this up can be found here.

In summary, you can either manually add the following line:
vhv.allow = "TRUE"
to the file /etc/vmware/config on your ESXi host, or you can SSH to your ESXi host, and use the following esxcli command to set the flag (which only works if the vCloud agent has already been installed, as @lamw correctly pointed out on Twitter here):
esxcli vcloud esxvm enable64bitnested

So much for step one. 😉

But now comes the fun part, enabling this in vCloud Director. Basic instructions on how to do that can be found here, and I can only confirm the warning given there:

---

This is not a supported configuration by VMware and this can disappear at any time, use at your own risk!

---

Since the instructions found on virtuallyGhetto are a bit more targeted towards Oracle, I thought I’d might as well share the instructions for a Microsoft SQL server, since these are slightly different.

For starters, go to the SQL server that is running your vCloud Director database, open the Object Explorer, and run a query against the dbo.config table that will allow nested 64-bit systems to run inside of vCloud Director. That query should look like this:

USE ReplaceWithYourDatabaseName;
SELECT config_it, cat, name, value, sortorder
FROM dbo.config
WHERE (name = 'extension.esxvm.enabled');

From there you can simply edit the value from “false” to “true”

Next up, you need to create an additional guest operating system type. However, by default you don’t have any permissions to add values to the table, so on SQL2008, you need to first change the “IDENTITY_INSERT” setting for the table, add the new family type, and finally set the Identity Insert value back to it’s original value, which goes like this:

USE ReplaceWithYourDatabaseName;
SET IDENTITY_INSERT dbo.guest_osfamily ON;
INSERT
INTO dbo.guest_osfamily (family_id,family)
VALUES (6,'VMware ESX/ESXi');
SET IDENTITY_INSERT dbo.guest_osfamily OFF;


Next up, we need to insert the operating systems for the entry we just created. We do this once for ESXi 4.1:

USE ReplaceWithYourDatabaseName;
SET IDENTITY_INSERT dbo.guest_os_type ON;
INSERT INTO dbo.guest_os_type
(guestos_id, display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version,
supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto,
is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version)
VALUES (81, 'ESXi 4.x', 'vmkernelGuest', 6, 1, 1, 8, 3072, 7, 1, 1, 4, 8, 0, 0, 0, 0, 107, 40);
SET IDENTITY_INSERT dbo.guest_os_type OFF;

And once more for ESXi 5:

USE vmvblvcd15;
SET IDENTITY_INSERT dbo.guest_os_type ON;
INSERT INTO dbo.guest_os_type
(guestos_id,display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version, supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto, is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version)
VALUES (82, 'ESXi 5.x', 'vmkernel5Guest', 6, 1, 1, 8, 3072, 7,1, 1, 4, 8, 0, 0, 0, 0, 107, 50);
SET IDENTITY_INSERT dbo.guest_os_type OFF;

Should the query analyzer give an error on the 81 or 82 values, you can increase these, because that just means that these values were already in use in the table. Just increase the numbers until the query analyzer doesn’t give you an error anymore.

And that’s it. You should now be able to see the new options when you create a new virtual machine for your vApp.

There are some additional steps to follow if you actually want to use the newly created options though. You need to restart the vCloud Director daemon on your vCloud cells, and re-prepare your hosts. Also, make sure to set promiscuous mode for the portgroups backing your vCloud network infrastructure, and you can check the post virtuallyGhetto for the details on that.