I cannot find any information on the Azure site clarifying this - possibly it's my understanding of how these work - please can someone confirm I am correct.
If I have a VM (Windows generated from their template which I have then installed some software on) and shut it down (using the portal to deallocate it), I am no longer charged compute costs. I am still charged storage for the VHD file but there will be no storage transactions as the machine is switched off.
As and when I start it, a new instance is deployed, from the VHD I previously configured (this is important to start with the software installed still) and I will then be charged for storage transactions and compute minutes.
Also, for the storage on VHD files, is this goo-redundant or locally-redundant or do I choose when creating the VM?
If you create a storage account first, you have a choice of enabling geo-replication or not. Default value is enabled.
If you create a virtual machine, creation of a new storage account is an option. This account will default have geo-replication enabled.
You are correct on the charging.
Related
I can't get my VM disk restored in Azure: it is only "converted" to the Storage Account linked to my VM.
Does anyone know how to get a VM fully restored from a Recovery Service Vault backup in Azure please?
Edit :
For additional precision, I made a simple Linux VM hosting a test website in order to experience Azure's backup and restore feature.
So once the test website was online, I waited for a backup job to be done.
Then I deliberately broke the test website inside the VM, and launched a disk restore.
Unfortunately, the restore did nothing to the VM. I checked on the jobs and restore was marked as "Successful", and a VM restart did nothing.
Anyway, I can find the "vhd" in the Conainer tab of the Storage Account. But I can't find a way to attach it to the VM...
Is the disk restoration feature even supposed to work like intended ?
I tried to replicate a backed up restore of a virtual machine using Azure Site Recovery.
When you restore the virtual machine you have the option to select if you want to restore the disks or the virtual machine.
Selecting here to restore as a VM, will create the VM for you.
You can check that status of the restore by going to the jobs section of the machine in ASR.
For reference, see this page for more detailed instructions.
This likely flies in the face of what Azure thinks it can do, but have you tried to create the VM first and then just restore your data? Other possible options are:
The user you are logged in as does have the correct permissions to create a VM in that space as well as restore the data, yes?
And you did select Recovery Service vaults in the portal, correct?
check if the original VM had any special conditions, such as multiple NICs or a load balancer. Any custom VM configurations, including HUB licensing, will not be duplicated with the Create Virtual Machine option as it uses Quick Create. You will need to use PowerShell to attach the restore disks to your chosen VM configuration. You can get additional information on PowerShell and Azure backups here.
And in the link that kim provided above, scroll down to the "Create a new VM from a restore point" section and review the options and notes for creating a new VM. You can get more information on ASR at this page.
I've set up Azure Site Recovery to replicate a VM using Azure-to-Azure replication. Everything is working great, but I've now added a new disk to my VM and I do not see the .vhd page blob in the replicated storage account.
How can I get the newly added disk to replicate? Do I need to remove replication and then redo it?
Currently, this feature is not available. Probably you need to redo it.
You may vote up an idea submitted by another Azure customer:
https://feedback.azure.com/forums/256299-site-recovery/suggestions/6438471-automatically-replicate-the-new-disk
All of the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
I'm a lone dev that inherited a giant undocumented mess of an azure vm without any sysadmin-like training nor a lab to test things out. This vm runs our website just fine, but I couldn't log in to VestaCp because disk space usage is at 100%.
I did setup azure to make daily backups. Now I'm wondering if azure somehow stores them on the same machine e.g. they're the cause of the full disk space.
if so, how do I remove a set of old backups?
Now I'm wondering if azure somehow stores them on the same machine e.g. they're the cause of the full disk space.
As mentioned in the official document about creating a recovery services vault for a VM:
The location of Recovery Services vault determines the geographic region where your backup data is sent.
If you have virtual machines in multiple regions, create a Recovery Services vault in each region.
There is no need to specify the storage accounts used to store the backup data--the Recovery Services vault and the Azure Backup service automatically handle the storage.
Per my understanding, your VM backup data could be stored on the storage accounts that are managed automatically by the Recovery Services vault (ARM) and the Azure Backup service (ASM).
Moreover, if this issue could not be solved by removing a set of old backups, I assumed that you could follow this tutorial to resize Azure VM OS or Data Disk created using Azure Service Manager (ASM) or this tutorial for resizing ARM VM OS & Data disk.
I'm using Azure VM (Ubuntu 16.04) as web server. For some reason at my resource group for VM there are two storages.
First - GRS Standart and second LRS Premium.
How to determine which storage is necessary for my web server and which I can safely delete?
You can check the storage account holding the disks (OS and Data disks) by clicking on Disks option and then clicking on individual disks. You will see the URL of the page blob holding the disk and that should tell you about the storage account.
However before deleting the other storage account, please check if it is not used for collecting diagnostics data for the VM.
Making an assumption, I believe your LRS Premium account is holding the disks and the other one is for storing diagnostics data.
I would like to migrate our test server - a Windows Azure VM running Windows 2008 server (running AD DC and variety of apps such as Dynamics CRM) - to a virtual network.
I am looking for a safe way to migrate the server to the virtual network.
My research to date indicates that I can create a new VM using the same OS disk. However when I attempt to create a new VM the existing OS disk is not visible in the list of images.
Is anybody able to point me in the right direction as to how this is achieved? Also, do you have any recommendations with respect to a rollback strategy (e.g. Backup tools)?
Alan.
I haven't verified the flow, but it should be working fine. Follow these steps:
Make sure you are not using static IP on your AD/DC. The IP Addresses in Azure shall always be DHCP allocated!
Shut down the AD/DC
Copy the VHD blob to a new blob! I strongly suggest that you have the OS Disk (VHD blob) in a storage account which is in the same affinity group as the Virtual Network. So, if the current OS Disk is not in a Storage Account, which is in the same affinity group as the VNet, create a new storage account and copy the original VHD there. Please note that you should copy the blob only when the VM is shut down!
Create the sub-net you want to bring the VM in. (probably you already have created it).
Create a new VM using the copied VHD as an OS Disk and selecting the Virtual Network and sub-net.
Possible gotchas with this migration:
IP Address of AD/DC will change when added to the Virtual Network. Be prepared and never assign static IP Address to a VM in Azure
You will not see the VHD in the list of possible images to use - in that case use some kind of storage explorer (such as Cloud Storage Studio) to make sure there is no existing lease on the blob with the VHD. If there is a lease - break it!
A suggested VNet setup for AD/DC/DNS infrastructure in azure is clearly described in this blog post