When I started my IT career, the best advice I received from one of my mentors was the old saying, "knowledge is power." The quote may seem trite, but I'm constantly reminded about the importance of keeping up to date on the technologies my company relies on to conduct business. A problem one day might be easily solved the next if you are aware of your options.
One of my favorite features in Windows Server 2012 is Hyper-V Replica. In a nutshell, you can replicate your virtual machines (VMs) from one server to another -- the replication will keep the copy up to date. At first glance this might not seem like much, but it's perfect for a disaster recovery (DR) site and a great way for small and medium-sized businesses to add a layer of protection and decrease recovery time without expensive or complicated storage area network, or SAN-based and clustered host approaches.
While working with Hyper-V Replica, a fellow IT pro ran into a problem when resizing the virtual disks at his primary site. To resize a virtual disk, you must take the VM offline. Because there is no way to track and replicate changes when the VM is offline, Microsoft marks the primary VM as resynchronization required. When you restart the VM, it immediately re-syncs with the replica disk. However, the immediate resynchronization can be very demanding on bandwidth and IOPS. The benefit of having a Hyper-V Replica outweighs this management problem, but make no mistake, it can go from an annoyance to outright painful.
Resizing running VMs
Microsoft has addressed the problem, and in Windows Server 2012 R2, you can resize Hyper-V Replica virtual disks on running VMs. This means the changes can be tracked and synchronized without the downtime or performance loss of re-syncing to the DR site.
Resizing a virtual disk is very simple, but there are some caveats when performing it on a live VM with Hyper-V Replica. When you resize the disks in the primary site, Hyper-V does not automatically resize them in the DR site. This means you need to resize the disks separately in each site.
1. Start with the primary site and resize the virtual disk using either the Edit Virtual Hard Disk wizard or the Windows PowerShell cmdlet Resize-VHD.
PS> Resize-VHD -Path <the Path to the VHD> -SizeBytes <The size in bytes>
This does not affect your current replication because the additional space is marked as unallocated and can't be used for disk writes. We will fix this shortly, but we much resize the replica site (DR, in our case) first.
2. In the DR site, resize the replica disk using either the Edit Virtual Hard Disk wizard or the Window PowerShell cmdlet Resize-VHD. You can imagine that as the primary virtual disk begins to use the new space, there will be replication errors. If you make a mistake, simply resize the replica disk and resume replication from the primary site.
3. The last step is to use the Disk Management utility in the guest VM to claim the unallocated disk space.
Keep in mind that the Hyper-V Replica live disk resizing is a feature of Windows Server 2012 R2, so you will need to be using that version.
Keeping up to date on new technologies is a good way of helping your business evolve and keeping your needs satisfied. The more you learn now will be beneficial in the long run if any issues arise. After all, as they say, "knowledge is power."
Dig deeper on Microsoft Hyper-V and Virtual Server
Jason Helmick asks:
What benefits have you experienced from Hyper-V Replica?
0 ResponsesJoin the Discussion