locked
Azure VM empty host name - no ssh RRS feed

  • Question

  • On my Azure VM, my host name is empty. In addition, I can't ssh to that machine.

    Any ideas what might cause this?

    Sunday, March 15, 2015 3:10 PM

Answers

  • Hi,

    Please try the below general troubleshooting steps :

    • Restart VM
    • Recreate endpoint
    • Connect from different location
    • Resize VM
    • Recreate VM
    • In the management portal, go to Virtual Machines, select the problem VM, select Dashboard, and make note of the following information under Quick Glance on the right side of the page:

      Status (should be "Running")

      DNS (<name>.cloudapp.net, this is what the RDP file from clicking "Connect" will try using) 

      Host Name (should be computer name/host name, "Retrieving..." may indicate a problem)

      Public Virtual IP (VIP) Address - external IP address, can try connecting to this or DNS name

      Internal IP Address - can try this from another VM in same cloud service/virtual network

      If Status is not Running, that narrows it down to the VM not being fully started, so there is no network issue to troubleshoot, just the issue of getting it started.

      If Status is Provisioning (Timed Out) this is commonly see with VMs created from a custom image or disk. If created from a custom image, the VHD used for the image must have been generalized with sysprep (Windows) or the provisioning agent installed (Linux). If created from a custom disk, the VHD used for the disk must NOT have been generalized with sysprep or prepared for provisioning (Linux).

      Host Name of Retrieving... means Azure was not able to get the host name via DHCP yet. It could be the VM hasn't fully booted, but also that a static IP has been set, network adapter disabled,  
    • Restart VM - assuming the Status is Running, but you are unable to connect, try restarting the VM using the management portal. Go to Virtual Machines, select the problem VM, select Dashboard, then click Restart at the bottom of the page. Wait until it gets back to Status of Running, then try connecting again.
    • Recreate Endpoint - external access to the VM is only available through endpoints that control which specific TCP/UDP ports are open to it. By default, endpoints for RDP (TCP 3389) and PowerShell (TCP 5986) are created for Windows VMs and for Linux VMs an endpoint for SSH (TCP 22).

      To recreate the endpoint for the service you are trying to access (RDP/SSH/HTTP, etc.), in the management portal, select Virtual Machines, select the problem VM, select Endpoints at the top, select the desired endpoint, then click Delete Endpoint at the bottom of the page. After the endpoint is deleted, click Add Endpoint, leave the radio button on Add Endpoint, click Next, then specify the name (just a display name, doesn't need to be the same as it was, i.e. can use "RDP" instead of "RemoteDesktop"), the protocol (TCP or UDP), the public port and the private port, then click Next to create the endpoint.

      Since connectivity issues can be a result of outbound traffic to specific ports being blocked at corporate firewalls, as a test, you can try setting the public port to the same thing as the private port (so 3389 and 3389 for RDP, or 22 and 22 for Linux) instead of the random ephemeral port in the 49152-65365 range that is used by default when the VM is created. Though keep in mind that having the public port be on a random ephemeral port may keep it off the radar of someone who is port scanning the Azure IP ranges. So ultimately you may want to put it back on an ephemeral port after working things out with your firewall administrator (if that was in fact the issue).
    • Connect from different network - to rule out the possibility that traffic is being blocked from the network you are on (i.e. behind corporate firewall), try connecting to the VM from a different network (like from public wifi, or from home, etc.). If connecting from a different network succeeds, this indicates a problem connecting from the original location, so possibly the port is blocked outbound by your corporate firewall and you should verify with your network administrator if this is the case. You may need proxy client software or have them open the outbound port.
    • Resize VM - changing the virtual machine size (i.e. Medium to Large) will usually result in the VM being moved to run on a different host server. So if there is a problem specific to the host where the VM is currently running, changing the size will usually move it to a different host server. Though commonly just resizing once will get the VM on a different host, there is the chance that the VM can be resized in-place on the same host. Since there is no customer-exposed way to tell if the VM ended up on a different host, this means it is prudent if the first resize doesn't help, to just resize it back to the original size to help rule out the possibility that it didn't have to move to a different host on the first resize.

      ***WARNING*** All data on the D: drive will be lost when changing the virtual machine size and the VM ends up on a different host. This is why the volume label for D: is TEMPORARY STORAGE. All other drives (C: drive and any data disks attached) are persistent as they are backed by VHDs that reside in your storage account. The D: drive resides on the host server itself locally, and is only used for the page file. So if you have data on D: that you care about losing, move it to C: or to a data disk (F:, etc.) before changing the virtual machine size.

      Note that the internal IP address of the VM will change if the resize results in the VM running on a different host, because the new host server will present a virtual network adapter with a different hardware ID, which will be detected as a new network adapter in Windows and it will get a different IP from Azure's DHCP. If the VM is in a virtual network, the internal IP address will not change after resizing, because the internal IP is mapped to that VM after it is first provisioned, and it will keep getting that same IP regardless of the host it runs on.

      To resize the VM, in the management portal, go to Virtual Machines, select the problem VM, select Configure at the top, then change Virtual Machine Size to something different. Resizing it up or down will work, although resizing it up gives a better chance of it moving to a different host. Whether or not this resolves the connectivity issue, you can resize it back to the original size after temporarily changing it.
    • Recreate VM - in some situations, removing the VM and deploying it again from the same VHD will resolve an issue.

      Recreate the VM using the management portal

      To recreate the VM in the management portal, select Virtual Machines, select the problem VM, and click Delete at the bottom of the page. Note that this does not delete the VHD for the VM.

      Now go to Cloud Services (on the left, instead of Virtual Machines), and you will see the now-empty cloud service for the VM. Though it may seem as if the VM has moved to Cloud Services, that is because doing a Quick Create will always give the VM and the cloud service the same name. So it isn't that the VM moved to Cloud Services, it is that the cloud service was hidden by the portal while there was a VM in it. Currently it is not possible to redeploy a VM back into that empty cloud service using the portal (though this is possible with Import-AzureVM in Azure PowerShell). So if you want the same DNS name as before, you must delete the cloud service.

      ***WARNING*** The cloud service is what reserves the DNS name and external IP. When you delete the cloud service, you can get the same DNS name back (there is that slight chance that someone could use it between the time you deleted it and tried using it again yourself). But you cannot get the same external IP address back, as these are randomly assigned. So if you have dependencies on the external IP staying the same, know that this step will change it. To delete the cloud service, select it and click Delete at the bottom of the page.

      Note that if you have more than one VM in the cloud service, there is no need to recreate the cloud service since the portal does allow redeploying to the same cloud service if it is not empty (by selecting Connect to an existing virtual machine on the Virtual Machine Mode page when creating the VM).

      Give it a few minutes (no more than 5 min.) after it says the VM was deleted to make sure the disk no longer shows up as being attached to the VM that was removed. Then click New at the very bottom left of the management portal, select Compute, Virtual Machine, From Gallery. Select My Disks and select the disk for the VM that was just removed (can take a few minutes for it to show up here). Enter a VM name (can be the same as before) and choose the size, then on the Virtual Machine Mode page, select Stand-alone Virtual Machine if you had deleted the cloud service, and enter the same (or a different) DNS Name as before. If you had more than one VM in the cloud service, you can deploy it back into that same cloud service (and get the same DNS name and external IP address as before) by selecting Connect to an existing virtual machine and choose the relevant cloud service). Then complete the rest of the VM create wizard.

    Regards,

    Shirisha Paderu

    Monday, April 20, 2015 8:04 AM

All replies

  • Hi,

    Is that a Linux VM ?

    What is the error message you are getting when you are trying to SSH into it ? Could you share the exact error message to finely identify the issue.

    Regards,

    Shirisha Paderu

    Monday, March 16, 2015 7:29 AM
  • Hi,

    Has this issue sorted out ? If so, could you please share the work around so that it can help others who has similar issues.

    Regards,

    Shirisha Paderu


    Tuesday, April 7, 2015 4:34 PM
  • Same problem here too. Did not find a solution yet.
    Friday, April 17, 2015 8:55 PM
  • Hi,

    Please try the below general troubleshooting steps :

    • Restart VM
    • Recreate endpoint
    • Connect from different location
    • Resize VM
    • Recreate VM
    • In the management portal, go to Virtual Machines, select the problem VM, select Dashboard, and make note of the following information under Quick Glance on the right side of the page:

      Status (should be "Running")

      DNS (<name>.cloudapp.net, this is what the RDP file from clicking "Connect" will try using) 

      Host Name (should be computer name/host name, "Retrieving..." may indicate a problem)

      Public Virtual IP (VIP) Address - external IP address, can try connecting to this or DNS name

      Internal IP Address - can try this from another VM in same cloud service/virtual network

      If Status is not Running, that narrows it down to the VM not being fully started, so there is no network issue to troubleshoot, just the issue of getting it started.

      If Status is Provisioning (Timed Out) this is commonly see with VMs created from a custom image or disk. If created from a custom image, the VHD used for the image must have been generalized with sysprep (Windows) or the provisioning agent installed (Linux). If created from a custom disk, the VHD used for the disk must NOT have been generalized with sysprep or prepared for provisioning (Linux).

      Host Name of Retrieving... means Azure was not able to get the host name via DHCP yet. It could be the VM hasn't fully booted, but also that a static IP has been set, network adapter disabled,  
    • Restart VM - assuming the Status is Running, but you are unable to connect, try restarting the VM using the management portal. Go to Virtual Machines, select the problem VM, select Dashboard, then click Restart at the bottom of the page. Wait until it gets back to Status of Running, then try connecting again.
    • Recreate Endpoint - external access to the VM is only available through endpoints that control which specific TCP/UDP ports are open to it. By default, endpoints for RDP (TCP 3389) and PowerShell (TCP 5986) are created for Windows VMs and for Linux VMs an endpoint for SSH (TCP 22).

      To recreate the endpoint for the service you are trying to access (RDP/SSH/HTTP, etc.), in the management portal, select Virtual Machines, select the problem VM, select Endpoints at the top, select the desired endpoint, then click Delete Endpoint at the bottom of the page. After the endpoint is deleted, click Add Endpoint, leave the radio button on Add Endpoint, click Next, then specify the name (just a display name, doesn't need to be the same as it was, i.e. can use "RDP" instead of "RemoteDesktop"), the protocol (TCP or UDP), the public port and the private port, then click Next to create the endpoint.

      Since connectivity issues can be a result of outbound traffic to specific ports being blocked at corporate firewalls, as a test, you can try setting the public port to the same thing as the private port (so 3389 and 3389 for RDP, or 22 and 22 for Linux) instead of the random ephemeral port in the 49152-65365 range that is used by default when the VM is created. Though keep in mind that having the public port be on a random ephemeral port may keep it off the radar of someone who is port scanning the Azure IP ranges. So ultimately you may want to put it back on an ephemeral port after working things out with your firewall administrator (if that was in fact the issue).
    • Connect from different network - to rule out the possibility that traffic is being blocked from the network you are on (i.e. behind corporate firewall), try connecting to the VM from a different network (like from public wifi, or from home, etc.). If connecting from a different network succeeds, this indicates a problem connecting from the original location, so possibly the port is blocked outbound by your corporate firewall and you should verify with your network administrator if this is the case. You may need proxy client software or have them open the outbound port.
    • Resize VM - changing the virtual machine size (i.e. Medium to Large) will usually result in the VM being moved to run on a different host server. So if there is a problem specific to the host where the VM is currently running, changing the size will usually move it to a different host server. Though commonly just resizing once will get the VM on a different host, there is the chance that the VM can be resized in-place on the same host. Since there is no customer-exposed way to tell if the VM ended up on a different host, this means it is prudent if the first resize doesn't help, to just resize it back to the original size to help rule out the possibility that it didn't have to move to a different host on the first resize.

      ***WARNING*** All data on the D: drive will be lost when changing the virtual machine size and the VM ends up on a different host. This is why the volume label for D: is TEMPORARY STORAGE. All other drives (C: drive and any data disks attached) are persistent as they are backed by VHDs that reside in your storage account. The D: drive resides on the host server itself locally, and is only used for the page file. So if you have data on D: that you care about losing, move it to C: or to a data disk (F:, etc.) before changing the virtual machine size.

      Note that the internal IP address of the VM will change if the resize results in the VM running on a different host, because the new host server will present a virtual network adapter with a different hardware ID, which will be detected as a new network adapter in Windows and it will get a different IP from Azure's DHCP. If the VM is in a virtual network, the internal IP address will not change after resizing, because the internal IP is mapped to that VM after it is first provisioned, and it will keep getting that same IP regardless of the host it runs on.

      To resize the VM, in the management portal, go to Virtual Machines, select the problem VM, select Configure at the top, then change Virtual Machine Size to something different. Resizing it up or down will work, although resizing it up gives a better chance of it moving to a different host. Whether or not this resolves the connectivity issue, you can resize it back to the original size after temporarily changing it.
    • Recreate VM - in some situations, removing the VM and deploying it again from the same VHD will resolve an issue.

      Recreate the VM using the management portal

      To recreate the VM in the management portal, select Virtual Machines, select the problem VM, and click Delete at the bottom of the page. Note that this does not delete the VHD for the VM.

      Now go to Cloud Services (on the left, instead of Virtual Machines), and you will see the now-empty cloud service for the VM. Though it may seem as if the VM has moved to Cloud Services, that is because doing a Quick Create will always give the VM and the cloud service the same name. So it isn't that the VM moved to Cloud Services, it is that the cloud service was hidden by the portal while there was a VM in it. Currently it is not possible to redeploy a VM back into that empty cloud service using the portal (though this is possible with Import-AzureVM in Azure PowerShell). So if you want the same DNS name as before, you must delete the cloud service.

      ***WARNING*** The cloud service is what reserves the DNS name and external IP. When you delete the cloud service, you can get the same DNS name back (there is that slight chance that someone could use it between the time you deleted it and tried using it again yourself). But you cannot get the same external IP address back, as these are randomly assigned. So if you have dependencies on the external IP staying the same, know that this step will change it. To delete the cloud service, select it and click Delete at the bottom of the page.

      Note that if you have more than one VM in the cloud service, there is no need to recreate the cloud service since the portal does allow redeploying to the same cloud service if it is not empty (by selecting Connect to an existing virtual machine on the Virtual Machine Mode page when creating the VM).

      Give it a few minutes (no more than 5 min.) after it says the VM was deleted to make sure the disk no longer shows up as being attached to the VM that was removed. Then click New at the very bottom left of the management portal, select Compute, Virtual Machine, From Gallery. Select My Disks and select the disk for the VM that was just removed (can take a few minutes for it to show up here). Enter a VM name (can be the same as before) and choose the size, then on the Virtual Machine Mode page, select Stand-alone Virtual Machine if you had deleted the cloud service, and enter the same (or a different) DNS Name as before. If you had more than one VM in the cloud service, you can deploy it back into that same cloud service (and get the same DNS name and external IP address as before) by selecting Connect to an existing virtual machine and choose the relevant cloud service). Then complete the rest of the VM create wizard.

    Regards,

    Shirisha Paderu

    Monday, April 20, 2015 8:04 AM
  • Hi Igor,

    Any update on the issue ?

    If the issue is not resolved yet, please brief a little more about the issue to further assist you.

    Regards,

    Shirisha Paderu

     
    Thursday, April 23, 2015 11:04 AM
  • Hi,

    Since we haven't found any responses on the thread I am marking the thread as answer. However, If you have any concerns pleasae feel free to unmark as answer and write back / start a new thread.

    Regards,

    Shirisha Paderu

    Friday, April 24, 2015 3:53 PM
  • Hi,

    I tried all the above mentioned step but still unable to connect through SSH.

    i have Linux box, i create another VM using the same VHD (old) and newly created VM is running fine.

    Computer name is still empty and unable to connect via SSH (old affected VM).

    Kidly help ASAP.

    Thanks in advance.

    Vikash Gaurav

    Tuesday, August 23, 2016 1:46 PM