Tag Archives: Hyper-V Replica

What’s New in Windows Server 2016 Hyper-V Webinar – Q & A Follow Up

We have compiled the recording, and a list of questions and answers from the What’s new in Windows Server 2016 Hyper-V webinar that we received from our viewers following the event. The webinar was presented by Microsoft Cloud and Datacenter MVP’s Aidan Finn and Andy Syrewicze.

Read the post here: What’s New in Windows Server 2016 Hyper-V Webinar – Q & A Follow Up

42 Best Practices for Balanced Hyper-V Systems

Last year, Nirmal Sharma wrote a fantastic article on this blog titled 23 Best Practices to improve Hyper-V and VM Performance. This sparked up a very lively discussion in the comments section; some were very strongly in favor of some items, some very strongly opposed to others. What I think was perhaps missed in some of these comments was that, as Nirmal stated in the title, his list was specifically “to improve Hyper-V and VM performance.” If squeezing every last drop of horsepower out of your Hyper-V host is your goal, then it’s pretty hard to find any serious flaws with his list. Just cause a Group can be brought to consensus, does not make them right. Assess the Risks of being wrong before proceeding on their say so. — guy w wallace (@guywwallace) February 27, 2015 As you probably know, or can at least guess, I’m not the biggest fan… Read More»

Original post link: 42 Best Practices for Balanced Hyper-V Systems

The post 42 Best Practices for Balanced Hyper-V Systems appeared first on Hyper-V Hub – Altaro’s Microsoft Hyper-V blog.

Replicate Azure Pack IaaS Workloads to Azure using ASR

A few months back, we announced Azure Site Recovery (ASR)’s integration with Azure Pack, which enabled our Service Providers to start offering Managed Disaster Recovery for IaaS Workloads using ASR and Azure Pack. The response, since we announced the integration, has been phenomenal – customers are appreciating the simplicity of ASR and are adopting ASR as the standard for offering DR solution in their environments. The integration of ASR and Azure Pack also enabled Service Providers to offer DR as a value added service, opening up new review streams and the ability to offer better Service Level Agreements (SLA) to their end customers. A key ask that our early adopters have expressed – and that we are delivering on today – is the ability to use Microsoft Azure as a Disaster Recovery Site for IaaS workloads when using Azure Pack.

The new features in the ASR – Azure Pack integration will enable Service Providers to offer Azure as a DR site or to an on-premise secondary site using their Azure Pack UR 4.0 deployments. To enable these capabilities you can download the latest ASR runbooks and import them into your WAP environments. To know more about the integration, check out our WAP deployment guide.

Getting started with Azure Site Recovery is easy – simply check out the pricing information, and sign up for a free Microsoft Azure trial.  

Microsoft Server Licensing in a Virtual Environment Revisited

Late last year, we published an eBook about licensing Microsoft server operating systems in a virtual environment. This was followed up with a webinar by Thomas Maurer and Andrew Syrewicze. Toward the end of that session, they took some questions. Since then, we’ve received a few more. We’ll use this article to answer those questions and to further expand on some of the ideas in the eBook. How does OS licensing work with Hyper-V Replica? The way that licensing works with Hyper-V Replica was covered in the eBook and talked about in the webinar, but is still a very common question topic. Unfortunately, the answer is much less popular. Replicas are actual virtual machines, and they are not the same virtual machines as the ones they are replicating. Therefore, they must be licensed independently of the source virtual machine. The license that you bought for the source virtual machine does not… Read More»

Original post link: Microsoft Server Licensing in a Virtual Environment Revisited

The post Microsoft Server Licensing in a Virtual Environment Revisited appeared first on Hyper-V Hub – Altaro’s Microsoft Hyper-V blog.

Announcing GA of Disaster Recovery to Azure – Purpose-Built for Branch Offices and SMB

Today, we are excited to announce the GA for Branch Office and SMB Disaster Recovery to Azure.  Azure Site Recovery delivers a simpler, reliable & cost effective Disaster Recovery solution to Branch Office and SMB customers.  ASR with new Hyper-V Virtual Machine Protection from Windows Server 2012 R2 to Microsoft Azure can now be used at customer owned sites where SCVMM is not deployed.


You can visit the Getting Started with Azure Site Recovery for additional information.

Announcing the GA of Disaster Recovery to Azure using Azure Site Recovery

I am excited to announce the GA of the Disaster Recovery to Azure using Azure Site Recovery. In addition to enabling replication to and recovery in Microsoft Azure, ASR enables automated protection of VMs, remote health monitoring, no-impact recovery plan testing, and single click orchestrated recovery – all backed by an enterprise-grade SLA.

The DR to Azure functionality in ASR builds on top of System Center Virtual Machine Manager, Windows Server Hyper-V Replica, and Microsoft Azure to ensure that our customers can leverage existing IT investments while still helping them optimize precious CAPEX and OPEX spent in building and managing secondary datacenter sites.

The GA release also brings significant additions to the already expansive list of ASR’s DR to Azure features:

  • NEW ASR Recovery Plans and Azure Automation integrate to offer robust and simplified one-click orchestration of your DR plans
  • NEW Track Initial Replication Progress as virtual machine data gets replicated to a customer-owned and managed geo-redundant Azure Storage account. This new feature is also available when configuring DR between on-premises private clouds across enterprise sites
  • NEW Simplified Setup and Registration streamlines the DR setup by removing the complexity of generating certificates and integrity keys needed to register your on-premises System Center Virtual Machine Manager server with your Site Recovery vault

Out-of-band Initial Replication (OOB IR) and Deduplication

A recent conversation with a customer brought out the question:   What is the best way to create an entire Replica site from scratch? At the surface this seems simple enough – configure initial replication to send the data over the network for the VMs one after another in sequence. For this specific customer however, there were some additional constraints placed:

  1. The network bandwidth was less than 10Mbps and it primarily catered to their daily business needs (email etc…). Adding more network was not possible within their budget. This came as quite a surprise because despite the incredible download speeds that are encountered these days, there are still places in the world where it isn’t as cost effective to purchase those speeds.
  2. The VMs were of size between 150GB and 300GB each. This made it rather impractical to send the data over the wire. In the best case, it would have taken 34 hours for a single VM of size 150GB.

This left OOB IR as the only realistic way to transfer data. But at 300GB per VM, it is easy to exhaust a removable drive of 1TB. That left us thinking about deduplication – after all, deduplication is supported on the Replica site. So why not use it for deduplicating OOB IR data?

So I tested this out in my lab environment with a removable USB drive, and a bunch of VMs created out of the same Windows Server 2012 VHDX file. The expectation was that at least 20% to 40% of the data would be same in the VMs, and the overall deduplication rate would be quite high and we could fit a good number of VMs into the removable USB drive.

I started this experiment by attaching the removable drive to my server and attempted to enable deduplication on the associated volume in Server Manager.

Interesting discovery #1:  Deduplication is not allowed on volumes on removable disks

Whoops! This seems like a fundamental block to our scenario – how do you build deduplicated OOB IR, if the deduplication is not supported on removable media? This limitation is officially documented here: http://technet.microsoft.com/en-us/library/hh831700.aspx, and says “Volumes that are candidates for deduplication must conform to the following requirements:  Must be exposed to the operating system as non-removable drives. Remotely-mapped drives are not supported.”

Fortunately my colleague Paul Despe in the Windows Server Data Deduplication team came to the rescue. There is a (slightly) convoluted way to get the data on the removable drive and deduplicated. Here goes:

  • Create a dynamically expanding VHDX file. The size doesn’t matter too much as you can always start off with the default and expand if required.


  • Using Disk Management, bring the disk online, initialize it, create a single volume, and format it with NTFS. You should be able to see the new volume in your Explorer window. I used Y: as the drive letter.


  • Mount this VHDX on the server you are using to do the OOB IR process.
  • If you go to Server Manager and view this volume (Y:), you will see that it is backed by a fixed disk.


  • In the volume view, enable deduplication on this volume by right-clicking and selecting ‘Configure Data Deduplication’. Set the ‘Deduplicate files older than (in days)’ field to zero.



You can also enable deduplication in PowerShell with the following commandlets:

PS C:> Enable-DedupVolume Y: -UsageType HyperV

PS C:> Set-DedupVolume Y: -MinimumFileAgeDays 0

Now you are set to start the OOB IR process and take advantage of the deduplicated volume. This is what I saw after 1 VM was enabled for replication with OOB IR:



That’s about 32.6GB of storage used. Wait… shouldn’t there be a reduction in size because of deduplication?

Interesting discovery #2:  Deduplication doesn’t work on-the-fly

Ah… so if you were expecting that the VHD data would arrive into the volume in deduplicated form, this is going to be a bit of a surprise. At the first go, the VHD data will be present in the volume in its original size. Deduplication happens as post-facto as a job that crunches the data and reduces the size of the VHD after it has been fully copied as a part of the OOB IR process. This is because deduplication needs an exclusive handle on the file in order to go about doing its work.

The good part is that you can trigger the job on-demand and start the deduplication as soon as the first VHD is copied. You can do that by using the PowerShell commandlet provided:

PS C:> Start-DedupJob Y: -Type Optimization

There are other parameters provided by the commandlet that allow you to control the deduplication job. You can explore the various options in the TechNet documentation: http://technet.microsoft.com/en-us/library/hh848442.aspx.

This is what I got after the deduplication job completed:


That’s a 54% saving with just one VM – a very good start!

Deduplication rate with more virtual machines

After this I threw in a few more virtual machines with completely different applications installed and here is the observed savings after each step:


I think the excellent results speak for themselves! Smile Notice how between VM2 and VM3, almost all of the data (~9GB) has been absorbed by deduplication with an increase of only 300MB! As the deduplication team as published on TechNet, VDI VMs would have a high degree of similarity in their disks and would result in a much higher deduplication rate. A random mix of VMs yields surprisingly good results as well.

Final steps

Once you are done with the OOB IR and deduplication of your VMs, you need to do the following steps:

  1. Ensure that no deduplication job is running on the volume
  2. Eject the fixed disk – this should disconnect the VHD from the host
  3. Compact the VHD using the “Edit Virtual Hard Disk Wizard”. At the time I disconnected the VHD from the host, the size of the VHD was 36.38GB. After compacting it the size came down to 28.13GB… and this is more in line with the actual disk consumed that you see in the graph above
  4. Copy the VHD to the Replica site, mount it on the Replica host, and complete the OOB IR process!


Hope this blog post helps with setting up your own Hyper-V Replica sites from scratch using OOB IR! Try it out and let us know your feedback.

Azure Site Recovery – FAQ

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.

Disaster Recovery to Microsoft Azure – Part 1

Drum roll please!

We are super excited to announce the availability of the preview bits of Azure Site Recovery (ASR) which enables you to replicate Hyper-V VMs to Microsoft Azure for business continuity and disaster recovery purposes.

You can now protect, replicate, and failover VMs directly to Microsoft Azure – our guarantee remains that whether you enable Disaster Recovery across On-Premise Enterprise Private Clouds or directly to Azure, your virtualized workloads will be recovered accurately, consistently, with minimal downtime and with minimal data loss.

ASR supports Automated Protection and Replication of VMs, customizable Recovery Plans that enable One-Click Recovery, No-Impact Recovery Plan Testing (ensures that you meet your Audit and Compliance requirements), and best-in-class Security and Privacy features that offer maximum resilience to your business critical applications. All this with minimal cost and without the need to invest in a recovery datacenter. To know more about this announcement and what we have enabled in the Preview, check out Brad Anderson’s In the Cloud blog.

We will cover this feature in detail in the coming weeks – stay tuned and try out the feature. We love to hear your feedback!

Application consistent recovery points with Windows Server 2008/2003 guest OS

I recently had a conversation with a customer around a very interesting problem, and the insights that were gained there are worth sharing. The issue was about VSS errors popping up in the guest event viewer while Hyper-V Replica reported the successful creation of application-consistent (VSS-based) recovery points.

Deployment details

The customer had the following setup that was throwing errors:

  1. Primary site:   Hyper-V Cluster with Windows Server 2012 R2
  2. Replica site:   Hyper-V Cluster with Windows Server 2012 R2
  3. Virtual machines:   SQL server instances with SQL Server 2012 SP1, SQL Server 2005, and SQL Server 2008

At the time of enabling replication, the customer selected the option to create additional recovery points and have the “Volume Shadow Copy Service (VSS) snapshot frequency” as 1 hour. This means that every hour the VSS writer of the guest OS would be invoked to take an application-consistent snapshot.


With this configuration, there was a contradiction in the output – the guest event viewer showed errors/failure during the VSS process, while the Replica VM showed application-consistent points in the recovery history.

Here is an example of the error registered in the guest:

SQLVM: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=2644. Thread=7212. Client. Instance=. VD=Global*******


BACKUP failed to complete the command BACKUP DATABASE model. Check the backup application log for detailed messages.


BackupVirtualDeviceFile::SendFileInfoBegin:  failure on backup device '{********-63**-49**-BA**-5DB6********}1'. Operating system error 995(error not found).

Root cause and Dealing with the errors

The big question was:  Why was Hyper-V Replica showing application-consistent recovery points if there are failures?

The behavior seen by the customer is a benign error caused because of the interaction between Hyper-V and VSS, especially for older versions of the guest OS. Details about this can be found in the KB article here: http://support.microsoft.com/kb/2952783

The Hyper-V requestor explicitly stops the VSS operation right after the OnThaw phase. While this ensures application-consistency of the writes going to the disk, it also results in the VSS errors being logged. Meanwhile, Hyper-V returns the consistency correctly to Hyper-V Replica, which in turn makes sure that the recovery side shows application-consistent points.

A great way to validate whether the recovery point is application-consistent or not is to do a test failover on that recovery point. After the VM has booted up, the event viewer logs will have events pertaining to a rollback – and this would mean that the point is not application consistent.

Key Takeaways

  1. All in all, you can rest assured that in the case of VMs with older operating systems, Hyper-V Replica is correctly taking an application-consistent snapshot of the virtual machine.
  2. Although there are errors seen in the guest, they are benign and having a recovery history with application-consistent points is an expected behavior.