I was looking at https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade and seeing if we could change our VMSS (currently using a Manual upgrade policy mode) to an automatic rolling update one but found that the application health probe couldn't use our existing App Gateway health probe as it needed to be specifically a LoadBalancer one. Bummer.
Anyhow, I thought I'd test our VMSS to ensure we can manually Upgrade each instance from the Portal/CLI but deliberately picking an old 16.04 LTS image id (instead of the 'latest' version tag). From "az vm image list --location canadacentral --publisher Canonical --offer UbuntuServer --SKU 16.04-LTS --all --output table" I picked the first 16.04 image published in 2018 ie 16.04.201801050. The latest one is "16.04.201811140"
Microsoft.Compute/virtualMachineScaleSets/cluster?api-version=2018-06-01:
"properties": {
"singlePlacementGroup": false,
"upgradePolicy": {
"mode": "Manual",
"automaticOSUpgrade": false
},
...
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "16.04.201801050"
},
I can confirm that each new VMSS instance indeed has the desired "16.04.201801050" image by SSH onto the box (with plenty of updates to apply):
```
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.11.0-1016-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
202 packages can be updated.
118 updates are security updates.
jiraadmin@jiranode-000001:~$ apt list linux-image-azure
Listing... Done
linux-image-azure/xenial-updates,xenial-security 4.15.0.1032.37 amd64 [upgradable from: 4.11.0.1016.16]
N: There is 1 additional version. Please use the '-a' switch to see it
```
but I was surprised to see that the Portal and REST API have each of the instances with the latest model applied set to true (which clearly it is not)
Microsoft.Compute/virtualMachineScaleSets/cluster/virtualMachines/0?api-version=2018-06-01:
"properties": {
"latestModelApplied": true,
"vmId": "...",
"hardwareProfile": {},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "16.04.201801050"
}
Clicking on the Upgrade button for the VM instance in the Azure Portal kicks off a very short-lived task with no changes made to the underlying VM.
So I assumed the following:
- Specifying an older image version before the 'latest' one should have VMSS instance's latestModelApplied set to false
- Clicking on Upgrade button from Poisal should bring the "old" image version upto the 'latest' image version ie essentially performing a 'sudo apt-get upgrade' or 'sudo apt dist-upgrade'. With latestModelApplied to false, it doesn't do either.
- Clicking an on Reimage from the Portal, you get a warning about instance back to it's original state but from https://docs.microsoft.com/en-us/rest/api/compute/virtualmachinescalesets/reimage it suggests it's going to upgrade OS image ie
sudo apt dist-upgrade. It does the former, it reinstalls the original image blowing away everything.
So at the min it appears to me you can't use the Portal to maintain OS and security updates on the currently running VM due to erroneous latestModelApplied property. Is the behaviour and my assumptions above correct?
Thanks, Stephen.
