Sunday, May 17, 2015

Resize Azure VM OS or Data Disk

Resizing an Azure VM disk using Update-AzureDisk -ResizedSizeinGB

Resizing an Azure VM disk was only possible until recently by using third party software such as Cloud Xplorer using a multistep approach. Not ideal. Best practice says provision Azure disk at maximum capacity but for one of my customers I faced the challenge where I migrated VMs using Azure Site Recovery. ASR is a great tool but it provisioned the target VMs with disks that match the size of the source, and it doesn't provide the option to change this. Now what if I run out of space? Or what if I don't want a 30 GB OS volume, but the 127 GB default size.

To overcome this problem I searched and found the following article. Azure Linux VM - Resize root volume. Great article, but it's only covers OS disks and Linux. The article includes a new command which hasn't been documented on MSDN yet. Which is Update-AzureDisk -ResizedSizeinGB

In my case I'm dealing with Azure VMs that run the Windows OS, and in many cases it's not only the OS disk that needs to be resized, but also the data disk.

I tested both scenario's and can confirm the Update-AzureDisk -ResizedSizeinGB works on both OS and data disks. In this article I'll explain how to use the command to resize Azure VM disks.

Note: The disk cannot be in use, shutdown the VM prior to making this change. And it cannot be reversed. You can only increase the size, the command will not allow you to shrink. 

The command

The command is pretty straight forward and all you need is to be a co-administrator and running the latest AzurePowerShell cmdlet. The command itself is as follow. 

Update-AzureDisk -DiskName 'MyDiskName' -Label 'MyLabel' -ResizedSizeInGB 300

Changing the disk size Step-by-Step


The Azure VM OS disk resize

1. First of all we'll connect to the subject VM and check out it's OS disk size. In this case it's a standard Azure VM with a 127GB disk. It can of course also be a much smaller disk which is in desperate need of resizing.

Azure VM OS Disk - 127 GB


2. De-allocate the Azure VM. The disks cannot be in use at the time of the resize.

3. Connect to your subscription using the latest Azure PowerShell cmdlet. 

4. To resize the disk you'll require the Diskname. To retrieve this information, in my case of VM ate-azr400, run the following command. If you want to make your life easy, store this information in a variable.
Get-AzureVM -ServiceName ate-azr4 -Name Ate-azr400 | Get-AzureOSDisk


Retrieve Azure VM DiskName


5. Run the following command to resize the disk. This will take a few second so be patient while the resize takes place.
Update-AzureDisk -DiskName ate-azr400-ate-azr400-0-201502180257360595 -Label Resized -ResizedSizeInGB 300


Update-AzureDisk -ResizedSizeinGB


6. Now have a look in the portal and browse to the container where the OS disk is stored. You'll find that the VHD has increased from the former 127 GB to 300 GB.

New size in Portal


7. Power On the Azure VM, and open the disk management to view the changes that have been applied. If you require the space extend your volume.

Resized VM OS Disk - 300 GB


The Azure VM Data Disk Resize

To resize the Azure VM Data Disk you pretty much follow the same process. The only difference is the command used to retrieve the Azure Disk Name.

1. To resize Azure Data Disk you'll require the Diskname. Note that this time I run Get-AzureDataDisk. In this case I want to extend the 10 GB disks.
Get-AzureVM -ServiceName ate-azr4 -Name Ate-azr400 | Get-AzureDataDisk


Get-AzureDataDisk


2. Next I run the same Update-AzureDisk -ResizedsizeinGB cmdlet to resize the Azure VM Data disk. This time I run it with the other DiskName.  
Update-AzureDisk -DiskName ate-azr400-ate-azr400-1-201505171031360397 -Label ResizeDataDisk -ResizedSizeInGB 150

Resize Azure VM Data Disk


3. If I now retrieve the information again I'll find that the disk size has been updated to 150 GB. 

Resized to 150 GB.

4. Power On the VM again and review the changes. You should find that the disk has now changed to 150 GB.

Disk size increased to 150 GB



I hope you enjoyed this walk through of how to resize a Azure VM disk. As mentioned earlier in the post, this change cannot be reversed. 




Monday, March 23, 2015

Reset Azure VM admin password

Help I lost my Azure VM admin password!

It's a pretty common mistake people make. They create an Azure VM and forget to write down the Azure VM admin password. You obviously knew it at the time of creation but a few weeks later it might be hard to recall what you configured as your admin password... End result is most of the time recreating another Azure VM. Ok if it was just a little demo machine but pretty annoying if it's a production system.

Luckily Azure VM admin password can be reset through PowerShell. And in this post I'll just quickly demonstrate how to complete this pretty simple task. All you need is a couple of things, nothing overly complicated.

Required:
  • The latest Microsoft Azure PowerShell cmdlet. Documentation on how to install that can be found on the following page Azure PowerShell.
  • Azure service or co-administrator account
  • A powered on VM with the VM Agent installed!
  • And your new username and password!
Note: The Azure VM will be restarted during the process of resetting the Azure VM admin credentials.

The problem:

So the problem we are facing in this case is the inability to connect to an Azure VM. I myself have provisioned a Windows 10 image from the MSDN gallery and am unable to currently connect to the Azure VM as I managed to forget the password.. This is what that look like..

Unable to logon to Azure VM

How to resolve?

So great, we have a problem. We cannot log on to the Azure VM. How do we somehow regain access or reset the password. It's all achieved by the following two commands. They are pretty basic but very powerful. They are both ran through the Microsoft Azure PowerShell cmdlet. Scroll down and I'll take you through the process.

Step 1. Set the new credentials

$adminCredentials = Get-Credential -Message "Enter new Azure VM credentials"

Step 2. Reset the Azure VM administrator password

(Get-AzureVM) |
Where-Object -Property Status -EQ "ReadyRole" |
Select-Object -Property Name, ServiceName |
Out-GridView -Title "Select a VM …" -PassThru |
ForEach-Object {
    $VM = Get-AzureVM -Name $_.Name -ServiceName $_.ServiceName
    If ($VM.VM.ProvisionGuestAgent) {
        Set-AzureVMAccessExtension -VM $VM `
            -UserName $adminCredentials.UserName `
            -Password $adminCredentials.GetNetworkCredential().Password `
            -ReferenceName "VMAccessAgent" |
        Update-AzureVM
        Restart-AzureVM -ServiceName $VM.ServiceName -Name $VM.Name
    } else {
        Write-Output "$($VM.Name): VM Agent Not Installed"
    }
}



Walk through

1. So before we go ahead, you need to launch your Microsoft Azure PowerShell cmdlet and connect to the subscription which has the Azure VM.


Connect to subscription


2. Followed by this is configuring the new Azure VM admin credentials by running the command below. This will prompt you to enter the new credentials.
$adminCredentials = Get-Credential -Message "Enter new Azure VM credentials"

Set credentials


3. Run $adminCredentials if you want to confirm that it's configured. And yes the password is safely stored and won't be displayed.

Check variable

4. Now it's time to reset the Azure VM password. Run the script that has included at the top of the post. You will be prompted with a grid view to select the VMs. The script only retrieves Azure VMs that are powered on as a password reset cannot be completed on a Azure VM that is shut down.

PowerShell script to reset Azure VM password


5. You have to be a little patient as it does take a while. The Azure VM is at the end of the process updated and restarted.

Reset Azure VM admin password


6. Have a look in the Azure portal and you'll find that the extension on the Azure VM are being installed. This is obviously to reset the password, so wait till this process has completed.

Installing Extensions



7. Once the Azure VM has returned to the status Running, try and reconnect using the newly configured Azure VM admin username and password.

Successfully reset the Azure VM credentials






Sunday, March 8, 2015

Improve your Azure Virtual Network

How can I improve the speed on my Azure virtual networks? 


In this article I'll be taking you through configuring the encryption type on your Azure Virtual Network to improve your throughput. And I'll conclude with a comparison to see the benefit of removing the encryption.

The ability to do so was announced by Microsoft in December in the following article. http://azure.microsoft.com/blog/2014/12/02/azure-virtual-network-gateway-improvements/

Some of the key changes noted are the ability to change to a high performance gateway, and  changing the encryption type on the gateway of an Azure VPN. As noted below.

More Custom Options for IPsec/IKE VPNs

We added two more custom options for configuring your IPsec/IKE S2S VPN tunnels – PFS (Perfect Forward Secrecy) and No Encryption.
With this feature, now you can specify PFS with IKE on a per tunnel basis. No Encryption is a new option for the S2S VPN tunnel. This is targeted at the VNet-to-VNet communication within Azure. The traffic between Azure Virtual Network gateways will stay within the Microsoft operated networks, including cross-region communication. This traffic today is encrypted by default. For customers that would like better throughput, we offer the No Encryption option that removes the encryption and decryption overhead. Please note that for traffic that is going through the Internet, this option is not recommended as it will cause the packets to be sent without encryption. It is only recommended for Azure VNet-to-VNet communication.
We are working on the PowerShell cmdlet support to enable these two features. Please stay tuned.

No article followed with the actual cmdlets, and for those like myself who are keen to test NoEncryption encryption type would have found that there is no information available. So I've followed up with Microsoft and have been able to get the command. Given that there is no additional information availably I thought why not compare the speeds so we actually know what "better throughput" is like?

So before we go ahead and configure the NoEncryption setting, be aware of the following. Do not configure a Site-to-Site VPN which traverses the public internet with the NoEncryption option. This makes perfect sense and is mentioned in the article of Microsoft, but it is well worth repeating. You do not want your VPN traffic to traverse the public internet without any encryption.

So what can we use it for? Well for your Azure VNet-to-VNet connectivity, this traffic does not traverse the public internet. Removing the encryption from the tunnel will enhance the throughput of VPN by removing the encryption and decryption overhead. Which can be quite critical when you run multiple VNet-to-VNet connections across multiple subscriptions, and regions like I do.

The command?

So that PowerShell cmdlet that we are looking for to configure NoEncryption, what is it? The command is:

Set-AzureVNetGatewayIPsecParameters

If you look for this command on MSDN you won't find a lot of information, but using the latest Microsoft Azure PowerShell cmdlet you'll be able to run a get-help. Which will provide you the following information. What we are looking at for this article is the parameter -EncryptionType with the following string values RequireEncryption and NoEncryption.

PS C:\> Get-Help Set-AzureVNetGatewayIPsecParameters -Full
NAME
    Set-AzureVNetGatewayIPsecParameters
 SYNTAX
    Set-AzureVNetGatewayIPsecParameters [-VNetName] <string> [-LocalNetworkSiteName] <string> [[-EncryptionType]
    <string>] [[-PfsGroup] <string>] [[-SADataSizeKilobytes] <int>] [[-SALifetimeSeconds] <int>]  [<CommonParameters>]
 PARAMETERS
    -EncryptionType <string>
        The type of encryption that will be used for the connection between the virtual network gateway and the local network.
 Valid values are RequireEncryption and NoEncryption.
        Required?                    false
        Position?                    2
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false 
    -LocalNetworkSiteName <string>

        The local network site name.   
        Required?                    true
        Position?                    1
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -PfsGroup <string>
        The PFS gruop that will be used for the connection between the virtual network gateway and the local network.
        Valid values are RequireEncryption and NoEncryption.
        Required?                    false
        Position?                    3
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -SADataSizeKilobytes <int>
        The SA Data Size Kilobytes value is used to determine how many kilobytes of traffic can be sent before the SA for theconnection will be renegotiated.
        Required?                    false
        Position?                    4
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -SALifetimeSeconds <int>
        The SA Lifetime Seconds value is used to determine how long (in seconds) this connection's SA will be valid before a new SA will be negotiated.
        Required?                    false
        Position?                    5
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    -VNetName <string>
        The virtual network name.
        Required?                    true
        Position?                    0
        Accept pipeline input?       false
        Parameter set name           (All)
        Aliases                      None
        Dynamic?                     false
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (http://go.microsoft.com/fwlink/?LinkID=113216).
INPUTS
    None
OUTPUTS
    Microsoft.WindowsAzure.Management.Network.Models.GatewayGetOperationStatusResponse
ALIASES
    None

REMARKS
    None



So there you go, that's the cmdlet and with all the syntax that can be used to configure the EncryptionType on the Site-to-Site or VNet-to-VNet VPN. You will probably noticed that there are a bunch of typo's in the get-help file. Let's assume they get fixed by Microsoft anytime soon.

Changing the type, and what is the throughput difference like?

So how about we start looking at changing the type, and compare the speed with, and without encryption.

To start of the test I'll first explain my setup. I myself have a number of subscriptions and have connected a virtual network in Australia East (Sydney) to Europe West (Amsterdam). So I basically have a VNet-to-VNet connection from Sydney to Amsterdam. I have virtual machines on both sides which i'll use for my test. My setup is pretty much as indicated below.


Scenario - VNet-to-VNet Sydney to Amsterdam












The configuration that applies is as follows.

Virtual NetworkLocalNetworkSiteNameSubscription
Ate-VNET1 Ate-VNET4 Projects Lab
Ate-VNET4 Ate-VNET1-FUJ Ate Lab


To retrieve the current configuration run the following commands.

Get-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET4 -LocalNetworkSiteName Ate-VNET1-FUJ | fl
Get-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET1 -LocalNetworkSiteName Ate-VNET4 | fl

In my case it returns me with the following results. As you can see the encryption type for both connections are set to RequireEncryption.

Get-AzureVNetGatewayIPsecParameters

To change this run the following command. Run them on both virtual networks, in my case Ate-VNET1 and Ate-VNET2, as you want to change the Encryption type both ways, not one way.

Set-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET1 -EncryptionType NoEncryption -LocalNetworkSiteName Ate-VNET4 
Set-AzureVNetGatewayIPsecParameters -Vnetname Ate-VNET4 -EncryptionType NoEncryption -LocalNetworkSiteName Ate-VNET1-FUJ

Set-AzureVnetGatewayIPsecParameters

The command takes a few minutes per connection, and will briefly interrupt your connectivity as indicated below. Run the command against both virtual networks.

Briefly interrupted

After changing the type quickly run the Get-AzureVnetGatewayIPsecParameters command to confirm that the changes have applied.

EncryptionType has changed to NoEncryption

Once you've completed this on both virtual networks you will have updated both tunnel to use the EncryptionType NoEncryption.

How much 'better' is the throughput?

As indicated at the start of the article, the goal of changing the connection type to NoEncryption is to remove the overhead caused by encryption and decryption of data going through the Azure IPSec VPN tunnel. So how much "better" is the throughput as mentioned in the Microsoft article.

To find out what the difference is I ran a robocopy of a file of 1GB from Ate-AZR401 to Ate-AZR101. Below the results of my test.


Encryption TypeTime Taken (m)Speed (MB/s)
Encryption12:001.4
NoEncryption8:441.9

That's an increase of throughput of 36%! These are obviously point in time measurements and can vary throughout the day. I am planning to over the next few days run a couple of more tests but was excited to share these results.

My conclusion is, removing the encryption truly improves the throughput on your connection. So if you run a lab, and use Vnet-to-Vnet connections, change the encryptiontype to NoEncryption! Your throughput could improve to 36%!

Hope you enjoyed this post, please feel free to provide feedback or ask any questions.