The following forum(s) have migrated to Microsoft Q&A (Preview): Azure Virtual Machines!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

 locked
ScaleSet VM SKU Resize RRS feed

  • Question

  • Why is it with VM ScaleSets that you can't easily change the SKU Size and it won't take effect after reboot? I find you have to totally delete the scaleset and re-provision for that to take effect. My scalesets are servers all built via automation scripts from ARM templates, sh script, etc but still… IF I wanted to quickly change the resources on one CPU and Memory wise it doesn't seem to be as easy as changing the SKU, letting it reboot and it's there or deallocating, changing size and booting back up same thing (Not there). This appears to not affect the VM inside.

     

    Example, I have a ScaleSet running a custom RHEL Image I made in my Shared Image Gallery. Currently sits at Standard_B2s (2 CPU 4GB Ram). Deallocated, Changed SKU to Standrd_B2ms (2CPU 8GB RAM) and booted back up.

     

    Result is still at 4GB RAM running say cat /proc/meminfo to see max memory

     

    MemTotal:        4026512 kB

    MemFree:         2301824 kB

    MemAvailable:    2718188 kB

     

    I see technically you would be able to update the SKU via powershell, but this only updates the scaleset and not the VM in the scaleset (Same as above). Can we not update the VM SKU size then without re-provision?

     

    Trying this does not work as it can't find the SKU, even though it lists it

    $VMSSvm = Get-AzVmssVM -ResourceGroupName "RG" -VMScaleSetName "vmss-name"

    $VMMSvm.SKU = "Standard_B2ms"

    Update-AzVmssVM -ResourceGroupName "RG" -Name "vmss-name"

     

    This works but doesn't affect the VM of course

    #AzVmss - Update SKU of VMSS

    $VMSS = Get-AzVmss -ResourceGroupName "RG" -VMScaleSetName "vmms-name"

    $VMSS.SKU.name = "Standard_B2ms"

    Update-AzVmss -ResourceGroupName "RG" -Name "vmms-name" -VirtualMachineScaleSet $VMSS

    Any clarification on this would be great from giving myself a headache if possible :)

    Tuesday, September 10, 2019 9:57 PM

Answers

  • Hi,

    Lets go through your questions one by one.

    Question: Can we not update the VM SKU size then without re-provision?

    We can update SKU  without re-provisioning.

    In VMSS, we should not change anything on the instances. We need to update only the VMSS and let the VMSS propagate the changes to the VM's.

    In your case, You have updated the VMSS SKU. It didnt change the VM's size immediately because of the upgrade policy.

    I think your VMSS upgrade policy is set to "Manual".  You can use the below command to check that.

    az vmss show -n vmssname -g resource-group-name --query 'upgradePolicy.mode'

    If its set to manual, Then changes to the VMSS wont be automatically propagated to the VM's.

    You can see that in the Instances blade with latest model "no" as shown below.

    Now you need to upgrade each of the instances to apply the new updated to the VMSS.

    You can do that by clis, powershell or rest.

    In cli, you can the below command to upgrade an instance.

    az vmss update-instances --instance-ids 1  -n vmss-name -g resource-group-name

    You can also upgrade form the portal after selecting that particular instance as shown below

    Now lets see how we can avoid this.

    You can change the upgrade policy to automatic or rolling so that any update to the vmss is propagated to the VM's  immediately 

    If we set to automatic, Then the VMSS picks the VM's automaticallu and upgrades to the latest model. Please note that it may pick all the machines at a time and reboot it and apply changes. Here we have a risk of application downtime. 

    If we set to upgradepolicy.mode to rolling, The VM's will be updated one by one so we will not have a downtime. 


    Wednesday, September 11, 2019 8:38 AM

All replies

  • Hi,

    Lets go through your questions one by one.

    Question: Can we not update the VM SKU size then without re-provision?

    We can update SKU  without re-provisioning.

    In VMSS, we should not change anything on the instances. We need to update only the VMSS and let the VMSS propagate the changes to the VM's.

    In your case, You have updated the VMSS SKU. It didnt change the VM's size immediately because of the upgrade policy.

    I think your VMSS upgrade policy is set to "Manual".  You can use the below command to check that.

    az vmss show -n vmssname -g resource-group-name --query 'upgradePolicy.mode'

    If its set to manual, Then changes to the VMSS wont be automatically propagated to the VM's.

    You can see that in the Instances blade with latest model "no" as shown below.

    Now you need to upgrade each of the instances to apply the new updated to the VMSS.

    You can do that by clis, powershell or rest.

    In cli, you can the below command to upgrade an instance.

    az vmss update-instances --instance-ids 1  -n vmss-name -g resource-group-name

    You can also upgrade form the portal after selecting that particular instance as shown below

    Now lets see how we can avoid this.

    You can change the upgrade policy to automatic or rolling so that any update to the vmss is propagated to the VM's  immediately 

    If we set to automatic, Then the VMSS picks the VM's automaticallu and upgrades to the latest model. Please note that it may pick all the machines at a time and reboot it and apply changes. Here we have a risk of application downtime. 

    If we set to upgradepolicy.mode to rolling, The VM's will be updated one by one so we will not have a downtime. 


    Wednesday, September 11, 2019 8:38 AM
  • Hi Jakaruna,

    Thank you for this as this definitely shed the light I needed on updating the SKUs for scalesets. It appears I was a bit confused, but this cleared it up.

    Thanks a ton for this!

    Thursday, September 12, 2019 7:32 PM
  • Go ahead and try it out.
    If you face any issues, Please post a new thread.
    Friday, September 13, 2019 4:33 AM