Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, April 7, 2017 10:28 PM
We only have one VM that we use, and occasionally I need to log into it to do something through remote desktop. The problem is that the server runs perfectly fine and does everything it needs to do being set to the A1 Basic size, but when I log in to do whatever it is I need to do (which isn't very often), it's dreadfully slow, so I have been resizing the VM to A2 Basic, doing what I need to do and then resizing it back to A1 Basic.
To do this, I have been:
- Logging in through remote desktop
- Shutting the VM down (using the start menu)
- Waiting for the portal to say it's shut down
- Resizing the VM to A2 Basic
- Starting the VM through the portal
- Logging in through remote desktop
- Doing whatever I need to do
- Repeat steps 2-5 except setting the size to A1 Basic
I've been doing it this way because we are running SQL Server Express on the VM and it takes backups on a schedule of our database. Since I'm not sure how the resize process works, and I can't seem to find the details, I feel safer doing these steps, but it takes forever to do.
I was wondering if it is safe to skip steps 1-3 and just resizing the machine from the portal without logging in? I don't want to risk losing any data or corrupting any backups.
What is the best thing to do in this situation? If I just resize the machine while the machine is running, does the portal automatically shut it down safely or does it just "pull the plug" so to speak?
All replies (5)
Saturday, April 8, 2017 11:40 AM
If your VM(s) are deployed using the Resource Manager (ARM) deployment model you can resize VMs by first stopping your VM, selecting a new VM size and then restarting the VM. If the VM you wish to resize is part of an availability set, then you must stop all VMs in the availability set before changing the size of any VM in the availability set. The reason all VMs in the availability set must be stopped before performing the resize operation is that all running VMs in the availability set must be using the same physical hardware cluster. Therefore, if a change of physical hardware cluster is required to change the VM size then all VMs must be first stopped and then restarted one-by-one to a different physical hardware clusters. So the steps 1-3 cannot be skipped. However, you can stop the VM directly from the portal instead of having to login via RDP and shut it down from within.
If the VM is a Classic VM then refer to Resize virtual machines for additional details. Here you cannot just resize the VM by stopping it. You will have to delete the VM and then recreate it using the existing disks.
Saturday, April 8, 2017 2:15 PM
I'm confused. The VM is a classic machine and I've been able to resize it like described forever.
This is the machine:
It's not part of a resource group or anything like that. It's literally just a single standalone VM.
Saturday, April 8, 2017 2:27 PM
The recreating of the VM will be applicable if the VM size you want to resize your Classic VM to is not available in your current region. I believe you have been resizing the VM on the same hardware cluster which does not require a recreation operation. I should have been more clearer about this in my previous post.
Saturday, April 8, 2017 11:37 PM
So if I stop the VM just using the portal, will it safely shut down the machine or does it just "pull the plug?"
Tuesday, April 11, 2017 8:50 AM
It does not pull the plug on the VM. It is simply a way to tell Azure that the VM is not in use and the billing needs to stop. IF you shut down the VM via the guest OS, the VM will be stopped but the storage will be charged on an hourly basis depending upon your type of subscription. Stopping (de-allocating) the VM via the portal will shut down the VM safely and also not charge you additional for the associated storage. This is the main difference.