When I was building vRA 7 and figuring everything out, at some point I set the ‘Default machine prefix‘ for the Business Groups. When you first create a Business Group, setting the default machine prefix is optional; However, if you do set this value then there is no way to unset it, which I find extremely annoying. As I don’t currently use specific prefixes for business groups, I was feeling a little OCD having to set this to some other prefix value.
I was able to ignore this for a while until I installed the Custom Hostnaming Extension for vRA7 by Dailyypervisor. This extension is really awesome and has helped me massively overcome my requirement to create dynamically generated hostnames. The hostnames are based on our internal naming convention and I make good use of Custom Properties for this. For testing, I simply created a very basic custom hostname scheme ‘{LOC}-GSTEST{##}’, with {LOC} being set on one of the vSphere endpoints.
At first this appeared to work just fine, until randomly some machines would be provisioned using a different hostname. The other hostname was based on another machine prefix that I had created previously and was configured as the default for the Business Group, which was ‘ES-VWOI-MANA##’. The image below shows the results of 7 machines provisioned using the custom hostname extension.
Clearly what is happening here is that on each provisioning attempt, it is randomly selecting a different machine prefix. What is also interesting is that both prefixes get incremented. In fact, that’s another issue with having a default one set for the business group (or even within the Blueprint), is that they are ‘allocated’ and incremented even before the EBS is used (which is when the custom hostnaming extension kicks in, at the requested stage, which is still AFTER the allocation). I have had a small look at the code for the workflow and can see that it’s identifying that the custom hostname scheme already exists, but I haven’t yet looked into why it’s setting the wrong one.
I figured the easiest workaround for now would be to simply remove the default machine prefix from the business group and make sure no one accidently sets it. But this is when I realised you can’t do that by simply editing the group via the IaaS interface. To cut a long story short, you have to manually remove this on the database, both the SQL database used by IaaS and the PostGres database used by vRA.
[stextbox id=”warning”]Warning, use the following information at your own risk. I take no responsibility if you trash the database when attempting to follow the steps below. You should take a full backup or snapshot the VMs before making any changes to the databases.[/stextbox]
Page Contents
Remove Machine Prefix from Business Group on IaaS SQL Database
You will need to log into the Microsoft SQL database as a user that can edit the ‘vra‘ database (if you’re using the default like I am). I just want to say at this point that I am no dBA and will be doing this all clicky clicky using SQL Server Management Studio. The table that you will need to edit is the ‘dbo.ProvisioningGroup‘ table. If you right click on the table there will be an option to ‘Edit Top 200 Rows’.
The results will look something like this:
Under the ‘HostnamePrefixID‘ column you can see that an ID has been set for my Business Group shown earlier. If you want to confirm that this ID does in fact match the machine prefix in question then you can check the ‘dbo.HostNamePrefix‘ table. To remove this association simply replace the PrefixID with ‘NULL‘. If you have any problems with this then simply copy and paste from one of the other cells. The changes will automatically be saved.
However, we’re not done. The business group will still show that the default machine prefix is still set. A change is also required on vRA’s PostGres database.
Remove Machine Prefix from Business Group on vRA PostGres Database
In order to carry out the next steps you will need to enable SSH on the vRA appliance, which can be done via the VAMI interface. Once you have done this log into the vRA appliance using SSH as the root user.
Connect to the PostGres server:
VRAA01:~ # /opt/vmware/vpostgres/9.4/bin/psql -U postgres psql.bin (9.4.5 (VMware Postgres 9.4.5.0-3183988 release)) Type "help" for help.
Connect to the vRA database:
postgres=# \c vcac You are now connected to database "vcac" as user "postgres".
The default machine prefix for the business group is set in the ‘subtenant‘ table (note that I have turned Expanded display mode on).
vcac-# \x Expanded display is on. vcac=# select * from subtenant;
In the ‘extension_data‘ property you can see that one of these attributes is ‘iaas-machine-prefix‘ with a value that matches the ID for the machine prefix that was removed from the vRA/IaaS SQL database. To remove the machine prefix you will need to update this entry and provide a new extension data payload. Below shows the new payload with the ‘iaas-machine-prefix‘ part removed.
Make sure to edit this properly in notepad beforehand. Also note that I am wrapping the entire string in a single quote ‘ as the double quotes “” are part of the extension data.
update subtenant SET extension_data = '"iaas-ad-container"=>"{\"type\":\"string\",\"value\":\"\"}", "iaas-manager-emails"=>"{\"type\":\"string\",\"value\":\"Gavin.Stephens@xxx.xxx\"}"' WHERE id = '643545f9-1e26-4178-bacb-f4d9363b00c0';
UPDATE 1
Issuing another select from the table should reveal that the ‘iaas-machine-prefix‘ entry no longer exists in extension_data.
Switching back to the IaaS portal and we can see that the default machine prefix for the business group is now un-set.
I should probably raise this with VMware and see if they can provide the ability to just unselect this on the IaaS portal.
Any thoughts, or comments then please let me know!