The ABC of Hyper-V – 7 Steps to Get Started

The ABC of Hyper-V – 7 Steps to Get Started

Authors commonly struggle with the blank, empty starting page of a new work. So, if you’ve just installed Hyper-V and don’t know what to do with that empty space, you’re in good company. Let’s take a quick tour of the steps from setup to production-ready.

1. Make a Virtual Machine

It might seem like jumping ahead, but go ahead and create a virtual machine now. It doesn’t matter what you name it. It doesn’t matter how you configure it. It won’t be ready to use and you might get something wrong — maybe a lot of somethings — but go ahead. You get three things out of this exercise:

  • It’s what we authors do when we aren’t certain how to get started with writing. Just do something. It doesn’t matter what. Just break up that empty white space.
  • You learn that none of it is permanent. Make a mistake? Oh well. Change it.
  • You have a focused goal. You know that the VM won’t function without some more work. Instead of some nebulous “get things going” problem, you have a specific virtual machine to fix up.

If you start here, then you’ll have no network for the virtual machine and you may wind up with it sitting on the C: drive. That’s OK.

If you want to know the basic steps for how to create a virtual machine in Hyper-V Manager, start with this article.

2. Install Updates and Configure the System

I try to get the dull, unpleasant things out of the way before I do anything with Hyper-V. In no set order:

3. Configure Hyper-V Networking

For Hyper-V configuration, I always start with my networking stack. You will likely spend a lot of time on this, especially if you’re still new to Hyper-V.

For a server deployment, I recommend that you start with my overview article. It will help you to conceptualize and create a diagram of your configuration design before you build anything. At the end, the article contains further useful links to how-to and in-depth articles:

For a Windows 10 deployment using a current release build, you’ll automatically get a “Default Switch”. If you connect your virtual machines to it, they’ll get an IP, DNS, and NAT functionality without any further effort on your part. You can read more about that (and some other nifty Windows 10 Hyper-V features) in Sarah Cooley’s article:

4. Prepare Storage for Virtual Machines

Storage often needs a lot of time to configure correctly as well.

First, you need to set up the basic parts of storage, such as SAN LUNs and volume. I’d like to give you a 100% thorough walk-through on it (perhaps at a later date), but I couldn’t possibly cover more than a few options. However, I’ve covered a few common methods in this article: I didn’t cover fiber channel because no two vendors are similar enough to write a good generic article. I didn’t cover Storage Spaces Direct because it didn’t exist yet and I still don’t have an S2D cluster of my own to instruct from.

Whatever you choose to use for storage, you need at least one NTFS or ReFS location to hold your VMs. I’m not even going to entertain any discussion about pass-through disks because, seriously, join this decade and stop with that nonsense already. I’m still recommending NTFS because I’m not quite sold on ReFS for Hyper-V yet, but ReFS will work. One other thing to note about ReFS, is to make sure your backup/recovery vendor supports it.

5. Configure Hyper-V Host Settings

You probably won’t want to continue using Hyper-V’s defaults for long. Storage, especially, will probably not be what you want. Let’s modify some defaults. Right-click your host in Hyper-V Manager and click Hyper-V Settings.

This window has many settings, far more than I want to cover in a quick start article. I’ll show you a few things, though.

Let’s start with the two storage tabs:

You can rehome these anywhere that you like. Note:

  • For the Virtual Hard Disks setting, all new disks created using default settings will appear directly in that folder
  • For the Virtual Machines setting, all non-disk VM files will be created in special subfolders

In my case, my host will own local and clustered VMs. I’ll set my defaults to a local folder, but one that’s not as deep as what Hyper-V starts with.

Go explore a bit. Look at the rest of the default settings. Google what they mean, if you need. If you’ll be doing Shared Nothing Live Migrations, I recommend that you enable migrations on the Live Migrations tab.

6. Fix Up Your VM’s Settings

Remember that VM that I told you to create back in step one? I hope you did that because now you get to practice working with real settings on a real virtual machine. In this step, we’ll focus on the simple, direct settings. Right-click on your virtual machine and click Settings.

If you followed right through, then the VM’s virtual network adapter can’t communicate because it has no switch connection. So, jump down to the Network Adapter tab. In the Virtual Switch setting, where it says, Not connected, change it to that switch that you created in step 3.

Again, poke through and learn about the settings for your virtual machine. You’ll have a lot more to look at than you did for the host. Take special notice of:

  • Memory. Each VM defaults to 1GB of dynamic memory. You can only change a few settings during creation. You can change many more now.
  • Processor: Each VM defaults to a single virtual CPU. You’ll probably want to bump that up to at least 2. We have a little guidance on that, but the short version: don’t stress out about it too much.
  • Automatic start and stop actions: These only work for VMs that won’t be clustered.

Check out the rest of it. Look up anything that seems interesting.

7. Practice with Advanced Activities and Settings

If you followed both step one and the storage location bit of step five, then that virtual machine might not be in the location that you desire. Not a problem at all. Right-click it and choose Move. On the relevant wizard page, select Move the virtual machine’s storage:

Proceed through the wizard. If you want more instruction, follow our article.

Not everything has a predefined setting, unfortunately. You’ll occasionally need to do some more manual work. I encourage you to look into PowerShell, if you haven’t already.

Changing a Virtual Machine’s VHDX Name

Let’s say that you decided that you didn’t like the name of the virtual machine that you created in step one. Or, that you were just fine with the name, but you didn’t like the name of its VHDX. You can change the virtual machine’s name very simply: just highlight it and press [F2] or right-click it and select Rename. Hyper-V stores virtual machine’s names as properties in their xml/vmcx files, so you don’t need to change those. If you put the VM in a specially-named folder, then you can use the instructions above to move it to a new one. The VHDX doesn’t change so easily, though.

Let’s rename a virtual machine’s virtual hard disk file:

  1. The virtual machine must be off. Sorry.
  2. On the virtual hard disk’s tab in the virtual machine’s settings, click Remove:
  3. Click Apply. That will remove the disk but leave the window open. We’ll be coming back momentarily.
  4. Use whatever method you like to rename the VHDX file.
  5. Back in the Hyper-V virtual machine’s settings, you should have been left on the controller tab for the disk that you removed, with Hard Drive selected. Click Add:
  6. Browse to the renamed file:
  7. Click OK.

Your virtual machine can now be started with its newly renamed hard disk.

Tip: If you feel brave, you can try to rename the file in the browse dialog, thereby skipping the need to drop out to the operating system in step 4. I have had mixed results with this due to permissions and other environmental factors.

Tip: If you want to perform a storage migration and rename a VHDX, you can wait to perform the storage migration until you have detached the virtual hard disk. The remaining files will transfer instantly and you won’t have a copy of the VHDX. After you have performed the storage migration, you can manually move the VHDX to its new home. If the same volume hosts the destination location, the move will occur almost instantly. From there, you can proceed with the rename and attach operations. You can save substantial amounts of time that way.

Bonus round: All of these things can be scripted.

Moving Forward

In just a few simple steps, you learned the most important things about Hyper-V. What’s next? Installing a guest operating system, of course. Treat that virtual machine like a physical machine, and you’ll figure it out in no time.

Need any Help?

If you’re experiencing serious technical difficulties you should contact the Microsoft support team but for general pointers and advice, I’d love to help you out! Write to me using the comment section below and I’ll get back to you ASAP!

How to Create Virtual Machine Templates with Hyper-V Manager

How to Create Virtual Machine Templates with Hyper-V Manager

As an infrastructure hypervisor, Hyper-V hits all the high notes. However, it misses on some of the management aspects, though. You can find many control features in System Center Virtual Machine Manager, but I don’t feel that product was well-designed and the pricing places it out of reach of many small businesses anyway. Often, we don’t even need a heavy management layer; sometimes just one or two desires go unmet by the free tools. Of those, admins commonly request the ability to create and deploy templates. The free tools don’t directly include that functionality, but you can approximate it with only a bit of work.

The Concept of the Gold Image

You will be building “gold” or “master” (or even “gold master”) images as the core of this solution. This means that you’ll spend at least a little time configuring an environment (or several environments) to your liking. Instead of sending those directly to production, you’ll let them sit cold. When you want to deploy a new system, you use one of those as a base rather than building the instance up from scratch.

As you might have guessed, we do need to take some special steps with these images. They are not merely regular systems that have been turned off. We “generalize” them first, using a designated tool called “sysprep”. That process strips away all known unique identifiers for a Windows instance. The next time anyone boots that image, they’ll be presented with the same screens that you would see after freshly installing Windows. However, most non-identifying customization, such as software installations, will remain.

Do I Need Gold Images?

The simpler your environment, the less the concept of the gold image seems to fit. I wouldn’t write it off entirely, though. Even with rare usage, you can use a gold image to jump ahead of a lot of the drudgery of setting a new system. If you deploy from the same image only twice, it will be worth your time.

For any environment larger than a few servers, the need for gold images becomes apparent quickly. Otherwise, you wind up spending significant amounts of time designing and deploying new systems. Since major parts of new server deployments share steps (and the equivalent involved time), you get the best usage by leveraging gold images.

Usually, the resistance to such images revolves around the work involved. People often don’t wish to invest much time in something whose final product will mostly just sit idle. I think that there’s also something to that “all-new” feeling of a freshly built image that you lose with gold images. The demands of modern business don’t really allow for these archaic notions. Do the work once, maybe some maintenance effort later, and ultimately save yourself and your colleagues many hours.

Should I Image Workstation or Server Environments?

The majority of my virtualization experience involves server instances. To that end, I’ve been using some sort of template strategy ever since I started using Hyper-V. I only build all-new images when new operating systems debut or significant updates release. Even if I wasn’t sure that I’d ever deploy a server OS more than once, I would absolutely build an image for it.

Workstation OSes have a different calculus. If you’ll be building a Microsoft virtual-machine RDS deployment, then you cannot avoid gold images. If you’re using only hardware deployments, then you might still image, but probably not the way that I’m talking about in this article. I will not illustrate workstation OSes, as the particulars of the process do not deviate meaningfully from server instances.

What About OS and Software Keys?

For operating systems, you have two basic types:

  • Keyed during install: This key will be retained after the sysprep, so you’ll need to use a key with enough remaining activations. KMS keys work best for this. With others, you’ll need to be prepared to change the key after deployment if the situation calls for it. If you have Windows Server Datacenter Edition as your hypervisor, then you can use the AVMA keys. If you don’t have DC edition, then you could technically still use the keys but you’ll have to immediately change it after deployment. I have no idea how this plays legally, so consider that a last-ditch risky move.
  • Keyed after install: This usually happens with volume licensing images. These are the best because you really don’t have to plan anything. Key it afterward. Of course, you also need to qualify for volume licensing in order to use this option at all, so…
  • OEM keys: I’m not even going to wade into that. Ask your reseller.

If you use the ADK (revisited a bit in an upcoming section), you have ways to address key problems.

As for software, you’ll have all sorts of issues with that. Most retain their keys. Lots of them have activation routines, too, so there’s that. And all of the things that come with it. You will need to think through and test. It will be worth the effort far more often than not.

What About Linux Gold Images?

Yes, you most certainly can create gold masters of Linux. In a way, it can be easier. Linux doesn’t use a lot of fancy computer identification techniques or have system-specific GUIDs embedded anywhere. Usually, you can just duplicate a Linux system at will and just rename it and assign a new IP.

Unfortunately, that’s not always the case. Because exceptions are so rare, there’s also no singular built-in tool to handle the items that need generalization. The only problem that I’ve encountered so far is with SSH keys. I found one set of instructions to regenerate them:

Creating Gold Images for Hyper-V Templating

The overall process:

  1. Create a virtual machine
  2. Install the operating system
  3. Customize
  4. Generalize
  5. Store
  6. Deploy

If that sounds familiar, you probably do something like that for physical systems as well.

Let’s go over the steps in more detail.

Creating the Virtual Machine and Installing the Operating System

You start by simply doing what you might have done any number of times before: create a new virtual machine. One thing really matters: the virtual machine generation. Whatever generation you choose for the gold image will be the generation of all virtual machines that you build on it. Sure, there are some conversion techniques… but why use them? If you will need Generation 1 and Generation 2 VMs, then build two templates.

The rest of the settings of the virtual machine that you use for creating a gold image do not matter (unless the dictates of some particular software package override). You have more than one option for image storage, but in all cases, you will deploy to unique virtual machines whose options can be changed.

Once you’ve got your virtual machine created, install Windows Server (or whatever) as normal (note, especially for desktop deployments: many guides mention booting in Audit mode, which I have never done; this appears to be most important when Windows Store applications are in use):

Customizing the Gold Image

If you’re working on your first image, I would not go very far with this. You want a generic image to start with. For initial images, I tend to insert things like BGInfo that I want on every system. You can then use this base image to create more specialized images.

I have plans for future articles that will expand on your options for customization. You can perform simple things, like installing software. You can do more complicated things, such as using the Automated Deployment Kit. One of the several useful aspects of ADK is the ability to control keying.

Tip: If you have software that requires .Net 3.5, you can save a great deal of time by having a branch of images that include that feature pre-installed:

Just remember that you want to create generic images. Do not try to create a carbon-copy of an intended live system. If that’s your goal (say, for quick rollback to a known-good build), then create the image that you want as a live system and store a permanent backup copy. You could use an export if you like.

Very important: Patch the image fully, but only after you have all of the roles, features, and applications installed.

Generalize the Gold Image

Once you have your image built the way that you like it, you need to seal it. That process will make the image generic, freezing it into a state from which it can be repeatedly deployed. Windows (and Windows Server) includes that tool natively: sysprep.

The best way to invoke sysprep is by a simple command-line process. Use these switches:


The first three parameters are standard. We can use the last one because we’re creating Hyper-V images. It will ensure that the image doesn’t spend a lot of time worrying about hardware.

Tip: If you want to use the aforementioned Audit Mode so that you can work with software packages, use /audit instead of /oobe.

Tip: You can also just run sysprep.exe to get the user interface where you can pick all of these options except the mode. Your image(s) will work just fine if you don’t use /mode:vm.

Once the sysprep operation completes, it will stop the virtual machine. At that point, consider it to be in a “cold” state. Starting it up will launch the continuation of a setup process. So, you don’t want to do that. Instead, store the image so that it can be used later.

Storing a Gold Image

Decide early how you want to deploy virtual machines from this image. You have the option of creating all-new virtual machines at each go and re-using a copy of the VHDX. Alternatively, you can import a virtual machine as a copy. I use both techniques, so I recommend export. That way, you’ll have the base virtual machine and the VHDX so you can use either as suits you.

Image storage tip: Use deduplicated storage. In my test lab, keep mine on a volume using Windows Server deduplication in Hyper-V mode. That mode only targets VHDX files and was intended for running VDI deployments. It seems to work well for cold image storage, as well. I have not tried with the normal file mode.

VHDX Copy Storage

If you only want to store the VHDX, then copy it to a safe location. Give the VHDX a very clear name as to its usage. Don’t forget that Windows allows you to use very, very long filenames. Delete the root virtual machine afterward and clean up after it.

The benefit of copy storage is that you can easily lay out all of your gold image VHDXs side-by-side in the same folder and not need to keep track of all of those virtual machine definition files and folders.

Exported Image Storage

By exporting the virtual machine, you can leverage import functionality to easily deploy virtual machines without much effort on your part. There are some downsides, but they’re not awful:

  • The export process takes a tiny bit of work. It’s not much, but…
  • When importing, the name of the VHDX cannot be changed. So, you wind up with a newly-deployed virtual machine that uses the same VHDX name as your gold image. That problem can be fixed, of course, but it’s extra work.

I discovered that we’ve never written an article on exporting virtual machines. I’ll rectify that in a future article and we’ll link this one to it. Fortunately, the process is not difficult. Start by right-clicking your virtual machine and clicking the Export option. Follow the wizard from there:

Tip: Disconnect any ISO images prior to exporting. Otherwise, the export will make a copy of that ISO to go with the VM image and it will remain permanently attached and deployed with each import.

Deploying Hyper-V Virtual Machines from Gold Images

From these images that you created, you can build a new virtual machine and attach a copy of the VHDX or you can import a copy.

Deploying from a VHDX Copy

VHDX copy deployment has two pieces:

  • Creation of a virtual machine
  • Attaching to a copy of the gold image VHDX

We have an article on using Hyper-V Manager to create a virtual machine. Make sure to use the same generation as the gold image. On the disk page, skip attaching anything:

Remember that Hyper-V Manager doesn’t have much for configuration options during VM creation. Set the memory and CPU and network up before proceeding.

To finish up, copy the gold image’s VHDX into whatever target location you like. You can use a general “Virtual Hard Disks” folder like the Hyper-V default settings do, or you can drop it in a folder named after the VM. It really doesn’t matter, as long as the Hyper-V host can reach the location. If it were me, I would also rename the VHDX copy to something that suits the VM.

Once you have the VHDX placed, use Hyper-V Manager to attach it to the virtual machine:

Once you hit OK, you can boot up the VM. It will start off like a newly-installed Windows machine, but all your customizations will be in place.

Deploying with Import

Importing saves you a bit of work in exchange for a bit of different but optional work.

We already have an article on importing (scroll down to the bottom 2/3 or so). I will only recap the most relevant portions.

First, choose the relevant source gold image:


Especially ensure that you choose to Copy. Either of the other choices will cause problems for the gold image.

Now, the fun parts. It will import with the name of the exported VM. That’s probably not what you want. You’ll need to:

  • Rename the virtual machine
  • Rename the VHDX(s)
    1. Detach the VHDX(s)
    2. Rename it/them
    3. Reattach it/them
  • You may need to rename the folder(s), depending on how you deployed. That hasn’t been a problem for me, so far.

Post-Deployment Work

At this point, you are mostly finished. The one thing to keep in mind: the guest operating system will have a generic name unrelated to the virtual machine’s name. Don’t forget to fix that. Also, IP addresses will not be retained, etc.

Further Work and Consideration

What I’ve shown you only takes you through some simplistic builds. You can really turn this into a powerhouse deployment system. Things to think about:

  • After you have a basic build, import it, customize it further and sysprep it again. Repeat as necessary.
  • Microsoft places limits on how many times an image can be sysprepped. Therefore, always try to work from the first image rather than from a deep child.
  • You can use the Mount-WindowsImage cmdlet family and DISM tools. Those allow you to patch and apply items to an image without decrementing the sysprep counter. For an example, I have a script that makes a VHDX into a client for a WSUS system.
  • You can mount a VHDX in Windows Explorer to move things into it.

Watch out for more articles that talk more about customizing your images. If you’re having trouble following any of the steps above, ping me a message in the comments below and I’ll help you out.

How to Perform Hyper-V Storage Migration

How to Perform Hyper-V Storage Migration

New servers? New SAN? Trying out hyper-convergence? Upgrading to Hyper-V 2016? Any number of conditions might prompt you to move your Hyper-V virtual machine’s storage to another location. Let’s look at the technologies that enable such moves.

An Overview of Hyper-V Migration Options

Hyper-V offers numerous migration options. Each has its own distinctive features. Unfortunately, we in the community often muck things up by using incorrect and confusing terminology. So, let’s briefly walk through the migration types that Hyper-V offers:

  • Quick migration: Cluster-based virtual machine migration that involves placing a virtual machine into a saved state, transferring ownership to another node in the same cluster, and resuming the virtual machine. A quick migration does not involve moving anything that most of us consider storage.
  • Live migration: Cluster-based virtual machine migration that involves transferring the active state of a running virtual machine to another node in the same cluster. A Live Migration does not involve moving anything that most of us consider storage.
  • Storage migration: Any technique that utilizes the Hyper-V management service to relocate any file-based component that belongs to a virtual machine. This article focuses on this migration type, so I won’t expand any of those thoughts in this list.
  • Shared Nothing Live Migration: Hyper-V migration technique between two hosts that does not involve clustering. It may or may not include a storage migration. The virtual machine might or might not be running. However, this migration type always includes ownership transfer from one host to another.

It Isn’t Called Storage Live Migration

I have always called this operation “Storage Live Migration”. I know lots of other authors call it “Storage Live Migration”. But, Microsoft does not call it “Storage Live Migration”. They just call it “Storage Migration”. The closest thing that I can find to “Storage Live Migration” in anything from Microsoft is a 2012 TechEd recording by Benjamin Armstrong. The title of that presentation includes the phrase “Live Storage Migration”, but I can’t determine if the “Live” just modifies “Storage Migration” or if Ben uses it as part of the technology name. I suppose I could listen to the entire hour and a half presentation, but I’m lazy. I’m sure that it’s a great presentation, if anyone wants to listen and report back.

Anyway, does it matter? I don’t really think so. I’m certainly not going to correct anyone that uses that phrase. However, the virtual machine does not necessarily need to be live. We use the same tools and commands to move a virtual machine’s storage whether it’s online or offline. So, “Storage Migration” will always be a correct term. “Storage Live Migration”, not so much. However, we use the term “Shared Nothing Live Migration” for virtual machines that are turned off, so we can’t claim any consistency.

What Can Be Moved with Hyper-V Storage Migration?

When we talk about virtual machine storage, most people think of the places where the guest operating system stores its data. That certainly comprises the physical bulk of virtual machine storage. However, it’s also only one bullet point on a list of multiple components that form a virtual machine.

Independently, you can move any of these virtual machine items:

  • The virtual machine’s core files (configuration in xml or .vmcx, .bin, .vsv, etc.)
  • The virtual machine’s checkpoints (essentially the same items as the preceding bullet point, but for the checkpoint(s) instead of the active virtual machine)
  • The virtual machine’s second-level paging file location. I have not tested to see if it will move a VM with active second-level paging files, but I have no reason to believe that it wouldn’t
  • Virtual hard disks attached to a virtual machine
  • ISO images attached to a virtual machine

We most commonly move all of these things together. Hyper-V doesn’t require that, though. Also, we can move all of these things in the same operation but distribute them to different destinations.

What Can’t Be Moved with Hyper-V Storage Migration?

In terms of storage, we can move everything related to a virtual machine. But, we can’t move the VM’s active, running state with Storage Migration. Storage Migration is commonly partnered with a Live Migration in the operation that we call “Shared Nothing Live Migration”. To avoid getting bogged down in implementation details that are more academic than practical, just understand one thing: when you pick the option to move the virtual machine’s storage, you are not changing which Hyper-V host owns and runs the virtual machine.

More importantly, you can’t use any Microsoft tool-based technique to separate a differencing disk from its parent. So, if you have an AVHDX (differencing disk created by the checkpointing mechanism) and you want to move it away from its source VHDX, Storage Migration will not do it. If you instruct Storage Migration to move the AVHDX, the entire disk chain goes along for the ride.

Uses for Hyper-V Storage Migration

Out of all the migration types, storage migration has the most applications and special conditions. For instance, Storage Migration is the only Hyper-V migration type that does not always require domain membership. Granted, the one exception to the domain membership rule won’t be very satisfying for people that insist on leaving their Hyper-V hosts in insecure workgroup mode, but I’m not here to please those people. I’m here to talk about the nuances of Storage Migration.

Local Relocation

Let’s start with the simplest usage: relocation of local VM storage. Some situations in this category:

  • You left VMs in the default “C:\ProgramData\Microsoft\Windows\Hyper-V” and/or “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks” locations and you don’t like it
  • You added new internal storage as a separate volume and want to re-distribute your VMs
  • You have storage speed tiers but no active management layer
  • You don’t like the way your VMs’ files are laid out
  • You want to defragment VM storage space. It’s a waste of time, but it works.

Network Relocation

With so many ways to do network storage, it’s nearly a given that we’ll all need to move a VHDX across ours at some point. Some situations:

  • You’re migrating from local storage to network storage
  • You’re replacing a SAN or NAS and need to relocate your VMs
  • You’ve expanded your network storage and want to redistribute your VMs

Most of the reasons listed under “Local Relocation” can also apply to network relocation.

Cluster Relocation

We can’t always build our clusters perfectly from the beginning. For the most part, a cluster’s relocation needs list will look like the local and network lists above. A few others:

  • Your cluster has new Cluster Shared Volumes that you want to expand into
  • Existing Cluster Shared Volumes do not have a data distribution that does not balance well. Remember that data access from a CSV owner node is slightly faster than from a non-owner node

The reasons matter less than the tools when you’re talking about clusters. You can’t use the same tools and techniques to move virtual machines that are protected by Failover Clustering under Hyper-V as you use for non-clustered VMs.

Turning the VM Off Makes a Difference for Storage Migration

You can perform a very simple experiment: perform a Storage Migration for a virtual machine while it’s on, then turn it off and migrate it back. The virtual machine will move much more quickly while it’s off. This behavior can be explained in one word: synchronization.

When the virtual machine is off, a Storage Migration is essentially a monitored file copy. The ability of the constituent parts to move bits from source to destination sets the pace of the move. When the virtual machine is on, all of the rules change. The migration is subjected to these constraints:

  • The virtual machine’s operating system must remain responsive
  • Writes must be properly captured
  • Reads must occur from the most appropriate source

Even if the guest operating does not experience much activity during the move, that condition cannot be taken as a constant. In other words, Hyper-V needs to be ready for it to start demanding lots of I/O at any time.

So, the Storage Migration of a running virtual machine will always take longer than the Storage Migration of a virtual machine in an off or saved state. You can choose the convenience of an online migration or the speed of an offline migration.

Note: You can usually change a virtual machine’s power state during a Storage Migration. It’s less likely to work if you are moving across hosts.

How to Perform Hyper-V Storage Migration with PowerShell

The nice thing about using PowerShell for Storage Migration: it works for all Storage Migration types. The bad thing about using PowerShell for Storage Migration: it can be difficult to get all of the pieces right.

The primary cmdlet to use is Move-VMStorage. If you will be performing a Shared Nothing Live Migration, you can also use Move-VM. The parts of Move-VM that pertain to storage match Move-VMStorage. Move-VM has uses, requirements, and limitations that don’t pertain to the topic of this article, so I won’t cover Move-VM here.

A Basic Storage Migration in PowerShell

Let’s start with an easy one. Use this when you just want all of a VM’s files to be in one place:

This will move the virtual machine named testvm so that all of its components reside under the C:\LocalVMs folder. That means:

  • The configuration files will be placed in C:\LocalVMs\Virtual Machines
  • The checkpoint files will be placed in C:\LocalVMs\Snapshots
  • The VHDXs will be placed in C:\LocalVMs\Virtual Hard Disks
  • Depending on your version, an UndoLog Configuration folder will be created if it doesn’t already exist. The folder is meant to contain Hyper-V Replica files. It may be created even for virtual machines that aren’t being replicated.

Complex Storage Migrations in PowerShell

For more complicated move scenarios, you won’t use the DestinationStoragePath parameter. You’ll use one or more of the individual component parameters. Choose from the following:

  • VirtualMachinePath: Where to place the VM’s configuration files.
  • SnapshotFilePath: Where to place the VM’s checkpoint files (again, NOT the AVHDXs!)
  • SmartPagingFilePath: Where to place the VM’s smart paging files
  • Vhds: An array of hash tables that indicate where to place individual VHD/X files.

Some notes on these items:

  • You are not required to use all of these parameters. If you do not specify a parameter, then its related component is left alone. Meaning, it doesn’t get moved at all.
  • If you’re trying to use this to get away from those auto-created Virtual Machines and Snapshots folders, it doesn’t work. They’ll always be created as sub-folders of whatever you type in.
  • It doesn’t auto-create a Virtual Hard Disks folder.
  • If you were curious whether or not you needed to specify those auto-created subfolders, the answer is: no. Move-VMStorage will always create them for you (unless they already exist).
  • The VHDs hash table is the hardest part of this whole thing. I’m usually a PowerShell-first kind of guy, but even I tend to go to the GUI for Storage Migrations.

The following will move all components except VHDs, which I’ll tackle in the next section:

Move-VMStorage’s Array of Hash Tables for VHDs

The three …FilePath parameters are easy: just specify the path. The Vhds parameter is tougher. It is one or more hash tables inside an array.

First, the hash tables. A hash table is a custom object that looks like an array, but each entry has a unique name. The hash tables that Vhds expects have a SourceFilePath entry and a DestinationFilePath entry. Each must be fully-qualified for a file. A hash table is contained like this: @{ }. The name of an entry and its value are joined with an =. Entries are separated by a ; So, if you want to move the VHDX named svtest.vhdx from \\svstore\VMs to C:\LocalVMs\testvm, you’d use this hash table:

Reading that, you might ask (quite logically): “Can I change the name of the VHDX file when I move it?” The answer: No, you cannot. So, why then do you need to enter the full name of the destination file? I don’t know!

Next, the arrays. An array is bounded by @( ). Its entries are separated by commas. So, to move two VHDXs, you would do something like this:

I broke that onto multiple lines for legibility. You can enter it all on one line. Note where I used parenthesis and where I used curly braces.

Tip: To move a single VHDX file, you don’t need to do the entire array notation. You can use the first example with Vhds.

A Practical Move-VMStorage Example with Vhds

If you’re looking at all that and wondering why you’d ever use PowerShell for such a thing, I have the perfect answer: scripting. Don’t do this by hand. Use it to move lots of VMs in one fell swoop. If you want to see a plain example of the Vhds parameter in action, the Get-Help examples show one. I’ve got a more practical script in mind.

The following would move all VMs on the host. All of their config, checkpoint, and second-level paging files will be placed on a share named “\\vmstore\slowstorage”. All of their VHDXs will be placed on a share named “\\vmstore\faststorage”. We will have PowerShell deal with the source paths and file names.

I used splatting for the parameters for two reasons: 1, legibility. 2, to handle VMs without any virtual hard disks.

How to Perform Hyper-V Storage Migration with Hyper-V Manager

Hyper-V Manager can only be used for non-clustered virtual machines. It utilizes a wizard format. To use it to move a virtual machine’s storage:

  1. Right-click on the virtual machine and click Move.
  2. Click Next on the introductory page.
  3. Change the selection to Move the virtual machine’s storage (the same storage options would be available if you moved the VM’s ownership, but that’s not part of this article)
  4. Choose how to perform the move. You can move everything to the same location, you can move everything to different locations, or you can move only the virtual hard disks.
  5. What screens you see next will depend on what you chose. We’ll cover each branch.

If you opt to move everything to one location, the wizard will show you this simple page:


If you choose the option to Move the virtual machine’s data to different locations, you will first see this screen:


For every item that you check, you will be given a separate screen where you indicate the desired location for that item. The wizard uses the same screen for these items as it does for the hard-disks only option. I’ll show its screen shot next.

If you choose Move only the virtual machine’s virtual hard disks, then you will be given a sequence of screens where you instruct it where to move the files. These are the same screens used for the individual components from the previous selection:


After you make your selections, you’ll be shown a summary screen where you can click Finish to perform the move:


How to Perform Hyper-V Storage Migration with Failover Cluster Manager

Failover Cluster Manager uses a slick single-screen interface to move storage for cluster virtual machines. To access it, simply right-click a virtual machine, hover over Move, and click Virtual Machine Storage. You’ll see the following screen:


If you just want to move the whole thing to one of the display Cluster Shared Volumes, just drag and drop it down to that CSV in the Cluster Storage heading at the lower left. You can drag and drop individual items or the entire VM. The Destination Folder Path will be populated accordingly.

As you can see in mine, I have all of the components except the VHD on an SMB share. I want to move the VHD to be with the rest. To get a share to show up, click the Add Share button. You’ll get this dialog:


The share will populate underneath the CSVs in the lower left. Now, I can drag and drop that file to the share. View the differences:


Once you have the dialog the way that you like it, click Start.

An Introduction to Hyper-V Server 2016

An Introduction to Hyper-V Server 2016


The Windows Server 2016 product family has been released, and with it, the free Hyper-V Server 2016 product. Now that we’ve had some time for the dust to settle and many thousands and thousands of words written about the new features, I’d like to take you through a more direct introduction to Microsoft’s free standalone hypervisor offering. This post is not about those new features; it’s about getting you up and running so you can start playing with them.

What is Distinct About “Hyper-V Server” as Opposed to Just “Hyper-V”?

The terms “Hyper-V” and “Hyper-V Server” are often treated interchangeably, which leads to some confusion. Microsoft has come up with some very creative code names for pre-release products, but any time you see a released Microsoft product with an interesting name, they either bought it from someone else or the gaming division came up with it. Let’s take a moment to distinguish these two terms.

  • Hyper-V: Hyper-V is the name for Microsoft’s type 1 hypervisor. You can distinguish it from everything else by one simple fact: Hyper-V does not ship on its own. It is always included in some other product. Its most applicable classification would be “feature”. “Component” might also work. You can find Hyper-V in:
    • Windows 10
    • Windows Server
    • Hyper-V Server
  • Hyper-V Server: Hyper-V Server is a stand-alone product directly downloadable from Microsoft. Apparently, its proper name is now “Microsoft Hyper-V Server” and not just “Hyper-V Server”. I’m willing to bet that doesn’t catch on. You are not required to make any purchases in order to use this product. Unless something changes from previous version, you’ll be allowed to freely upgrade to the next version as well. The Hyper-V Server product includes the Hyper-V feature.

What is Distinct About “Hyper-V Server” as Opposed to “Windows Server”?

Hyper-V Server and Windows Server are both complete products in their own right, but it wouldn’t be completely out of line to think of Hyper-V Server as “Windows Server Lite”. Everything in Hyper-V Server can be found in Windows Server, but the opposite is not true. Almost every single role and feature available in Hyper-V Server can be listed on a single screen.

Notable role and feature differences in Hyper-V Server:

  • Text-based shell. You can use CMD.EXE and PowerShell.
  • Graphical capability is nearly non-existent. It’s difficult to say precisely what will and what will not work, but here are some guidelines:
    • The Explorer renderer is not present. This means that there is no Windows Explorer, no Internet Explorer, and no way to operate Microsoft Management Console (MMC) snap-ins, among other things.
    • The Windows Presentation Framework components (WPF) are not present. No applications based on WPF will operate, which means Windows Store applications and a great many other modern apps.
    • The Windows Forms components (often abbreviated as WinForms) are present. That means that some WinForms-based applications will operate, but many depend upon components of Windows/Windows Server that are not present. Things that you can expect to work:
      • regedit.exe
      • notepad.exe
      • Installer packages based on the Windows Installer API
  • Only the most basic storage components are present. With the exception of Storage Spaces Direct, which requires Windows Server 2016 Datacenter Edition, none of the advanced storage components are supported on a system that is running Hyper-V anyway. However, some people might want to take the risk of running deduplication locally with Hyper-V. You must use Windows Server to do so.
  • Routing and Remote Access Services are not present in Hyper-V Server. If this functionality is desired, it should be run on another physical server or from within a guest anyway.
  • IIS is not available.
  • Failover Clustering and the Remote Desktop Virtualization Host features are both available.

One strong distinction is that Windows Server has a “Core” mode that is commonly confused with Hyper-V Server. Despite many confusing labels that you’ll find in a number of places, Hyper-V Server is just Hyper-V Server. “Core” is a term that belongs to Windows Server. It is a GUI-less mode that is otherwise identical. It has the same offerings of roles and features as Windows Server (except those that are specifically dependent upon the GUI, of course).

While this article is only going to briefly touch on the concept of licensing, remember that Microsoft’s licensing approach for Hyper-V’s management operating system is that it can only provide services that are directly related to Hyper-V. Any other role, feature, or application causes forfeiture of a guest Windows Server license. If you use Hyper-V Server and its available roles and features, there are only a handful of simple ways to violate that license. Basically, don’t try to turn your Hyper-V Server into a file server and you’ll almost certainly be all right.

How is Hyper-V Server Licensed?

Every Microsoft product that I’ve ever seen has an attached license of some kind, and Hyper-V Server is no exception. What makes it stand out among Microsoft’s line-up of server products is that they don’t ask you to pay for it. You can install and use Hyper-V Server in any environment at no charge. The fact that you download it from TechNet’s “Evaluation Center” and that the web page has “evaluation” in its title is just misleading. It’s a fully packaged product with no expiration, free for the taking.

That should be enough to leave this section and move on to the fun technical stuff, but I do need to address a myth that I still see in circulation. You may have been told that, if you run Windows Server as a guest operating system, you get a licensing benefit by installing Windows Server on the hardware instead of Hyper-V Server on the hardware. If you’ve been told that, you’ve been lied to (“lie” is kind of a strong word, admittedly). Any operating system that you use as a Hyper-V guest must be properly licensed. That has nothing to do with Hyper-V, though. Any operating system that you use as an ESXi guest must be properly licensed. Same with Xen. And XenServer. And VirtualBox. And KVM. And RHV. And whatever else. Use whatever management operating system makes you happy — licensing for the guests is a separate issue.

Meet Hyper-V Server

The very first thing I noticed about Hyper-V Server is that even the graphical logon UI is gone. Hyper-V Server 2012 R2 and prior all used the same logon screen as their Windows Server counterpart. Hyper-V Server now greets you like this:

Hyper-V Server 2016 Logon

Hyper-V Server 2016 Logon


Hyper-V Server 2016’s entire login process is text-based.

After logging in, things look similar to previous versions. You’ll have two cmd.exe windows, one with sconfig.cmd and another waiting for input in your profile directory.

Meet the New SCONFIG, Same as the Old SCONFIG. Mostly

If you’ve never used SCONFIG.CMD before, it’s the text-based menu driven system that many use to configure Windows Server Core and Hyper-V Server. This tool is very straightforward to use and I’m not going to spend much time on it in this article. It can help you to configure:

  • Computer Name and domain or workgroup membership
  • Local administrator accounts
  • Remote management firewall rules
  • Windows Update
  • Inbound Remote Desktop connections
  • IPv4 and IPv6 network settings
  • Date and time, including the time zone
  • Telemetry
  • Logging off, shutting down, and restarting the system

SCONFIG.CMD has not changed much from earlier versions:

Hyper-V Server 2016 sconfig Root Screen

Hyper-V Server 2016 sconfig Root Screen


The “new” entry here is 10) Telemetry settings. “Telemetry” is basically the current incarnation of the “Customer Experience Improvement Program”, except that it doesn’t have a “no, thank you” mode. Using this interface, you can only select how much data is transmitted to Microsoft, not disable it entirely. Selecting option 10 shows you the following screen:

Telemetry Information Dialog

Telemetry Information Dialog


The nice thing about this dialog is that it proves what I was telling you earlier: WinForms works in Hyper-V Server 2016. That’s probably not what you were thinking about when you saw this message, though. In a move that’s certain to have the conspiracy theorist spheres abuzz, the “For more information” link just drops you to the Microsoft home page. The privacy link works, though. Despite whatever oversight caused that broken link to be deployed into production products, Microsoft is not trying to hide information about the telemetry service from you. TechNet has an extremely thorough article on what it is, what it does, and how to configure it. For even more information on what’s sending data to Microsoft and how to get rid of them, TechNet has another thorough article. I haven’t found anything by any credible source that makes me worry about what Microsoft is collecting, but if it bothers you, a bit of research will show you how to disable Telemetry. All I’m going to leave you with on this topic is that all of the people that ran Windows Media Center disabled CEIP, and now we don’t have Windows Media Center anymore.

Configuring Hyper-V Server 2016

I cannot stress enough that you should find a way to automate your system configuration. If you’re in a small shop on a budget, try something like the script that I created. Effort in automation is never wasted.

That said, here are some functions to help you configure a new Hyper-V Server 2016 system. I am going to specifically avoid those things that are best done in SCONFIG.CMD, so go through that utility first.

Most of the things I’m going to show you are done in PowerShell. All you need to do is use the empty command prompt window and type powershell and press [Enter]. There’s no UAC in Hyper-V Server, so don’t worry about being “elevated”. You just need to have logged on as a local administrator (which includes domain accounts that have been placed into the local administrator group). I have a starter course article on PowerShell whose concepts you should be familiar with.

Working with Network Adapters

SCONFIG can set an IP address and DNS information for an adapter, but that’s the extent of its powers. NETSH is still around and is perfectly acceptable if you remember how to use it. PowerShell is the current game, though.

List all network adapters:

If you’ve got hardware that supports Consistent Device Naming, then you’ll get descriptive names for your adapters. Personally, I haven’t got that good hardware, and I can’t make much sense out of “Ethernet” and “Ethernet 1”. What I do is turn off ports on my physical switch until I’ve identified each of the adapters (Get-NetAdapter will show that the port is unplugged), then I use a text file to match the MAC addresses of each adapter, the name that I give it, and the IP addressing information for it:

IP Info Sample

IP Info Sample


I could very easily just throw all of that information into my DHCP system with a very long lease and manage it all with IPAM, but that takes all the fun out of things (actually, it doesn’t). One thing that I do is rename all of my adapters:

SCONFIG will set IPs, or you can use New-NetIPAddress.

Since I have multiple adapters and I don’t want any of my other systems to accidentally try to connect to one of my storage IPs, I disable DNS registration on all adapters except the primary:

Microsoft is now allowing us to get rid of the dreadful SMB 1.0/CIFS protocol. If you have any need of that on Hyper-V Server, something is wrong. Let’s kill it immediately:

Don’t forget about your virtual switch! New-VMSwitch will get you there. The -EnableEmbeddedTeaming switch will allow you to use the new switch-embedded teaming feature to combine your adapters into a team (switch independent mode only) and create a Hyper-V virtual switch on them in one cmdlet. For me, that’s:

For the record, the New-VMSwitch documentation STILL incorrectly says that the default QoS mode is “Weight”. After three versions of the documentation saying that, I’m starting to think that it’s just a joke.

Techniques for Installing Drivers on Windows Server 2016

Driver installation can sometimes be a chore, but you can figure out most problems if you pause for a bit to think about it. I have a Dell T20, and almost all of their installer packages require WPF if you use defaults. But, with a bit of effort, you can get most of them to work without a lot of drama. Getting the drivers to the server might be a bit of a challenge. I typically use a graphical station to download the files from the manufacturer and then place them on a common share. You can also burn them to an ISO or place them on a USB device.

If you have an .EXE from the manufacturer, the very first thing I would do is just try to run it and see if it works. If it doesn’t, the next thing that I do is try running the installer with the /? switch to see if it has alternatives, such as extraction or silent installation methods. If that doesn’t work, I go looking for raw driver files that aren’t part of an installer. So far, I believe that I’ve found solutions for everything.

Let’s look at an example. I have a Dell T20. The first thing that I needed to do was find drivers for that model. Want to do it by service tag but don’t want to digging? Ask PowerShell:

The “SerialNumber” field has your service tag.

I’ve got my files now, and I want to install the Intel chipset drivers, which are packaged in a file named “Chipset_Driver_TTVVT_WN_9.4.0.1027_A03.EXE”. When I ran that file directly, I got an error about missing Windows components. So, that’s not going to work. But, I think ran it with the /? switch and discovered that it has a few options, like silent install. I don’t like silent installs much, so I went for the extraction technique first:

That’s all it took, and I had extracted the Intel contents of the Dell driver package. Unlike Dell, Intel relies on fairly basic Windows Installer packages that will work just about anywhere:

Intel Installer

Intel Installer


The NIC drivers were a bit more interesting. I extended the T20 with some extra Intel NICs that are older, so the drivers from Dell aren’t going to cover them. After some digging, I determined that my best option was to just use the Intel CD, because it will install drivers for all of my adapters in one shot. The problem? They’re in a ZIP file. No problem for PowerShell in Hyper-V Server 2016:

Another problem easily solved:

Intel Network Installer in Hyper-V Server 2016

Intel Network Installer in Hyper-V Server 2016


The final place that you might find yourself is with the need to install from an .inf file because you can’t find a suitable installer. I did not have that problem with the T20 so I haven’t got any direct examples. However, the basic format is very simple (and you can do it from the standard command line instead of PowerShell, if you prefer):

What’s nice about PNPUTIL is that it works in a remote PowerShell session. I have installed updated network driver files that way. I lost connection, of course, but it then reconnected once the drivers were installed.

Device Manager does not work on Hyper-V Server 2016 or Windows Server 2016 Core. You can list installed drivers with pnputil -e .

Managing Hyper-V Server 2016

A very common complaint is that, out-of-the-box, Hyper-V Server is difficult to manage. There are two ways to look at this. One is that the complaint is correct. There are other freely-available hypervisors that ship with basic graphical interfaces, and if that’s your metric for “easy to manage”, then Hyper-V Server is not easy to manage.

The other way to look at it is that the complaint misses the point. I’ve said it before and I’ll say it again: Microsoft does not understand the small business very well and they did not build Hyper-V Server for the small business. In their minds, Hyper-V Server is just one cog in a larger cloud infrastructure. You deploy it with automated tools, you configure it with pre-defined scripts and automated systems, and you manage it from a remote system. It is entirely possible to have fully-functional Hyper-V Server systems that operate perfectly from cradle to grave without any human ever logging on locally. Why would anyone build a user-friendly interface for something like that?

But, I imagine that if you fielded the complaint, you haven’t got the budget or the expertise for that sort of environment. Just because Hyper-V Server is a free tool does not mean that it is intended for people that don’t have much money to spend. Smaller businesses are expected to use the graphical version of Windows Server because they have relaxed density requirements so GUI overhead is trivial, they are probably using internal storage so a larger disk footprint is trivial, and their security concerns are probably greater elsewhere. Windows Server is Hyper-V’s graphical interface. The differentiation is that its management environment is not free, not that it isn’t easy to use. Usability issues with the graphical tools are a topic for another article (or ten).

So, if you really want to manage Hyper-V Server locally, then you need to be prepared to do sysops like a professional. That means learning to navigate the native command shell and PowerShell. If you have these skills, then Hyper-V Server is not difficult to manage. I don’t think that having these skills is too much to ask, either. I’m still baffled by the existence of people that say they want to be systems administrators but don’t want to learn these things. That, to me, is like a surgeon that doesn’t want to see blood or a structural engineer that doesn’t want to do math. These attitudes are a sign that you selected the wrong career field.

Of course, there’s no requirement to manage Hyper-V Server locally. I am a big fan of using a single management computer that has all of the necessary tools installed. Here’s a Windows Server 2016 connected to and managing my Hyper-V Server 2016 installation:

Remote Connections to Hyper-V Server 2016

Remote Connections to Hyper-V Server 2016


I don’t even do PowerShell locally on Hyper-V Server. Hyper-V Server is intended to run “headless”, so that should be your goal.

Get Started!

That’s enough to create a fully functional Hyper-V Server deployment that’s ready to start running virtual machines. New-VM is one way to create them, but you’ll probably like your results better if you operate from a remote system with Hyper-V Manager. This article can help you get that connection made. Its contents aren’t for 2016 specifically, but 2016 is actually a bit easier than those older versions so you shouldn’t have any troubles.

Hyper-V Live Migration methods in 2012 and 2012 R2 VMs

Hyper-V Live Migration methods in 2012 and 2012 R2 VMs

The purpose of this article is to demonstrate the various methods for performing Live Migrations in Hyper-V. You can check out our previous article that provides a step by step guide to how Hyper-V Live Migration works, or you can check out our troubleshooting guide to Hyper-V Live Migration in case you ran into any errors.

What is Live Migration?

Live Migration is the name of Hyper-V’s technology that moves virtual machines between physical hosts without service interruption. This feature appears in multiple forms:

  • Live Migration: While often used as an umbrella term, the most precise meaning for these two words is the transfer of ownership of a clustered virtual machine from one node to another node within the same cluster.
  • Storage Live Migration: A Storage Live Migration transfers one or more of a virtual machine’s constituent files from one location to another without interrupting service to the owning virtual machine. A Storage Live Migration might or might not occur in conjunction with a Live Migration.
  • Shared Nothing Live Migration: A Shared Nothing Live Migration is similar to a standard Live Migration in that it transfers a virtual machine from one host to another without interruption, but the primary difference is that the virtual machine cannot be clustered. The most common utilization for a Shared Nothing Live Migration is moving a virtual machine from one standalone host to another. However, it is possible to transfer from a node that is a cluster member, provided that the virtual machine is not a cluster role at the time of transfer. Shared Nothing Live Migration typically occurs in conjunction with a Storage Live Migration, but it is not necessary if the virtual machine’s files are on an SMB 3 share accessible by both the source and target physical hosts.

What is Quick Migration?

Quick Migration is an earlier technology that moved virtual machines between cluster nodes but does cause a brief service interruption. Live Migration is preferred for running virtual machines, but because the active state of the virtual machine is saved to disk instead of transferred and actively synchronized over the network, Quick Migration usually enjoys a noticeably lower total operation time. Quick Migration is the only way for non-running virtual machines to be transferred.

PowerShell vs. GUI Methods

This article will demonstrate both PowerShell and GUI methods (via Hyper-V Manager and Failover Cluster Manager). While I normally make it a point to encourage everyone to learn and use PowerShell whenever possible, I make no particular preference on Quick and Live Migrations. I recommend that you at least learn how the PowerShell techniques work, especially if you are considering building any automated solutions. For day-to-day operations, the GUI is easier. I’ll show you the PowerShell techniques first with the GUI methods following.

Quick Migrations in PowerShell

PowerShell can easily move virtual machines:

If you do not specify –Node, the cluster decides where to place the virtual machine(s).

To move multiple virtual machine simultaneously, you can use this cmdlet in a loop or pipe in output from Get-VM.

Live Migrations in PowerShell

The PowerShell syntax for Live Migrations is even easier than Quick Migrations:

If you do not specify –Node, the cluster decides where to place the virtual machine(s).

To move multiple virtual machine simultaneously, you can use this cmdlet in a loop or pipe in output from Get-VM.

For Live Migrations, you can also use Move-VM:

Move-VM will fail if the virtual machine is not on and it requires a destination host to be specified. If not run from the source host, it will also fail if delegation is not enabled. See the Troubleshooting section.

Storage Live Migrations Using PowerShell

Another capability of the Move-VM cmdlet is relocation of a virtual machine’s storage. That usage is probably better explained by its relation to Shared Nothing Live Migration, so that section will explain it further. However, there is a cmdlet just for Storage Live Migration: Move-VMStorage. This cmdlet has quite a few options, not all of which will be discussed here. Use Get-Help to see the full list or read the related page on TechNet. The cmdlet does have four separate parameter sets, but there are only two major variants. Your major decision is whether you want to move all of the VMs files to the same location or if you want to specify locations for individual components. You can make either of these moves by specifying the VM by its name or by using its VM object (as in, from Get-VM). The examples shown here only specify the virtual machine by its name.

Using Move-VMStorage to Relocate All of VM’s Files to a Single Location

Using a single location is the easiest:

The above example moves all of the files for the virtual machine named “svtest” to the G:\ drive. In this case, that is a Cluster Disk (not a CSV) that has been specifically assigned to the virtual machine svtest. This usage results in the following:

  • If a folder named Snapshots does not exist on G:, it will be created. Any VM configuration files that belong to an existing checkpoint for the VM will be placed there.
  • If a folder named Virtual Hard Disks does not exist on G:, it will be created. Any virtual hard disks attached to the VM will be placed there.
  • If a folder named Virtual Machines does not exist on G:, it will be created. The VM’s XML description file will be placed in it. A subfolder named with the virtual machine’s ID will be created. The VM’s BIN and VSV will be placed there.

Using Move-VMStorage to Separate a VM’s Files

Multiple locations can be somewhat complicated because the VHD/X files need to be in an array of hash tables. Each hash table in this array needs to be in the format of: @{‘SourceFilePath’ = ‘G:\Virtual Hard Disks\svtest.vhdx’; ‘DestinationFilePath’ = ‘C:\ClusterStorage\CSV1\Virtual Hard Disks\svtest.vhdx’}. The locations and VHDX files are specific to my installation, of course, but the “SourceFilePath” and “DestinationFilePath” key names are required. Notice the  @{}  wrapper; this is what makes this a hash table. Every VHD/X set that you’re going to move needs to be placed inside one of these, and then all of those (even if it’s only one), needs to be placed inside a standard PowerShell array. The wrapper for that is @(). Separate VHDX hash tables inside the array with commas. An example of such an array of hash tables:

A more complete example:

Notice that I used neither the SnapshotFilePath nor the SmartPagingFilePath parameter. Whereas the Failover Cluster Manager tool will leave any files that you did not specifically instruct it to move in their original location, the cmdlet the way that I have issued it will move all unspecified components to the same location as the VirtualMachinePath parameter, if it is specified.

Preparing a Clustered Virtual Machine for a Shared Nothing Live Migration Using PowerShell

Before you can move a clustered virtual machine, you must remove it from its cluster. This operation does not cause downtime for the virtual machine, but it may cause issues for other applications. For instance, System Center Virtual Machine Manager will mark any virtual machine on a Cluster Shared Volume that isn’t clustered as “unsupported configuration” and will refuse to allow you to manipulate it within that console. Also, running a non-clustered virtual machine on a cluster member’s shared storage (besides SMB 3) can have other undesirable effects if any failures should occur, so do not perform these steps until you are ready to start the Shared Nothing Live Migration.

To prepare a clustered virtual machine for Shared Nothing Live Migration using PowerShell:

Note 1: The name of the virtual machine’s cluster group does not always match its cluster group name. This is especially likely to be true if you created the virtual machine using System Center Virtual Machine Manager. You can use Get-ClusterGroup to view all clustered roles.

Note 2: Remove-VMFromCluster is an alias for Remove-ClusterGroup.

Shared Nothing Live Migration Using PowerShell

Shared Nothing Live Migration is enabled by using Move-VM. It works almost exactly like Move-VMStorage, but adds a DestinationHost parameter. In fact, everything you learned from Move-VMStorage above (in the Storage Live Migrations Using PowerShell section) applies to Move-VM.


Performing a Quick Migration in Failover Cluster Manager

Failover Cluster Manager is the only native GUI tool that can perform a Quick Migration.

  1. Switch to the Roles tree node.
  2. To move multiple VMs, use CTRL+Click to select them.
  3. Right-click the VM(s) to be moved.
  4. In the context menu, go to Move and Quick Migration.
    1. To allow the cluster to select the destination, click Best Possible Node.
    2. To manually choose the destination, click Select Node… This will cause a dialog to appear with all cluster nodes displayed. Double-click one or highlight it and click OK.
Quick Migration in Failover Cluster Manager

Quick Migration in Failover Cluster Manager


Performing Live Migrations in Failover Cluster Manager

As with Quick Migrations, Failover Cluster Manager is the only native GUI tool that can perform a Quick Migration.

  1. Switch to the Roles tree node.
  2. To move multiple VMs, use CTRL+Click to select them.
  3. Right-click the VM(s) to be moved.
  4. In the context menu, go to Move and Live Migration.
    1. To allow the cluster to select the destination, click Best Possible Node.
    2. To manually choose the destination, click Select Node… This will cause a dialog to appear with all cluster nodes displayed. Double-click one or highlight it and click OK.
Live Migration Example

Live Migration Example


If you have selected more virtual machines than can be migrated at once, the cluster will choose the maximum number and begin moving them. The rest will show a status of Migration queued.

Performing a Storage Live Migration

A Storage Live Migration can be performed for non-clustered virtual machines using Hyper-V Manager. Only Failover Cluster Manager can handle them for clustered virtual machines.

Storage Live Migrations in Hyper-V Manager

For non-clustered virtual machines:

  1. Right-click on the virtual machine in the list and select Move…
  2. The Move Wizard will open. The first screen is informational. Click Next when ready.
  3. On the Choose Move Type screen, choose Move the virtual machine’s storage and click Next.
    Storage Live Migration Selection

    Storage Live Migration Selection


  4. Now, you’ll need to make a generic choice of what you want to move. There are three options:
    1. Move all of the virtual machine’s data to the same location. This will place all of the virtual machine’s files except its VHD/Xs in a ‘Virtual Machines’ folder at the target location. All of the hard disks will be placed in a ‘Virtual Hard Disks’ subfolder.
    2. Move the virtual machine’s data to different locations. You’ll be prompted for the location of each component. This is the only option we’ll go through in this walk-through as it is a superset of the other two.
    3. Move only the virtual machine’s hard disks. This will skip the component section and have you pick which VHD/X files to move and where to put them.
      Move Options

      Move Options


  5. After that, you’ll make more specific decisions about what to move. If you picked the first option in step 4, you’ll just have a single target location. Otherwise, you’ll have the screen as shown in the following screen shot. Whether or not the components are visible depends on whether you chose the second or third option in step 4. Uncheck anything that you want to leave behind.
    Move Components

    Move Components


  6. You will now progress through a series of screens that ask you where to place each individual item. How many of these screens you see depends on your selections in steps 4 and 5. Each looks similar to the following, and you will not be allowed to proceed until you have selected a suitable destination for the current item. When the wizard validates the target location, it will fill in the Available space field. If you’re manually typing, it attempts to validate the storage location after each letter, so results are immediate.
    Destination Path Selection

    Destination Path Selection


  7. Once you have made all of your selections, you will be presented with a summary screen. If all of your selections are correct, click Finish to start the move.

Storage Live Migrations in Failover Cluster Manager

Failover Cluster Manager is the tool to use for clustered virtual machines.

  1. Switch to the Roles tree node.
  2. To move multiple VMs, use CTRL+Click to select them.
  3. Right-click the VM(s) to be moved.
  4. In the context menu, go to Move and Virtual Machine Storage.
    Starting Failover Cluster Storage Live Migration

    Starting Failover Cluster Storage Live Migration


  5. The Move Virtual Machine Storage dialog will open. Select destination(s) for the virtual machine’s files and click Start to begin the move. This dialog and its components are explained below.

The Storage Live Migration window has quite a few pieces to give you fine-grained control over the placement of your virtual machine’s files. The following is an index that matches with the numbers I’ve super-imposed on the screenshot:

Failover Cluster Manager Storage Live Migration Window

Failover Cluster Manager Storage Live Migration Window


Legend for the Preceding Screenshot

  1. In the first column, you’ll find the virtual machine(s) that you selected to move. In this screenshot, I’ve expanded the virtual machine, which shows its constituent components. If I had selected other virtual machines to move, they would be listed below this one.
  2. This column shows you where the components of the virtual machine currently are.
  3. The Destination Folder Path is initially empty. As you select target locations, they will be indicated here.
  4. The box at the lower left shows valid destinations. Initially, only Cluster Shared Volumes will be visible. If a Cluster Disk has been assigned directly to a selected virtual machine, that will appear as well. You can expand any of the items here to show their subfolders. You can drag-drop any item from the top to any location that appears here. Alternatively, you can highlight an object in the top and click the Copy button (near the number 1 in the screenshot) and then use the Paste button (above and to the left of the number 6 in the screenshot) to set that as the item’s target location.
  5. The Add Share button shows a small dialog that allows you to manually type the name of a share. If it is reachable, it will then appear in the bottom left box under a Shares tree. It can then be used as described in number 4.
  6. Items in the lower-right box in black font are components that will be moved into the currently highlighted location on the left. Items in gray font are components that are already present. This output can be a little confusing because only VHD/X files are named. Items such as Checkpoints and Current configuration do not indicate which virtual machine they are for. Take caution when moving virtual machines simultaneously and be mindful of the contents of the third column. If an item in black font is highlighted, the Delete button (above the number 6 in the screenshot) will remove its current move target (meaning that it will be left where it is when the move is started).

One of Storage Live Migration’s powers is that the virtual machine doesn’t need to have all of its components in a single place. This window allows you to design the precise layout of its constituent files. However, remember that:

  • The Checkpoints location does not affect AVHD/X files. Those will always be placed in the same location as their parent VHD/X files.
  • If a Virtual Machines folder does not exist at the designated target location for Current configuration and Smart Paging, it will be created.
  • If a Snapshots folder does not exist at the designated target location for Checkpoints, it will be created.
  • Virtual disk files will be placed exactly where they are targeted without creation of any subfolders.
  • The source folder structure will not be altered.

Preparing a Clustered Virtual Machine for a Shared Nothing Live Migration

Before you can move a clustered virtual machine, you must remove it from its cluster. This operation does not cause downtime for the virtual machine, but it may cause issues for other applications. For instance, System Center Virtual Machine Manager will mark any virtual machine on a Cluster Shared Volume that isn’t clustered as “unsupported configuration” and will refuse to allow you to manipulate it within that console. Also, running a non-clustered virtual machine on a cluster member’s shared storage (besides SMB 3) can have other undesirable effects if any failures should occur, so do not perform these steps until you are ready to start the Shared Nothing Live Migration.

To prepare a clustered virtual machine for Shared Nothing Live Migration using Failover Cluster Manager, right-click on the virtual machine in the Roles section and click Remove. You’ll be prompted to remove its cluster resources. The virtual machine is not affected, only its status within the cluster.

Shared Nothing Live Migration in Hyper-V Manager

The only freely-provided GUI tool from Microsoft that can perform a Shared Nothing Live Migration is Hyper-V Manager. The process is similar to that of a Storage Live Migration, so you’ll likely notice some similarities between the two processes.

  1. Right-click on the virtual machine in the list and select Move…
  2. The Move Wizard will open. The first screen is informational. Click Next when ready.
  3. On the Choose Move Type screen, leave Move the virtual machine selected and click Next.
    Move Type

    Move Type


  4. Choose the host that you wish to migrate the virtual machine to. You can type it in or Browse to it. Click Next.
    Destination Host

    Destination Host


  5. The Move Options dialog deals with the general placement of the virtual machine’s components.
    1. Move the virtual machine’s data to a single location. If you choose this option, the next window will ask you for the location to place the virtual machine files. The VHD/X files will be placed in a ‘Virtual Hard Disks’ subfolder of that location. All others will be placed in a ‘Virtual Machines’ subfolder. The Browse button operates from the perspective of the VMMS service on the target machine.
    2. Move the virtual machine’s data by selecting where to move the items. This option will cause a series of dialogs to be generated that will ask about each component separately. This is the only option that will be further explored in this walkthrough.
    3. Move only the virtual machine. If you choose this option, you will not be given any options for file placement. The wizard will attempt to swap the XML file registration from the source to the destination without making any other changes, just as it does with a cluster Live Migration. This can only work if the files are in an SMB 3 share opened to both the source and destination hosts or if they are in a Cluster Shared Volumes and both hosts are members of the same cluster.
      Move Options

      Move Options


  6. If you chose the second option in step 5, you’ll be presented with a dialog that further inquires how you wish to distribute the virtual machine’s data on the target host. It has three options.
    1. Move the virtual machine’s data automatically. The first option is the simplest. It will place the files in the same folder structure that they use on the source host.
    2. Move the virtual machine’s virtual hard disks to different locations. This choice is almost identical to the third option, except that it only deals with virtual hard disk files.
    3. Move the virtual machine’s items to different locations. If you choose this option, you’ll be presented with a series of dialogs that ask you to place each individual component, including the virtual hard disks.
      Advanced Move Options

      Advanced Move Options


  7. If you chose the third option in step 6, you’ll be presented with a dialog asking which of the components you wish to move. If you chose the second option, you’ll get the same dialog but it will only contain the VHD/X files. For a Shared Nothing Live Migration to succeed, all of the source files must either be moved or be in a location that both hosts can reach.
    Move Components

    Move Components


  8. If you made any choices in previous steps that involve moving items, you will now progress through a series of screens that ask you where to place each individual piece. How many of these screens you see depends on your earlier selections. Each looks similar to the following, and you will not be allowed to proceed until you have selected a suitable destination for the current item. When the wizard validates the target location, it will fill in the Available space field. If you’re manually typing, it attempts to validate the storage location after each letter, so results are immediate. Because you’re moving to a different host, all of these destinations are taken from the perspective of that host.
    Destination Path Selection

    Destination Path Selection


  9. Finally, you will be presented with a summary screen. If all looks well, press Finish to begin the transfer.
  10. If necessary, re-cluster the virtual machine with the Configure Role wizard in Failover Cluster Manager or with the Add-ClusterVirtualMachineRole cmdlet.

If all goes well, the files will be removed from the source location upon completion. Sometimes, these files are left behind even on success. Source folder structures will not be modified.

Network Ports Related to Hyper-V

Network Ports Related to Hyper-V


I firmly believe that Hyper-V is best implemented using Hyper-V Server and remote management techniques. Set it up once and never connect to its console again. With a bit of creativity, you can even deploy vendor-supplied firmware updates without accessing a local session. My approach does not enjoy community consensus; in fact, I’m unaware of any general agreement on the matter at all. One thing I do know for certain is that humans follow the path of least resistance. If option A is more difficult than option B, almost everyone will follow option B. Even people that take the hard road a few times at first will eventually fall back to the easy route, especially in times of distress.

With all of that said, I also firmly believe that digital security needs to be taken seriously. You may be in a low-security environment that doesn’t handle any sensitive information, but there is still a basic level of expected due diligence. Attackers are sometimes out to steal storage space and network bandwidth, not information. You have a responsibility to at least attempt to prevent that from happening. Even if you don’t feel like you owe to your current employer for whatever reason, you might want to work somewhere else someday. No prospective employer will be impressed if you have developed poor security habits.  Good security practice involves firewalls. Yes, they’re annoying when they inhibit legitimate traffic, but they are a simple and effective way to stop the most common assaults.

This article has two purposes. The first is to succinctly lay out the TCP/IP network ports information for Hyper-V management and activities. This allows you to configure firewalls as necessary. The second is to help you through some configuration dos and don’ts. This article might have information that helps you connect to workgroup-joined Hyper-V host, but it was not written with that usage in mind. I have not heard any compelling reason for that configuration to exist, therefore, I will not waste any further energy enabling it.

Inbound Hyper-V-Related TCP/IP Ports

The rules table below is used on 2012 R2 and should also apply to 2012. Every firewall configuration is a bit different. The following diagram gives a generalized idea of where you’ll be working:

Location of Firewall Rules

Location of Firewall Rules

Hyper-V Host Inbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP; CNO Management servers and stations; RDS broker Server Manager and other tools that use Remote Procedure Call
80 Management IP Other Hyper-V hosts that can replicate to this host Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Management IP Other Hyper-V hosts that can replicate to this host; VMM servers Hyper-V Replica (only if using secure traffic) and System Center VMM
445 Management IP and Cluster IPs; Live Migration IPs if using SMB mode Management servers and stations that would copy files to this host; members of the same cluster; Live Migration sources if using SMB mode; RDS broker Inbound file copy; cluster communications; Cluster Shared Volumes redirected access; Live Migration if using SMB mode
2179 Management IP; CNO Management servers and stations; RDS broker Communication to Virtual Machine Management Service
TCP & UDP 3389 Management IP Management stations Console access
5985 Management IP Management servers and stations; RDS broker WSMan and WMI; notably used by PowerShell Remoting
5986 Management IP Management servers and stations; SCVMM Secure WSMan and WMI
6600 Live Migration IPs Other Hyper-V hosts that can Live Migrate to this host Live Migration when using standard TCP or compressed TCP modes

The above table should be mostly self-explanatory. There are a handful of notes:

  • You probably don’t need to open all dynamic ports. I’ve only seen the first five or six ever actually being used. The problem is, if Microsoft has documented the true range of used ports anywhere, I have never found it. I only stumbled on the necessity to open the ports at all via netstat and Wireshark traces from failing connections. PSS didn’t even know about them.
  • For the best outcomes, do not use any firewalls at all on cluster-only networks. The above will work, but (unscientifically), the Wireshark traces I’ve seen on cluster networks suggest that it uses other undocumented methods for communications that are likely more efficient. This would not apply to cluster-and-client networks such as the management network. Keep all of your cluster-only networks in the same layer-2 network with no routers, preferably in a VLAN or otherwise isolated network.
  • “CNO” is cluster name object. Server Manager in particular wants to be able to talk to it. In reality, it maps directly to the management IP of the host that currently maintains the cluster core resources and as long as Server Manager can reach that, everything will be fine even if Server Manager is displeased. If you can ignore Server Manager’s complaints, so can I.
  • “RDS” is “Remote Desktop Services”. I hope the clarification isn’t necessary, but this is for virtual machine RDS and not session-based RDS.
  • Very few things have any need to use 5986 because WSMan traffic is always encrypted. Your host will only be listening on 5986 if you enable secure WSMan with a specially configured WinRM listener.

Outbound Hyper-V-Related TCP/IP Ports

Most institutions won’t block traffic outbound. However, you might need to use it to configure the inbound firewalls on other hosts. It’s also helpful if you have interim hardware firewalls. The rules are presented from the perspective of the following diagram:

Hyper-V-Related Outbound Firewall Rules

Hyper-V-Related Outbound Firewall Rules

Hyper-V Host Outbound Rules
Port Target Source Purpose
All dynamic ports (49152-65535) Management IP of other Hyper-V hosts; RDS broker Management IP Server Manager and other tools that use Remote Procedure Call if you will manage one host from another; RDS broker if using RDS
80 Other Hyper-V hosts that this host will replicate to Management IP Hyper-V Replica (only if using insecure traffic)
135 Management IP Management servers and stations; RDS broker RPC Endpoint Mapper (sometimes for WMI as well)
443 Other Hyper-V hosts that this host will replicate to; SCVMM Management IP Hyper-V Replica (only if using secure traffic) and System Center VMM
445 SMB 3 systems that present VM storage to this host; SMB 2+ targets with files this host needs to access, such as ISO; SCVMM library hosts; Live Migration target hosts if using SMB; other members of the same cluster; RDS broker Management IPs; cluster network IPs; RDS User Profile Disk share File copy; SMB access; Live Migrations in SMB mode; cluster communications; Cluster Shared Volume communications; RDS UPD host
3260 iSCSI Portals and Targets iSCSI discovery and initiator IPs iSCSI
6600 Other hosts this machine can Live Migrate to Live Migration IPs Live Migration when using standard TCP or compressed TCP modes

There isn’t much else to say with this table.

Other Hyper-V Related Traffic

Since I included port information for RDS, I might as well round it out with port information for RDS that doesn’t involve the hosts themselves. I’ll also include additional port information for System Center Virtual Machine Manager. While I’m at it, I’ll throw in some common ports just for the sake of completeness. I think the source/destination fields should be enough to help you figure out where to place these rules.

Other Hyper-V Firewall Rules
Port Target Source Purpose
All dynamic ports (49152-65535) All RDS hosts besides RDS broker RDS broker Server Manager and other tools that use Remote Procedure Call — the RDS broker is a central management hub
TCP/UDP 53 DNS servers Everyone DNS lookups
80 RDS Clients RDS web VDI’s web access is a standard IIS site
389 Domain Controllers Domain members Standard AD authentication
443 RDS Clients RDS web VDI’s web access is a standard IIS site
443 RDS Gateway RDS Clients Client-to-gateway connections handled via 443
443 RDS virtual machines RDS Clients If gateway is not used, clients authenticate directly to their own VMs on 443
686 Domain Controllers Domain members AD authentication using LDAPS; secure authentication is now also available on the 389 port
3389 RDS virtual machines in unmanaged pools RDS Broker Client-to-VM connectivity
3389 RDS Broker RDS Gateway Gateway facilitating of client-to-VM connectivity
3389 RDS virtual machines RDS Clients If an RDS gateway is not used, everyone is connected directly to his or her VDI virtual machine
UDP 3391 Same rules as 3389 Same rules as 3389 When this transport is enabled, higher-performing UDP is used for the connection. Duplicate all of the port 3389 rules to UDP 3391.
5504 RDS Broker RDS Web Hand-off from web authenticator to the RDS broker
5985 RDS Gateway RDS Broker RDS Broker control of RDS Gateway
8100 SCVMM Management stations Connect VMM console to VMM server service
8530 (default) Windows Server Update Services hosts All Windows/Windows Server/Hyper-v Server Windows Updates; may be configured to use another port

A few notes here:

  • I didn’t include all of the VMM rules. A more comprehensive list is available on the TechNet wiki. My real complaint with that list is that it does not include source/destination information and not all of the rules are obvious. For instance, you do need the Hyper-V hosts to be able to talk to the SCVMM server on port 443.
  • There is a similar TechNet wiki article for Remote Desktop Services, but the parts that aren’t difficult to sort out are just wrong and its overall state is such that, in good conscience, I cannot link it. Through some indirect channels, I have been left with the impression that the RDS team’s opinion on ever making that page useful or correct is “that’s not our job”. I have created the entries on these lists through Wireshark traces and observed trial and error. I can say that they have all worked just fine for me, but you might need to do some sleuthing of your own if you are doing some sort of configuration that I am not. PSS only has access to the same broken list so they will not be able to help you further, unless you don’t know how to use network traces or netstat to locate blocked ports.


Building a Better VMM: 8 Ideas

Building a Better VMM: 8 Ideas

One day, I was out traversing the wide, untamed world of my Twitter feed when I came across this most lovely post by Aidan Finn that does a great job summarizing Hyper-V’s Biggest Weakness. That post is required reading for this one. Actually, that post should be required reading for anyone that has anything to do with Hyper-V. Start there, then come back here.

Aidan’s post is about the state of management tools for Hyper-V in general. I’m going to focus on System Center Virtual Machine Manager (VMM). Even if you don’t use VMM, this article is for you. If you have Hyper-V but not VMM, then that is something that Microsoft seriously needs to address whether you (or they) realize it or not.

I believe that there should be a set of free tools with a premium management pack. The free tools should be enough for anyone to get by with minimal stress and the premium tool should not be required but it should provide a value-add that exceeds its price point. It should also either be a plug-in to the free tools or it should be able to do everything that they do so that a premium user doesn’t need to flip between tools. As these products stand today, none of those things are true. That’s part of the reason so many people aren’t using VMM. What I really want to focus on is the problems in the VMM product.

As I was reading that part of Aidan’s post and several of the comments, my central thought was, “I’m not alone.” Using VMM is a fairly miserable experience for me as well and one that I avoid as much as possible. It seems that each time I do break down and open the application because there’s something that I need that only it can do, I discover some error condition that poses absolutely no problem for my Hyper-V environment but has VMM in a total panic. I then have to spend time, usually hours, correcting that before I can do what it was that I needed to start VMM for in the first place. The program is extremely brittle, which isn’t a good label at all for an infrastructure management component.

If you look at the bottom of Aidan’s article, he links to a site where you can go to provide feedback to the relevant Microsoft team. That’s something I think you should do. Of course, it’s something I think that I should do as well. But as I sat there in front of those feedback blanks, I suddenly had a hard time articulating exactly what I wanted to say. That’s what happens when you hit your maximum frustration point with something. So, the purpose of this article is to lay out some of the things I see that are wrong with VMM and some of my suggestions, and hopefully that will get more community ideas flowing.

As a side note, there really is a benefit in speaking up. I hear a common complaint that Microsoft doesn’t listen to its customers. The truth is, they do. They just may not have listened to that one complaint that you had (I’m still pretty bitter over losing TechNet subscriptions and am not going to get over it any time soon) and they may not be listening in the places where you’re speaking. Use the feedback forms. Sign up for a research panel. Do not go out to some random Internet forum and stir up a bunch of drama. Whatever you do, be an adult about it. There is no one — repeat, no one — that looks at a post littered with “M$” and “Microshaft” and “Winblows” and “Windoze” et al and thinks, “Wow, that is a deep, insightful, carefully crafted commentary that has influenced the way I view things and will surely foster a great deal of admiring respect for the author.” What the few people who don’t roll their eyes and keep scrolling really think is, “Oh boy, yet another immature person that should never have been allowed off the schoolyard, much less into a professional datacenter, that thinks they’re being original and clever by parroting epithets that weren’t very funny when we first heard them 20 years ago and haven’t gotten any better since.” Please submit your ideas, but use your grown-up words. With that said, the VMM product is not in good shape.

My Two Big Wishes

1: Aidan’s article talks about “refactoring” the VMM product Hyper-V management stack. I’m in the mood for something much more aggressive. I think the VMM team should make a plain-text list of all the features that VMM has (and you know, that’s an impressive list), and maybe a few they’d like to add. They should then just throw all the existing code out. Put it in the recycle bin and set the bin on fire. Start from scratch with the user interface and user experience teams leading the way. Get input from research panels. Once all that’s collected, go and make a good product.

2: Beef up Hyper-V Manager and Failover Cluster Manager. I understand why these are separate products and I don’t think it’s asking too much of people to use separate management tools because a failover cluster and a hypervisor are two separate infrastructure components. However, Hyper-V Manager should have much more control over the failover features of the VMs that it manages and it wouldn’t hurt Failover Cluster Manager to have a little more control over host nodes.

My Wishes for VMM

I need to accept the reality that VMM is probably not going to be reset like that. However, my boss made a really good observation that holds up pretty well under testing: Microsoft usually doesn’t get anything right until the fourth or fifth try. VMM is really only on version 2 right now. It’s gone through more version numbers than that so that it can keep up with the rest of the System Center suite, but realistically, everything up to 2008 R2 was version 1 and everything since has been version 2. Hopefully, Microsoft will realize that this is a weak point and throw some resources at it, or we’re not going to have that solid version 4 until 2020 or later. Anyway, rather than spend a lot of energy chasing things that have a nearly zero chance of happening, I’ll list out some things that might.

1. Error Messaging

The error messaging in VMM is…, well, it’s just terrible. The ones that have intelligible text usually have words with little or nothing to do with the actual problem. If you get an error, you’ll likely use its code to search the Internet for solutions. Unfortunately, your best hope is that someone else has a.) figured it out and b.) written a blog article or forum post about it. If not, you usually wind up having to take some pretty poor troubleshooting steps, like reinstalling something or manually tinkering with the database. My first wish is for the error messaging to be improved dramatically. Solutions should be available on TechNet. If not, just follow the Windows team and remove the useless descriptions and replace them with “Oh gee, that didn’t work, terribly sorry” platitudes. Those aren’t helpful either, but at least they don’t have us chasing red herrings.

Seems Like a Legitimate Error When Changing a VLAN

That’ll Teach Me to Change a VLAN

The other problem with error messaging is that you have to take extra steps just to find out something is in an error state. If I open a dialog box, perform an action, click OK, and am returned to the main screen, my natural assumption is that everything went well. That’s a bad plan with VMM. Everything in this application is considered a “job”. That in itself isn’t so bad, but clicking OK in a dialog doesn’t mean “do what I said,” like it does in other applications. Here, it means “start a job to do what I said.” That’s why the program won’t throw an error, because as far as it’s concerned, its responsibility is satisfied the moment that it submits that job. If it threw an error 15 milliseconds later, that’s your problem. You have to train yourself to start something and then immediately flip to the Job tab to see what happened with it… or then, maybe not. Sometimes, the job window will automatically appear. It even has a little check box on it to prevent such job windows from automatically appearing in the future. It does not have a check box to have that box behave with any sort of consistency. The thing is, this is a problem that has a very old, very reliable, very common solution: status bars. If a job goes south and you don’t want to notify me with a pop-up window, put a nice little flashing red something in a status bar. You also have a list of items, one of which I just worked on. Add a scrolling progress bar field to that list that ignites when a job is operating on that item.

2. Networking

Networking in VMM is just ridiculously over-engineered. Networking in Hyper-V is simple (once you get over the concepts): you set up your physical infrastructure, you make a virtual switch on top of it, you attach virtual network adapters to it, and maybe you configure them with VLANs. All done, no problem. Not so in VMM. VMM tries to wrap everything up in a nice, tidy package, but manages to deliver a mess that you need a real product expert to sort out.

  • How many places do you really need to go to configure networking? There are at least four that I can recall, and I’m coasting now because my network is mostly configured the way I want it. I dread needing to make any changes to it, though. There’s just way too much going on. I understand that VMM has extra needs because it enables network virtualization features and such that Hyper-V alone can’t provide, but that’s no excuse for the mess that it is.
  • Does adding a new VLAN really need to be a major networking configuration event? Why do I have to work harder to add a new VLAN to my VMM environment than my network engineers do to add it to the real environment? You might have some grandiose idea that you’re protecting me from myself by restricting where VMM allows a VLAN ID to appear, but I don’t need that, and when I hit my frustration limit I’m just going to use PowerShell to directly assign the VLAN ID where I need it anyway.
  • Why can’t I convert between a “logical switch” and a “virtual switch”? The thing is, the logical switch can be really annoying to set up using VMM. Creating a virtual switch natively in Hyper-V is ridiculously simple regardless of the circumstances. Why can’t I make the switch using native Hyper-V PowerShell cmdlets and just let VMM take it over as a “logical switch”? Hyper-V doesn’t even seem to think there is a difference, so how much work would that really be?
  • While we’re on that subject, why is it such a pain to create a logical switch? Specifically, I’m thinking about fully converged switches. You can kick off the creation, but as soon as VMM loses contact with the Hyper-V host, it panics. This would be more acceptable if it didn’t have an agent sitting on the host that should be aware of what’s going on and could be dealing with such things.
  • With all this over-engineering, you can’t assign a VLAN to a virtual machine when you deploy it. Or, maybe you can, but it’s a big secret. You worked too hard on features that not many care about and ignored the features that nearly everyone cares about.

3. The Agent

The agent seems to be pretty fragile. I do far more agent reinstalls than I believe that I should have to (0 seems like a reasonable limit). Since VMM is something I use in my production environment and not my lab, I leave it alone. It seems only fair to ask that the software I’m not actively trying to break should be fairly solid.

If it Doesn't Work in the Next Five Minutes, Just Wait Longer

If it Doesn’t Work in the Next Five Minutes, Just Wait Longer

4. Bare Metal Deployment

I spent nearly two months getting bare metal deployments to work. Once I did, I had a nice long two month hiatus between that and my next deployment. In the interim, an update roll-up was released for VMM. I don’t know if that was the cause, but I had another nice long fight with bare metal deployment afterward. The thing is, I’d rather use DSC or just my own PowerShell scripts and not even deal with bare metal deployment, but it’s the only way to get fully converged logical switches working without a lot of other excessively complicated busy work.

The first issue with this feature is that it’s really poorly documented. In conjunction with the really poor error messaging, it’s really hard to determine why something went wrong. One thing that hit us especially hard is that all the necessary firewall ports are not documented. We wound up calling Microsoft support and they, largely on a hunch, decided to run traces on our network. So, the conclusion is, they don’t entirely know how it works, either. Side note: the firewall issue seems to be fairly common at Microsoft. If you use internal hardware firewalls and a Microsoft product doesn’t work right, break out Wireshark and go it alone. Support will take at least a couple of days to sort it out if you get into the top tier and a week or two if you’re in the bottom tier. I think it’s kind of embarrassing that Microsoft doesn’t know the firewall ports for its own products, but the people I’ve talked to there seem to think there’s nothing strange about having developers that set up software communications channels and don’t tell anyone what they are.

The next thing about bare metal deployment, and one that I did leave feedback on, is that it’s annoyingly all-or-nothing. If there’s a problem somewhere, you’ll probably invest twenty minutes in waiting to find out. If it fails, there’s no real retry button. You can retry the job from its last failed point, but since you can’t change any parameters, odds are pretty high that it will just encounter the same problem again. There are many manual data entry points for a bare metal deployment, and you can’t make any errors. Each attempt requires at least one reboot of the target host system, which, since so many modern servers take longer than a 1980’s 80286 system to boot, can cause a great deal of lost time and frustration. This inability to click Back to fix things that the “wizard” should have identified during a pre-flight phase has become a tiresome, endemic problem across the entire Microsoft stack.

5. PowerShell

I’m a big advocate of PowerShell and all the fantastic things it can do, so this doesn’t come easily. The PowerShell module in VMM is… well, it needs some help. Since I don’t use VMM any more often than I have to, I don’t use the PowerShell module much, either. It tends to be on the frustrating side though, as items I expect to pipeline from one cmdlet to another don’t seem to be well-received. That, ultimately, is more of a learning-curve issue than anything else, which is to be expected. What’s not expected is that the authors of the module broke one of the cardinal rules of PowerShell. When a module shadows a cmdlet from a pre-existing module, it should replicate all of the functionality of the original. VMM’s PowerShell module breaks functionality in the base Hyper-V module such that at least the Get-VM cmdlet no longer functions as expected. That wreaks havoc on a lot of my scripts, and I’ve seen it break those from other people too. You have to know PowerShell enough to realize where the break is occurring, because it is not obvious. Since I tend to not load the VMM PowerShell module unless I’ve run out of options, I don’t yet know if there are others that it breaks, but it does create aliases for several other cmdlets in the Hyper-V module.

As for the learning curve, that’s partially the interface’s fault, too. What most people do, regardless of the technology, is undergo all their on-the-job learning in the graphical interface, gradually figure out how to get PowerShell to duplicate that, and then make the jump to using PowerShell. VMM’s interface is so complicated and its processes so error-prone that you’re completely exhausted once you finally get it to do anything. There’s really no energy left over to go wrestling with the PowerShell cmdlets as well.

6. Packaging and Pricing

VMM 2008 R2 came in a “Workgroup” edition that allowed you to manage up to 5 hosts for about $500 at maximum retail cost. This made it good for small and medium businesses. Buying it alone meant that you lost out on the enhancements of Operations Manager, but that’s what I meant by the “value-add” comment above.

Starting with 2012, the “Workgroup” edition was no more. It was replaced by an odd licensing scheme that allowed you to have two virtual machines on a single host at a somewhat reasonable price, but anything after that had a very high price tag attached. The benefit* was that you got all the components of System Center at that price. I have to put an asterisk by “benefit” because not everyone wanted that. The medium-sized organization I was working for at the time of 2012’s debut had elected to forgo Operations Manager in the 2008 R2 edition because it didn’t add anything we really cared about. We evaluated the other components of System Center and decided that we simply didn’t want them and wouldn’t have used them even if they were free. The pricing change in 2012 amounted to a gigantic upsell of products that we had no interest in, effectively escalating the cost of VMM well beyond our budget or interest. The fact that it was, from our point of view, inferior to 2008 R2 didn’t help matters any.

7. It’s OK to be Microsoft

You can use VMM to manage not only manage Hyper-V hosts but ESX and XenServer as well. That’s all well and good, but it does seem like a great deal is sacrificed to shoehorn them in. Do you think that VMware or Citrix would short-change their own interfaces just to cram support for Hyper-V in? Of course they wouldn’t. No one expects them to. So, why is Microsoft sacrificing anything to give support for these products? It’s OK to let them in, but don’t dumb down Hyper-V support to do it. Make them second-class citizens if you have to. People are likely to continue using vSphere and XenCenter anyway. Don’t force us to keep using Hyper-V Manager and Failover Cluster Manager when we’ve bought into your premium platform (at a really high price, too).

8. I Know What I’m Doing. No, Really

Have you ever met anyone that says, “Hooray! VMM has marked my VM as ‘Unsupported Configuration’ and won’t let me manage it!” Me neither. And what, really, is the point of it anyway? So, let’s say I create a virtual machine on a CSV and don’t make it highly available. VMM won’t let me manage it until I rectify the problem. Why can’t I just use VMM to rectify the problem? Does this really make sense to anyone? Yes, I’m aware that a particular VM only has one preferred owner. Why does that cause a hard block on me being able to Live Migrate it to a non-preferred host if I want to? Does someone not understand what the word “preferred” means? I tried to change the VLAN on a guest, VMM freaked out about it for some unintelligible reason, and now it’s unmanageable? Really?

VMM’s Future

There is a pretty simple statement to be made here. If Microsoft is truly serious about becoming the de facto virtualization solution, VMM absolutely must be attended to in a very serious fashion and in very short order. It wants to be a major data center component but it is too unstable, too unwieldy, and too limited in scope to fulfill that dream. We all need to do our part to make it better, and the part that we in the community can do is submit ideas.

If you want to give feedback to the VMM team, use this link (remember to be nice; programming and interface design is really hard work and we don’t know what kind of conditions they’re working under):

If you want to vote on Aidan’s idea, this is the link:


The Hyper-V Hub 2014 Year in Review

The Hyper-V Hub 2014 Year in Review

Like any creative work, a blog post is never really done; it’s just abandoned. Unlike many other mediums, blogs do allow us to easily refresh those older articles, but we so rarely ever do it. To close out this year, a few of us on the editorial team got together and selected a few highlights from the past year.

Our 14 selections from 2014 (in no particular order):

Hyper-V Guest Licensing

This was our first licensing article directly related to guest licensing. We followed it up with a downloadable eBook that was expanded to include a number of examples, and Andy Syrewicze and Thomas Maurer gave a fantastic webinar on the topic. We’ve received quite a few questions and some great feedback. Keep an eye out for a follow-up post that takes on some of those questions and incorporates some of the suggestions. If you’ve got questions or suggestions of your own, feel free to send them in (by leaving a comment)!

Demystifying Virtual Domain Controllers (series)

This two part series started with a look at all the myths surrounding the virtualization of domain controllers and exposed the truths. In part 2, we explained how to successfully virtualize your domain controllers without headaches. I felt that both of these articles explained the situation and remedies very well, except that it seems that some people have been unable to make time synchronization work correctly when the Hyper-V Time Synchronization service is partially disabled for virtualized domain controllers. Microsoft has changed their published policy to include a recommendation that time sync be fully disabled for DC guests, although personally, I think the jury is still out. Completely disabling it is certainly an expedient solution to a frustrating situation, but that doesn’t automatically make it the best option. I’ve been able to make partial disablement work every time I’ve tried, and it’s the only way to guarantee that a DC that was saved (even accidentally) will be able to properly recover.

7 Reasons not to Make Hyper-V a Domain Controller

I wrote this post as I saw a lot of people really trying hard to justify using their Hyper-V hosts as domain controllers. It’s a really bad idea, so I collected all the reasoning I could think of not to do it. In retrospect, I probably should have ordered them a little better to address the topmost concerns first. Those are:

  1. Licensing costs. People want to save on licensing by just installing the domain controller in the Hyper-V host so that they don’t have to pay for a Windows license just to run domain services. As explained in #4, this doesn’t work.
  2. The chicken-and-egg myth. People believe that if they join the Hyper-V host to the domain and the only DC is a guest, then the Hyper-V host won’t boot or will have other problems. That wasn’t even mentioned in this article, at least not outright, although it was a major point of the articles that it links to.
  3. The myth that Hyper-V hosts should be left in workgroup mode to increase security. This was included as point #1, which isn’t a bad placement for it. People get too close to a situation and sometimes make irrational decisions. They don’t want to put their systems at unnecessary risk and a compromised Hyper-V host can potentially put a lot of guests at risk all at once, so they do take steps to distance the host from the guests. While there are solutions, workgroup mode isn’t one of them. I mean, just try to say this out loud without laughing: “Workgroup mode is more secure than domain mode”. Or, write this on your resume: “I once put a computer in workgroup mode to increase security over domain mode”. I’ll bet that won’t get you many callbacks.

Common Hyper-V Deployment Mistakes

“There are three kinds of men. The one that learns by reading. The few who learn by observation. The rest of them have to pee on the electric fence for themselves.” – Will Rogers

One really good way to learn is from your own mistakes. Most people that do something really wrong are much less likely to do that same thing twice. But, as far as I’m concerned, it’s a whole lot better if you can learn from other people’s mistakes. This article compiles a list of the ones I’ve seen most frequently in the hopes that at least a few people can avoid them.

Storage Formatting and File Systems (part 4 of a series)

We had an unusually long (7 parts!) series on storage and Hyper-V. Even though this particular piece looked at parts of storage that some people might find very basic, we often forget that there are always newcomers, and sometimes even experienced administrators missed some of the basics during their career. A highlight of this article is that it puts to bed an old recommendation about spending a lot of time on sector alignment. It also takes a generalized look at architecting disk layout for Hyper-V.

Connecting to Storage in Hyper-V (part 6 of a series)

Everyone likes a good how-to. Even if you can figure something out on your own, it makes little sense to do so if someone else has already done the work. For many administrators, moving to a virtualization platform is the first time they’ll connect to external storage, which is why I took the time to lay out exactly how it’s done. I noticed that we had intended to publish a Powershell-equivalent article to this one, but that never came to fruition. We’ll rectify that in 2015.

Creating a Virtual Machine from a Hyper-V Snapshot (series)

Another outstanding submission from Jeff Hicks, this article shows a clever way to create a snapshot (now checkpoint) of a virtual machine and turn it into its own virtual machine. This gives you some cloning powers without needing to incur the expense of something like Virtual Machine Manager. Be sure to keep reading into part 2, where he shows you how to do it all much more efficiently with PowerShell.

10 Awesome Hyper-V Cmdlets

Jeff Hicks compiled a list of his 10 favorite Hyper-V cmdlets and took us all for a quick tour. If you’re thinking about integrating PowerShell with Hyper-V into your toolkit as a New Year’s resolution, this is a great place to start with one of the topmost experts.

A PowerShell-Based Hyper-V Health Report

This fantastic article was written by Jeff Hicks, and is one of my personal favorites. This is a wonderful little script that quickly runs against the target hosts that you specify and returns a snappy-looking HTML health report. Even better, Jeff shows you how to set it up to run automatically against all your hosts, so you can easily have a daily report.

Best Practices to Maximize Hyper-V Performance

In this article, Nirmal discusses the best approaches to ensure your Hyper-V guests are operating at their peak performance. Since Nirmal focused on peak performance and we had more than a few comments about that, we’re planning a follow-up article that contains more generalized best practices.

Resizing Online VM Disks

Another great how-to guide from Nirmal shows you how to use the new feature of 2012 R2 that allows you to resize a Hyper-V VM’s virtual SCSI disk without shutting the guest down.

Hyper-V Virtual CPUs Explained

Out of all my articles, this is one of my personal favorites. I feel really bad for people who spend a lot of time wringing their hands over how many cores should be in their Hyper-V hosts, especially when they wind up spending too much money on CPUs that are just going to sit idle. One thing I probably should have mentioned in that article is that one of the first things many of us do to address certain Hyper-V performance issues is disable many of the power-saving features of our processors (C-states, especially). If you’ve got a lot of cores sitting idle, that’s a lot of wasted energy. And, if Aidan Finn’s prediction about per-core licensing comes true in 2015 (I really hope it doesn’t), then it’s going to translate into lots of wasted licensing dollars as well.

The Hyper-V and PowerShell Series

PowerShell still hasn’t become of serious importance to far too many administrators, and that’s really a shame. Since I clearly remember the days before I learned to embrace it and all the reasons I invoked to avoid it, I can certainly understand why. It’s just one of those things that can be tough to see the value in until you have your own personal “A ha!” moment. This series is meant to serve a dual role: one is to provide useful scripts to the Hyper-V community. The other is to simply to teach by example. If you’ve just come for the scripts, great! If you happen to learn something while you’re here, that’s even better!

Finding Orphaned Hyper-V VM Files

I’ve written a number of PowerShell scripts for you now, but far and away this one is both the most complicated and my favorite. For a very long time prior, I had been thinking, “Someone should do that.” I was eventually forced to accept that I qualify as “someone”. A few days into this, I realized just why no one had done it. I learned a lot, though, and there are certainly a great many uncommon techniques included in this script. So, it has its surface value of being the only tool I know of that can track down orphaned Hyper-V files, but it would also be something that intermediate PowerShell scripters can tear apart for tidbits to add to their own scripting toolkit.

The Future

Time keeps on slippin’, slippin’, slippin’, into the future. – The Steve Miller Band, “Fly Like an Eagle”

As we close out 2014 by examining our successes, we acknowledge that all of it has been made possible by you, our readers. If you want to have a say in how in how we approach 2015, now is your chance! Let us know in the comments what you’d like to see more of, what you’d like to see less of, and what big things we’ve missed entirely.

On behalf of the Altaro blogging crew, we’ve had a wonderful time writing for you and interacting with you in the comments section. We wish you and yours a wonderful holiday season and look forward to another wonderful year!

How to Create a New Virtual Machine from a Hyper-V Snapshot Part 2

How to Create a New Virtual Machine from a Hyper-V Snapshot Part 2

In the first part of this series I walked through using the Hyper-V Manager to create a new virtual machine from a snapshot. If this is something you only need to do occasionally, there is no reason not to use a graphical tool. But if you find yourself doing this often, or would like a way to automate the process for the sake of efficiency, then you’ll need to turn to Windows PowerShell. (more…)