Hyper-V VM migration in 5 steps

Requirements:
• Compatible Server (Windows 2008 Server DC Edition w/Hyper-V)
• Method of connecting from Source server to Destination Server.
• Source and Destination server must reside on the same VLAN. (For easy migration) Should they not reside on the same VLAN Re-IP'ing of the Virtual Machine will be necessary which will require an open Support ticket.
• Virtual Machines must have working network uplinks and working/supported Software installed.

Summary:

The two most common reasons why you may need to relocate your Hyper-V Virtual Machine: The VM is on hardware that is not functioning properly, or the current host server is running low on resources. In either event, the Hyper-V migration can be completed rather quickly if you have the requirements listed above and follow the steps below.

Step 1:

Login to the Source server and open your Hyper-V Manager Screen and select the Virtual Machine you would like to migrate to the Destination Server, the screen should be similar to the one below:

Step 2:

Gracefully shutdown the virtual machine you wish to migrate. Then select the Export option under the Server actions list, the screen should be similar to the one below:

The Export option will then ask you the desired location for the export file; in this example we have chosen the Desktop.

Step 3:

Now using RDP on our Source server we can login to the Destination server with our C: drive mounted in order to bring the file over, the screen should be similar to the one below:

In our example, "Romeo" is the Source server and we are logging into "Romeo2" which is our Destination server. Note: We are transferring the file via a resource mount through RDP, you can choose the transfer method that is most comfortable to you for this process (Windows Sharing, Resource mount via RDP, FTP, etc.)

Step 4:

Now that we have our exported file on the Destination server we will make sure it is in the default location for Hyper-V Virtual Hard Disks or "VHD's" and import it. The default location is C:\Users\Public\Documents\Hyper-V\Virtual hard disks , if you have changed this default location and are not sure of what it was, you can always select the "Hyper-V Settings" link on the Home page for Hyper-V Manager. Just above the "Hyper-V Settings" link you will find the "Import Virtual Machine" link, the screen should be similar to the one below:

Step 5:

Once you locate the Exported file and click the Import button, seconds later the Virtual Machine will be populated into your Hyper-V Manager with all configurations and files it had previously. If the conditions listed at the beginning of this Walkthrough were met the server will now be online and working. If your server did not match the requirements above and the destination server resides in a different VLAN you will need to Re-IP the virtual machine with a Portable Subnet (Routed as Secondary on VLAN).  The final result should be similar to the one below:

 

When should you enable IMAP in Exchange?

I know that IMAP is disabled by default in Exchange Server, but I'm curious as to why. Also, under what circumstances should an organization enable IMAP, and what types of organizations typically enable IMAP in Exchange?

Both the POP3 and IMAP services are installed, but disabled by default, in every Exchange Server release since Exchange 2003. The rationale behind the decision lies in security. It's not that IMAP and POP3 are inherently insecure, but the general school of thought is that IMAP and POP3 are not as frequently used as other protocols within Exchange to connect to mailboxes. Simply put, disabling IMAP and POP3 limits the potential attack surface on your Exchange servers.

For example, if you have a 5,000 user Exchange organization, and none of your user base connects to Exchange using either IMAP or POP3, it makes little sense to have the services running and listening. Doing so increases the number of open ports and also allocates precious memory and CPU resources to things you're not using.

Organizations generally enable IMAP -- or POP3 -- if they have users (usually senior-level executives) who use mail clients to access email that do not support MAPI or RPC over HTTP. The most prominent examples of this that I've seen are in organizations that do not support "traditional" means of connectivity to Exchange; think Thunderbird and Entourage.

It's hard to chart how many organizations use IMAP. Personally, I advise my customers against using IMAP if at all possible. My primary reason behind the suggestion is that IMAP introduces limitations to Exchange, thus not allowing the application to be used to its full potential.

That said, the following are common scenarios where I've found a definite business need to enable IMAP:

• When an organization has business software that needs a mailbox to participate in workflow processing, but only supports connectivity through IMAP. For example, one organization I worked with used Oracle HR and Payroll, which only supports IMAP connectivity for its workflow processes.
• When an organization only opens certain protocols through their firewalls for remote email access. For example, one organization I worked in did not allow OWA or RPC over HTTP, but did allow remote users to connect via IMAP.
• When an organization has employees who use "non-standard" client builds, such as Macs that do not have Microsoft Office installed but must access their company email.

The Microsoft Hyper-V snapshot

Snapshots are an important part of a Hyper-V administrator's toolkit. A Hyper-V snapshot allows an admin to roll back to a previous state, undoing changes and potentially saving recovery time. However, if you don't know how to use them properly, you could be setting yourself up for disaster and inadvertently slowing VM performance. Before you start taking virtual pictures of your own, make sure you know when and how to use a Hyper-V snapshot.

What is a Hyper-V snapshot?

While it seems like a simple question, defining what a Hyper-V snapshot is can be tricky. The confusion stems from inconsistent terminology and naming conventions, which seem to be an all-too-common problem with IT lingo. The most important thing is not to confuse a Volume Shadow Copy Service (VSS) snapshot with a Hyper-V snapshot. While both are used to restore a virtual machine (VM) to a prior state, they work in fundamentally different ways. VSS operates on the block level of the file system and only backs up disk information, while a Hyper-V snapshot captures disk and memory information of a VM by creating a separate automatic Virtual Hard Disk (.AVHD) file to track changes. Unlike VSS snapshots, Hyper-V snapshots aren't the answer to backups or disaster recovery. Instead, you should use them as a troubleshooting option, should a configuration change or patch update cause problems.

How do Hyper-V snapshots work, and what are they used for?

When you create a Hyper-V snapshot, you're actually creating a differencing disk. A differencing disk stores changes, or differences, that would otherwise be written to the original virtual hard disk. As the VM continues to change, the differencing disk grows in size. VSS snapshots differ because they create a copy of the disk image at a specific time. Think of a Hyper-V snapshot like an "undo" option, rather than an independent backup.

Hyper-V snapshots are extremely useful for quickly reverting a VM back to a previous state, after an administrator realizes that an update failed or that a configuration change caused unexpected problems. The downside is that, if left unchecked, those expanding differencing disks can slow VM performance and fragment a hard drive.

How do I take a Hyper-V snapshot?

Many admins choose to create snapshots right before making any potentially risky change to a VM's state. The actual act of creating a Hyper-V snapshot from the Hyper-V Manager in the Microsoft Management Console is a simple process: Simply right-click on a VM and select Snapshot. The time it takes to create a snapshot will depend on many factors, including the size of the VM and the disk's overall I/O load.

It's important to delete and merge older snapshots that can continue to grow and hurt performance. In Windows Server 2008 R2, completely deleting the snapshot means shutting down the VM.

What changed with Hyper-V snapshots in Windows Server 2012?

Snapshots created in Windows Server 2012 can be merged and completely deleted without shutting down the VM. This live merging of snapshots can save administrators time and aggravation by allowing them to perform updates to VMs without the risk of secondary downtime (once to perform the update and again to delete the snapshot). This new feature brings Hyper-V snapshots more in line with VMware snapshots, which do not require the shutdown of a VM to merge snapshots.

Backup Data Deduplication Layer

As backup data deduplication matures, it's still very much a proprietary technology. We need standardization to eliminate some of today's software-hardware headaches.

Just about everyone who works with disk-based backup understands the need for data deduplication. For many, that includes the use of a deduplication storage appliance as a data backup target. Most backup software products can use deduplication appliances that present themselves as either a file share (NFS or CIFS) or a tape device (virtual tape library or VTL). The challenge with those approaches is that the backup software doesn't know it's writing to a deduplication target. All the data is sent from the backup software to the appliance, and then most of the data is discarded when the appliance determines it has it stored.

If simply leveraging a deduplication appliance was "Dedupe 1.0," then "Dedupe 2.0" is to optimize the process by making the backup software deduplication-aware. It seems as if almost every deduplication array now offers API libraries that enable backup software to optimize the backup process, such as:

    EMC Data Domain with DD Boost
    HP StoreOnce Catalyst
    Quantum DXi with Accent

The list goes on, but the point is that for backup software users to better leverage their deduplication hardware, their software provider has to embrace that particular hardware vendor's accelerator APIs. Of course, many of those hardware providers also sell data backup software that leverages those APIs, such as EMC NetWorker with Data Domain or HP Data Protector with StoreOnce.

We can classify the alternatives a little differently, on a "good-better-best" scale:

    "Good" deduplication is simply using a deduplication appliance.
    "Better" deduplication involves a backup server that's dedupe-aware.
    "Best" deduplication enables deduplication at the production source server within the backup agents.

Unfortunately, there are very few hardware plus software "best" offerings. For example, EMC Data Domain offers a "best" solution with NetWorker (meaning its deduplication can occur client-side), whereas other software solutions that leverage Data Domain only offer "better" deduplication from the backup server. This isn't a knock on EMC, but on the complexity of adding those deduplication APIs to the client agents. If a third-party software vendor wanted to deliver a "best" deduplication experience that still appealed to that software vendor's broad customer base, they would have to engineer their agents to use DD Boost, Catalyst, Accent and others, and then absorb some appreciable development, testing and support requirements.

One backup software vendor, Symantec, has a different approach through its OpenStorage Technology (OST) mechanisms. Instead of the deduplication appliance presenting itself as a VTL or file share, or offering its own API accelerator, it can support Symantec's OST standard that provides interoperability with Backup Exec and NetBackup. Essentially, instead of the software vendors writing to the APIs of one or more hardware vendors, the hardware vendors write to Symantec's OST specifications. Hardware vendors do this because of the Symantec products' time and presence in market, but what if other software vendors each published specifications similar to OST? This creates the same challenges described above, where each hardware vendor would have to develop and support multiple software specifications.

So, what's the answer? In a perfect world, there would be a data deduplication API layer that works across wide ranges of backup software and hardware vendors. Symantec OST is used by many hardware vendors, but only with Symantec software products. EMC DD Boost has a broad ecosystem of software partners, but it only works with EMC Data Domain appliances. What would happen if Symantec or EMC licensed the API libraries for interoperability across all hardware/software players? Who would support it, and what would happen to the differentiation in the "better together" stacks? At first glance, it appears to benefit a variety of constituents, including participating vendors, partners, and IT organizations struggling with the current mixing and matching. But in reality, it's a chicken-and-egg challenge and nobody is moving.

A standard backup data deduplication layer may seem like a pipe dream, but it isn't the first time it's been suggested. At one time, backup software vendors each wrote their own backup software agents per application workload. Each of those software vendors did their own engineering to understand how to get the data out of the databases and other production applications, as well as how to restore the data. Meanwhile, storage hardware vendors used to create their own application agents to enable their own data protection solutions. All those vendors talked about innovation and differentiation (and they were right), but it made solution designs and support challenging not just for IT teams, but for partners and vendors. What if someone had suggested a common layer for backup software, storage hardware and applications?

Actually, someone did. With Windows as the primary OS, and Exchange and SQL Server as key applications that would benefit, Microsoft introduced Volume Shadow Copy Service (VSS) several years ago to enable that common layer from within the Windows OS. Backup software vendors now include VSS requesters in their agents, hardware vendors include VSS providers and application vendors can now use VSS writers. Adoption was slow initially, but now almost every Windows application uses VSS -- and everyone benefits. A common layer for backup software and storage hardware to interoperate happened once for application backups. Let's hope it will happen again for deduplication.

Windows Server 2012 Hyper-V introduction

Last year was a year of change, especially for Microsoft with its release of Windows Server 2012 Hyper-V earlier this year. Adapting to change can be tough, but we're here to help get you up to speed on Hyper-V changes. In this Windows Server 2012 Hyper-V introduction, we cover topics like licensing options, the new Hyper-V virtual hard disk format and planning for Hyper-V updates. Then take the quiz to see how prepared you are for a Windows Server 2012 Hyper-V 3.0 upgrade.

Microsoft Windows Server 2012 removes licensing option for Hyper-V

Microsoft's Windows Server 2012, which includes Hyper-V 3.0, simplified its licensing in September, eliminating the Enterprise edition and giving users two options instead: the Datacenter and Standard editions. The Datacenter edition comes at a cost of $4,809 per two processors, with unlimited virtual operating system instances. The Standard edition comes at a cost of $882 per host, with two virtual operating system instances.

Microsoft hoped its new licensing would make things easier for IT shops. The Datacenter edition is the best option for highly virtualized environments. On the other hand, the Standard edition is the best fit for small IT shops, because licenses can be accumulated to reach the number of virtual machines (VMs) needed for low-ratio virtualized environments.

However, any organization requiring more than five Standard licenses is probably better off just purchasing the Datacenter edition.

Getting to know VHDX: The new Hyper-V virtual hard disk format

The new VHDX virtual hard disk format replaced Virtual Hard Disk (VHD). This key feature to Windows Server 2012 Hyper-V allows administrators to create much larger virtual hard disks with a 64 TB capacity. IT pros with existing Hyper-V environments that use the VHD file format will be able to convert them easily to the VHDX format when they acquire Windows Server 2012. However, it is important to migrate VMs to Windows Server 2012 Hyper-V servers to be able to make the format conversion.

Fixed and dynamically expanding virtual hard disks are still available, but the VHDX version has the ability to create differencing disks in Hyper-V Manager. Differencing disks make it easier to build VMs from a VM template and actually allows you to spawn multiple VMs from one VM template parent.

VHDX files support larger block sizes for differencing and dynamically expanding disks. Additionally, Microsoft has taken steps to prevent corruption within VHDX files. It seems that the VHDX features can make IT pros happy.

Creating a Hyper-V update roadmap to get it right the first time

When planning for a Hyper-V update with Windows Server 2012, there are key points to consider. First, take into account Microsoft's new licensing model, which only offers either the Datacenter or Standard edition. If you have the Windows Server 2008 R2 Enterprise Edition, you will only be able to upgrade to the Datacenter Edition.

Keep in mind that the update does cause a bit of downtime, so schedule a time that will be the least disruptive for end users. On the other hand, if your Hyper-V servers are clustered, it will require a migration to a couple of new servers. You also have to determine what to do with VMs during the migration

Here are some key things to keep in mind while doing the update. First, backup all of your VMs and virtual hosts. Before performing either an in-place upgrade or migration, you should rehearse the Hyper-V update in a test environment. Finally, once the VMs are running on the updated hypervisor, you'll need to update Microsoft Integration Services on each VM.

Windows Server 2012 Hyper-V introduction to storage

Even with the new storage architecture of Windows Server 2012 Hyper-V, Microsoft can still make some improvements. There are three methods, however, that could simplify Hyper-V management and reduce downtime.

First, you can convert to the new VHDX format with minimal downtime for your Hyper-V VMs if you are a legacy VHD user. Second, you can change from fixed to dynamically expanding disks without downtime. This could save your organization not only time but money, because Hyper-V will better use storage resources, and administrators can easily alternate between disk types, reducing effort and downtime.

And finally, expand VM storage without any downtime. This not only saves a considerable amount of time but also reduces the administrative practice of overprovisioning disk resources. Thus, organizations could utilize their storage resources in a more intelligent way, saving them money. The purpose of these three methods is for IT pros to spend less time coordinating downtimes so that they can focus on optimizing management and performance.

Managing Hyper-V From the Command Line #8

Working with Snapshots

One of the first tricks that I want to show you involves getting a list of all of the snapshots that exist on a particular Hyper-V host. You can accomplish this by entering the Get-VMSnapshot command. When you do, Hyper-V will display a table listing the snapshot description, the virtual machine for which the snapshot was created, the virtual machine's boot order, and when the virtual machine snapshot was created.

While it is sometimes handy to be able to look at the virtual machine snapshots at the host level, it is often more helpful to be able to view snapshots on a per VM basis. The easiest way to accomplish this is to append the name of a virtual machine to the Get-VMSnapshot command. For example, to see all of the snapshots for a virtual machine named Storage you would enter: Get-VMSnapshot Storage

Figure A shows examples of retrieving snapshot information for an entire Hyper-V host and for a single virtual machine.

Figure A: You can use the Get-VMSnapshot command to retrieve snapshot information.

As you can see in the figure above, snapshot information is listed for the specified virtual machine. However, snapshots are normally displayed in a tree view so that it is easier to tell how the snapshots relate to one another. If you prefer to view your snapshots as a tree you can easily do so by using the Get-VMSnapshotTree command. The syntax for this command is identical to that of the Get-VMSnapshot command. In fact, Figure B shows both the Get-VMSnapshot command and the Get-VMSnapshotTree command being used so that you can see the difference in the command's output.

Figure B: The Get-VMSnapshotTree command displays snapshot information as a tree.

Creating a Snapshot

The Hyper-V module for PowerShell really provides some nice options when it comes to snapshot creation. At its most basic you can create a new snapshot by entering the New-VMSnapshot command, followed by the name of the virtual machine that you want to snapshot. If you want, you can even append the Note parameter as a way of leaving yourself a note about the snapshot's purpose. Of course creating a note is completely optional.

To show you how this works, suppose that I wanted to create a snapshot for a virtual machine named Storage. To do so, I would enter the following command:

New-VMSnapshot Storage –Note "Snapshot Demo"

When you execute this command, PowerShell will prompt you as to whether or not you want to perform the action. You will then see a warning message indicating that the operation is occurring in the background. You can use the Get-VMSnapshot command to verify that the snapshot was created, as shown in Figure C.

Figure C: Snapshots can be created from the command line.

Another cool thing that you can do is to create multiple snapshots in sequence. For example, I have a host server on which most of the virtual machines are named Lab- something. If I wanted to, I could create snapshots of all of my Lab virtual machines through the use of wildcards. The trick is to combine the New-VMSnapshot command with the Get-VM command that I showed you in a previous part of this series. The full command looks something like this:

Get-VM "Lab%" –Server "Hyper-V" | New-VMSnapshot –wait

You will notice that I had to specify the name of my Hyper-V host, which was named Hyper-V. More importantly, I had to specify the –Wait parameter at the end of the command. This causes Hyper-V to wait for one snapshot to be created before starting the next one. You can see the command and its output in Figure D.

Figure D: You can create multiple snapshots through a single command.

Rolling Back a Snapshot

So what happens if you want to roll back a virtual machine to a previous state? Well, you can easily perform a virtual machine rollback by using the Restore-VMSnapshot command.

Before you can use this command, you have to select the snapshot that you want to remove. This is accomplished by using the Select-VMSnapshot command. Once you have selected the desired snapshot, you can roll the virtual machine back by using the Restore-VMSnapshot command.

To show you how this command works, consider that earlier I created a snapshot for a virtual machine named Storage. As you will recall, a couple of snapshots already existed for that virtual machine. Therefore, if I want to roll the virtual machine back to a previous state then it is necessary to choose which snapshot I want to use.

The command for doing so is:

Select-VMSnapshot Storage | Restore-VMSnapshot

When I execute the command, PowerShell asks which snapshot I want to use. When I make my selection, the virtual machine is rolled back, as shown in Figure E.

Figure E: You must select which snapshot you want to roll back.

Removing a Snapshot

You can use a very similar technique to remove a snapshot. The removal process uses the Remote-VMSnapshot command. The syntax for this command is identical to that of the Restore-VMSnapshot command. For example, if you wanted to remove a snapshot from the virtual machine named Storage, you could use the following command:

Select-VMSnapshot Storage | Remove-VMSnapshot

This command also gives you the option of removing an entire snapshot tree. To do so, simply append the –Tree switch to the end of the command like this:

Select-VMSnapshot Storage | Remove-VMSnapshot -Tree

Managing Hyper-V From the Command Line #7

What is Left?

When we initially created the virtual machine, we allocated 2048 MB of memory to it. After that, we created a virtual hard disk file and told the virtual machine to use it. Finally, we provided the virtual machine with a virtual network adapter. Technically the virtual machine could stand on its own right now. Even so, I want to walk you through the process of allocating a bit more hardware. For the purposes of this article, we will add an extra virtual CPU to the virtual machine and we will add a secondary virtual hard drive.

Virtual CPUs

Even though we already know that the virtual machine that we created was automatically provisioned with a single virtual CPU core, let's pretend that we don't know how many virtual CPUs have been allocated. The easiest way to determine virtual CPU allocation is to enter the Get-VMCPUCount command.

If you look at Figure A, you can see that I have used this command in two different ways. First, I entered the command by itself, which caused Hyper-V to return virtual CPU allocation information for every virtual machine on the host. Next, I entered the command again, but this time I specified the name of one specific virtual machine. This caused Hyper-V to return virtual CPU allocation information solely for that one virtual machine.

Figure A: The Get-VMCPUCount command returns information about virtual CPU allocation.

Regardless of whether we specify one virtual machine or look at all of the virtual machines, several key pieces of information are returned. First, take a look at the Quantity column. This column reflects the number of virtual CPUs that have been allocated to each virtual machine. Another column worth paying attention to is the Cores / Socket column. This column tells you how many physical CPU cores the server has for each CPU socket. Finally, the Socket Count column tells you the number of physical CPU sockets that the server is equipped with.

So now that we have determined the current virtual CPU count, let's go ahead and set the number of virtual CPUs that are assigned to the virtual machine to two. You can allocate up to four virtual CPUs to a virtual machine, but the virtual machine's operating system must support using the number of virtual CPUs that you provide it with. Furthermore, you cannot exceed the total number of physical cores that are installed in the server.

You can modify a virtual machine's CPU allocation by simply specifying the name of the virtual machine and the number of CPU cores that you want to assign. For example, if you wanted to assign two virtual CPU cores to a virtual machine named Windows Server 8 Beta then you would use the following command:

Set-VMCPUCount "Windows Server 8 Beta" 2

If you look at Figure B, you can see that when I enter this command, the Quantity count changes from one to two.

Figure B: The virtual CPU quantity changes from one to two.

Technically this achieves the objective of increasing the number of virtual CPUs that are allocated to our new virtual machine. Even so, there are a few extra parameters that can be used along with this command that I want to mention. I won't go into all of the parameters because they are listed in the documentation and some of them don't really do anything too exciting. However, a few of the more useful parameters that you might want to use are:

Limit – The Limit parameter lets you specify the maximum amount of time that a virtual machine is allowed to use a physical CPU. The default limit is 100% usage.

Reservation – The Reservation parameter lets you reserve a percentage of CPU time solely for a specific virtual machine. By default the reservation is set at 0%.

Weight – The weight parameter lets you set a relative weight that affects how much CPU time a virtual machine will receive. The default weight is 100.

Adding an Additional Virtual Hard Disk

The last thing that I want to do to the newly created virtual machine is to provide it with an additional virtual hard disk. The procedure for doing so is very similar to the procedure that we already used to create the virtual machine's primary virtual hard disk.

The first step in the process is to actually create the virtual hard disk file. This can be done through the now familiar New-VHD command. You can see an example of the command below:

New-VHD –VHDPath "F:\Windows Server 8 Beta\SecondVHD.vhd" –Size 16106127360

Next, we have to assign the virtual machine to a variable name ($VM in this case), and then attach the virtual hard disk to a virtual disk controller on the virtual machine. The two commands that will be required to complete this operation are:

$VM=Get-VM "Windows Server 8 Beta" –Server Hyper-V

Add-VMDisk –VM $VM –ControllerID 0 –LUN 0 –VHDPath "F:\Windows Server 8 Beta\SecondVHD.vhd"

You can see these commands and their result in Figure C. If you need any help understanding what these commands are doing then be sure to either check out Part 6 of this series or the documentation for the PowerShell module for Hyper-V.

Figure C: You can create and attach a new virtual hard disk file from the command line.

Now that we are done, take a look at Figure D. This is the virtual machine's Settings page, as seen through the Hyper-V Manager. You will notice that the newly created virtual machine now has two virtual processors, a VM-Bus network adapter (which we created in Part 6), and two virtual hard drives.

Figure D: The virtual machine is now fully provisioned.