If we remote desktop to an Azure Instance for a PAAS role and look at the hostname we see something as below.
It’s not very useful while troubleshooting in case you want know to which particular Instance maps to this particular RD0003FF40585A name, moreover this will change in case the virtual machine is re-incarnated. For example I get the following when I try to see which Instance is connected to my SQL Azure database.
I have a PAAS Cloud Service running a PHP site which talks to SQL Azure. I sent a request and then I run the DMV sys.dm_exec_sessions on SQL Azure to find the connected host. So the hostname for the instance is RD0003FF40585A (the ANSHUWIN7 is my on premise SQL Server Management Studio). How do I tie back this RD0003FF40585A name to the instance in case I don’t have RDP? Also we might have a scenario, where there might be multiple instances say 50 and it will be really tiresome to (very time consuming for troubleshooting as well) to look at 49 instances (worst case) to identify where the connection might have initiated from. The above entry is made by a database driver code and hence a developer will have no option to override it with the RoleEnvironment class properties either to provide some instance related logging.
While providing a solution to customer on such a scenario I stumbled upon a rather nifty albeit not widely known feature of Windows Azure. It really solves the RD name to Actual Instance identification problem.
In the ServiceConfiguration file for the role we need to add a key called vmName.
<?xml version="1.0" encoding="utf-8"?> <ServiceConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" serviceName="myPhpProjects" osFamily="2" osVersion="*" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"> <Role name="myPhpRole" vmName="phpInst"> <ConfigurationSettings /> <Instances count="1" /> <Certificates /> </Role> </ServiceConfiguration>
After the ServiceConfiguration was saved we deployed the Role again. If the deployment is done via portal then only the modified ServiceConfiguration file can be uploaded. Now if we do an RDP and look at the hostname of the machine we see something as below.
Now if we try to see for the instance which connected to the database we can something as below.
The hostname beautifully becomes PHPINST0 and PHPINT1 for Instance 0 and Instance 1 respectively. If we were logging custom error from the instance we would know exactly which instance was giving error and we can take corrective steps like recycling or reimaging the exact instance.
There is an MSDN article which mentions about the vmName option http://msdn.microsoft.com/en-us/library/windowsazure/jj156077.aspx
There is another thing I would like to mention here as I think it’s useful. While deploying the role I got the following error often.
PS H:\Projects\PHP\myPhpProjects> Import-AzurePublishSettingsFile 'H:\Study Material\Azure Publish Profile\CIE-annayak-dsdazure-annayak-3-1-2014-credentials.publishsettings' Publish-AzureServiceProject WARNING: Publishing myPhpProjects to Windows Azure. This may take several minutes... WARNING: 12:42:41 PM - Preparing runtime deployment for service 'myPhpProjects' WARNING: 12:42:43 PM - Verifying storage account 'myphpprojects'... WARNING: 12:42:45 PM - Preparing deployment for myPhpProjects with Subscription ID: fc50b687-42f8-415e-86b8-5fa83024aa3d... WARNING: 12:42:50 PM - Connecting... WARNING: 12:43:00 PM - Uploading Package to storage service myphpprojects... WARNING: 12:43:11 PM - Upgrading... Publish-AzureServiceProject : BadRequest: The specified configuration settings for Settings are invalid. Verify that the service configuration file is a valid XML file, and that role instance counts are specified as positive integers. At line:3 char:1 + Publish-AzureServiceProject + ~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Publish-AzureServiceProject], CloudException + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.CloudService.PublishAzureServiceProjectCommand
The reason for this is that the vmName can only be 10 characters wide (I didn’t get any documentation, just stumbled upon after multiple failures of deploying the role). I hope this information save you some trouble deploying the role.
Angshuman Nayak, Cloud Integration Engineer