Information and announcements from Program Managers, Product Managers, Developers and Testers in the Microsoft Virtualization team.
Quick post to clarify some frequently asked questions on the newly announced Azure Site Recovery service which enables you to protect your Hyper-V VMs to Microsoft Azure. The FAQ will not address every feature capability - it should help you get started.
Q1: Did you just change the name from Hyper-V Recovery Manager to Azure Site Recovery?
A: Nope – we did more than that. Yes, we rebranded Hyper-V Recovery Manager to Azure Site Recovery (ASR) but we also brought in a bunch of new features. This includes the much awaited capability to replicate virtual machines (VMs) to Microsoft Azure. With this feature, ASR now orchestrates replication and recovery between private cloud to private cloud as well as private cloud to Azure.
Q2: What did you GA in Jan 2014?…
A: In Jan 2014, we announced the general availability of Hyper-V Recovery Manager (HRM) which enabled you to manage, orchestrate protection & recovery workflows of *your* private clouds. You (as a customer) owned both the primary and secondary datacenter which was managed by SCVMM. Built on top of Windows Server 2012/R2 Hyper-V Replica, we offered a cloud integrated Disaster Recovery Solution.
Q3: HRM was an Azure service but data was replicated between my datacenters? And this continues to work?
A: Yes on both counts. The service was being used to provide the “at-scale” protection & recovery of VMs.
Q4: What is in preview as of June 2014 (now)?
A: The rebranded service now has an added capability to protect VMs to Azure (=> Azure is your secondary datacenter). If your primary machine/server/VM is down due to a planned/unplanned event, you can recover the replicated VM in Azure. You can also bring back (or failback) your VM to your private cloud once it’s recovered from a disaster.
Q5: Wow, so I don’t need a secondary datacenter?
A: Exactly. You don’t need to invest and maintain a secondary DC. You can reap the benefits of Azure’s SLAs by protecting your VMs on Azure. The replica VM does *NOT* run in Azure till you initiate a failover.
Q6: Where is my data stored?
A: Your data is stored in *your* storage account on top of world class geo-redundant storage provided by Azure.
Q7: Do you encrypt my replica data?
A: Yes. You can also optionally encrypt the data. You own & manage the encryption key. Microsoft never requires them till you opt to failover the VM in Azure.
Q8: And my VM needs to be part of a SCVMM cloud?
A: Yes. For the current preview release, we need your VMs to be part of a SCVMM managed cloud. Check out the benefits of SCVMM @ http://technet.microsoft.com/en-us/library/dn246490.aspx
Q9: Can I protect any guest OS?
A: Your protection and recovery strategy is tied to Microsoft Azure’s supported operating systems. You can find more details in http://msdn.microsoft.com/en-us/library/azure/dn469078.aspx under the “Virtual Machines support – on premises to Azure” section.
Q10: Ok, but what about the host OS on-premises?
A: For the current preview release, the host OS should be Windows Server 2012 R2.
In summary, you can replicate any supported Windows and Linux SKU mentioned in Q9 running on top of a Windows Server 2012 R2 Hyper-V server.
Q11: Can I replicate Gen-2 VMs on Windows Server 2012 R2?
A: For the preview release, you can protect only Generation 1 VMs. Trying to protect a Gen-2 VM will fail with an appropriate error message.
Q12: Is the product guest-agnostic or should I upload any agent?
A: The on-premises technology is built on top of Windows Server 2012 Hyper-V Replica which is guest, workload and storage agnostic.
Q13: What about disks and disk geometries?
A: We support all combinations of VHD/x with fixed, dynamic, differencing.
Q14: Any restrictions on the size of the disks?
A: There are certain restrictions on the size of the disks of IaaS VMs on Azure – primary being:
Azure is a rapidly evolving platform and these restrictions are applicable as of June 2014.
Q15: Any gotchas with network configuration or memory assigned to the VM?
A: Just like the previous question, when you failover your VM, you will be bound by Azure’s offerings/features of IaaS VMs. As of today, Azure supports one network adapter and upto 112GB (in the A9 VM). The product does not put a hard-block in case you have a different network and/or memory configuration on-premises. You can change the parameters with which a VM can be created in the Azure portal under the Recovery Services option.
Q16: Where can I find information about the product, pricing etc?
A: To know more about the Azure Site Recovery, pricing, documentation; visit http://azure.microsoft.com/en-us/services/site-recovery/
Q17: Is there any document explaining the workflows?
A: You can refer to the getting-started-guide @ http://azure.microsoft.com/en-us/documentation/articles/hyper-v-recovery-manager-azure/ or post a question in our forums (see below)
Q18: I faced some errors when using the product, is there any MSDN forum where I can post my query.
A: Yes, please post your questions, queries @ http://social.msdn.microsoft.com/Forums/windowsazure/en-US/home?forum=hypervrecovmgr
Q19: But I really feel strongly about some of the features and I would like to share my feedback with the PG. Can I comment on the blog?
A: We love to hear your feedback and feel free to leave your comments in any of our blog articles. But a more structured approach would be to post your suggestions @ http://feedback.azure.com/forums/256299-site-recovery
Q20: Will you build everything which I suggest?
A: Of course…not :) But on a serious note – we absolutely love to hear from you. So don’t be shy with your feedback.
Each data disk cannot be more than 1TB
Could you elaborate on the reasons of this limitation. I feel that 1TB is good maximum size for a volume in general but I was wondering if you had good rationales to share with us.
This is a limitation in Azure as of today (search for "Max. data disks" in
http://msdn.microsoft.com/en-us/library/azure/dn197896.aspx). The reasons for the limitation are unfortunately not documented but our scalability limits keep improving over a period of time.
It's worth reiterating that the limit is 1TB per disk and you can have upto 16 such disks (16TB) attached to a VM.