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)
    movevm_hvmwiz1
  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.
    movevm_hvmwiz2
  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:

movevm_hvmwiz3

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

movevm_hvmwiz4

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:

movevm_hvmwiz5

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

movevm_hvmwiz6

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:

movecm_fcm1

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:

movevm_fcmaddshare

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:

movecm_fcm2

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

8 Most Important Announcements from Microsoft Ignite 2017

8 Most Important Announcements from Microsoft Ignite 2017

Last week saw us close the door on Microsoft Ignite 2017, and while the conference came and went in a blur, there was no lack of information or amazing reveals from Microsoft. While this conference serves as a great way to stay informed on all the new things that Microsoft is working on, I also find that it is a good way to get an overall sense of the company’s overall direction. With that in mind, I wanted to not only talk about some of my favorite reveals from the week but also discuss my take on Microsoft’s overall direction.

Microsoft Ignite 2017 - most important announcements

My take on the week from an Infrastructure Engineering Perspective

To put things simply….. things are changing, and they’re changing in a big way. I’ve had this gut feeling stirring for some time that the way we work with VMs and virtualization was changing, and the week of Ignite was a major confirmation of that. This is not to mention the continued shift from the on-premise model we’re used to, to the new cloud (Public, Private, and Hybrid) model that things are moving too.

It’s very clear that Microsoft is adopting what I would call the “Azure-Everywhere” approach. Sure, you’ve always been able to consume Azure using what Microsoft has publicly available, but things really changed when Azure Stack is put into the mix. Microsoft Azure Stack (MAS) is officially on the market now, and the idea of having MAS in datacenters around the world is an interesting prospect. What I find so interesting about it, is the fact that management of MAS onsite is identical to managing Azure. You use Azure Resource Manager and the same collection of tools to manage both. Pair that with the fact that Hyper-V is so abstracted and under-the-hood in MAS that you can’t even see it, and you’ve got a recipe for major day-to-day changes for infrastructure administrators.

Yes, we’ve still got Windows Server 2016, and the newly announced Honolulu management utility, but If I look out 5, or even 10 years, I’m not sure I see us working with Windows Server anymore in the way that we do so today. I don’t think VM usage will be as prevalent then as it is today either. After last week, I firmly believe that containers will be the “new virtual machine”. I think VMs will stay around for legacy workloads, and for workloads that require additional layers of isolation, but after seeing containers in action last week, I’m all in on that usage model.

We used to see VMs as this amazing cost-reducing technology, and it was for a long time. However, I saw containers do to VMs, what VMs did to physical servers. I attended a session on moving workloads to a container based model, and MetLife was on stage talking about moving some of their infrastructure to containers. In doing so they achieved:

  • -70% reduction in the number of VMs in the environment
  • -67% reduction in needed CPU cores
  • -66% reduction in overall cost of ownership

Those are amazing numbers that nobody can ignore. Given this level of success with containers, I see the industry moving to that deployment model from VMs over the next several years. As much as it pains me to say it, virtual machines are starting to look very “legacy”, and we all need to adjust our skill sets accordingly.

Big Reveals

As you know, Ignite is that time of year where Microsoft makes some fairly large announcements, and below I’ve compiled a list of some of my favorite. While this is by no means a comprehensive list,  but I feel these represent what our readers would find most interesting. Don’t agree? That’s fine! Just let me know what you think were the most important announcements in the comments. Let’s get started.

8. New Azure Exams and Certifications!

With new technologies, come new things to learn, and as such there are 3 new exams on the market today for Azure Technologies.

  • Azure Stack Operators – Exam 537: Configuring and Operating a Hybrid Cloud with Microsoft Azure Stack
  • For Azure Solutions Architects – Exam 539: Managing Linux Workloads on Azure
  • For Azure DevOps – Exam 538: Implementing Microsoft Azure DevOps Solutions

If you’re interested in pursuing any of these (Which I would Highly Recommend) then you can get more information on them at this link.

7. SQL Server 2017 is now Available

Normally I wouldn’t make much of a fuss about SQL Server as I’m not much of a SQL guy myself, but Microsoft did something amazing with this release. SQL Server 2017 will run on Windows, Linux, and inside of Docker Containers. Yes, you read correctly. SQL Server 2017 will run on Linux and inside of docker containers, which opens up a whole new avenue of providing SQL workloads. Exciting times indeed!

6. Patch Management from the Azure Portal

Ever wanted to have WSUS available from the Azure portal? Now you have it. You can easily view, and deploy patches for your Azure based workloads directly from the Azure portal. This includes Linux VMs as well, which is great news as more and more admins are finding themselves managing Linux workloads these days!

5. PowerShell now Available in Azure CLI.

When Azure CLI was announced and released, many people were taken aback at the lack of PowerShell support. This was done for a number of reasons that I won’t get into in this article, but regardless, it has been added in now. It is now possible with Azure CLI to deploy a VM with a single PowerShell cmdlet and more. So, get those scripts ready!

4. Azure File Sync in Preview

I know many friends and colleagues that have been waiting for something like this. You can essentially view this as next-generation DFS. (Though it doesn’t use the same technology). It essentially allows you to sync your on-premise file servers with an Azure Files account for distributed access to the stored information around the globe.

3. Quality of Life Improvements for Windows Containers

While there were no huge reveals in the container space, Windows Server 1709 was announced and contains a lot of improvements and optimizations for running containers on Windows Server. This includes things like smaller images and support for Linux Containers running on Windows Server. I did an Interview with Taylor Brown from the Containers team, which you can view below for more information.

2. Nested Virtualization in Azure for Production Workloads

Yes, I know, nested virtualization in Azure has been announced for some time. However, what I found different was Microsoft’s Insistence that it could also be used for production workloads. During Scott Guthrie’s Keynote, Corey Sanders actually demonstrated the use of the M-Series (Monster) VM in Azure being used to host production workloads with nested VMs. While not ideal in every scenario obviously, this is simply another tool that we have at our disposal for added flexibility in our day-to-day operations.

If you’re interested, I actually interviewed Rick Claus from the Azure Compute team about this. That Interview can be seen below

1. Project Honolulu

This one is for the folks that are still strictly interested in only the on-prem stuff. Microsoft revealed and showed us the new Project Honolulu management utility for on-premise workloads. Honolulu, takes the functionality of all the management tools and MMC snap-ins that we’ve been using for years and packages them up into a nice easy to use web-UI. It’s worth a look if you haven’t seen it yet. We even have a nice article on our blog about it if you’re interested in reading more!

Wrap-Up

As I mentioned, this was by no means a comprehensive list, but we’ll be talking about items (From this list and some not mentioned) from Ignite on our blogs for some time. So, be sure to keep an eye on our blog if you’re interested in more information.

Additionally, if you attended Microsoft Ignite, and you saw a feature or product you think is amazing that is not listed above, be sure to let us know in the comments section below!

Why Your Hyper-V PowerShell Commands Don’t Work (and how to fix them)

Why Your Hyper-V PowerShell Commands Don’t Work (and how to fix them)

I occasionally receive questions about Hyper-V-related PowerShell cmdlets not working as expected. Sometimes these problems arise with the module that Microsoft provides; other times, they manifest with third-party tools. Even my own tools show these symptoms. Most GUI tools are developed to avoid the problems that plague the command line, but the solutions aren’t always perfect.

The WMI Foundation

All tools, graphical or command-line, eventually work their way back to the only external interface that Hyper-V provides: its WIM/CIM provider. CIM stands for “Common Information Model”. The Distributed Management Task Force (DMTF) maintains the CIM standard. CIM defines a number of interfaces pertaining to management. Anyone can write CIM-conforming modules to work with their systems. These modules allow users, applications, and services to retrieve information and/or send commands to the managed system. By leveraging CIM, software and hardware manufacturers can provide APIs and controls with predictable, standardized behavior.

Traditionally, Microsoft has implemented CIM via Windows Management Instrumentation (WMI). Many WMI instructions involved VBS or WMIC. As PowerShell gained popularity, WMI also gained popularity due to the relative ease of Get-WmiObject. Depending on where you look in Microsoft’s vast documentation, you might see pushes away from the Microsoft-specific WMI implementation toward the more standard CIM corollaries. Get-CimInstance provides something of an analog to Get-WmiObject, but they are not interchangeable.

For any of this to ever make any sense, you need to understand one thing: anyone can write a CIM/WMI provider. The object definitions and syntax of a provider all descend from the common standard, but they do nothing more than establish the way an interface should look. The provider’s developer determines how it all functions behind the scenes.

Why Hyper-V PowerShell Cmdlets May Not Work

Beyond minor things like incorrect syntax and environmental things like failed hardware, two common reasons prevent these tools from functioning as expected.

The Hyper-V Security Model

I told you all that about WMI so that this part would be easier to follow. The developers behind the Hyper-V WMI provider decide how it will react to any given WMI/CIM command that it receives. Sometimes, it chooses to have no reaction at all.

Before I go too far, I want to make it clear that no documentation exists for the security model in Hyper-V’s WMI provider. I ran into some issues with WMI commands not working the way that I expected. I opened a case with Microsoft, and it wound up going all the way to the developers. The answer that came back pointed to the internal security coding of the module. In other words, I was experiencing a side effect of designed behavior. So, I asked if they would give me the documentation on that — basically, anything on what caused that behavior. I was told that it doesn’t exist. They obviously don’t have any externally-facing documentation, but they don’t have anything internal, either. So, everything that you’re going to see in this article originates from experienced (and repeatable) behavior. No insider secrets or pilfered knowledge were used in the creation of this material.

Seeing Effects of the Hyper-V Security Model in Action

Think about any “Get” PowerShell cmdlet. What happens when you run a “Get” against objects that don’t exist? For example, what happens when I run Get-Job when no jobs are present?

psnowork_emptygetjob

Nothing! That’s what happens. You get nothing. So, you learn to interpret “I got nothing” to mean “no objects of that type exist”.

So, if I run Get-VM and get nothing (2012/R2):

psnowork_emptygetvm

That means that the host has no virtual machines, right?

But wait:

Hyper-V Powershell commands help

What happened? A surprise Live Migration?

Look at the title bars carefully. The session on the left was started normally. The session on the right was started by using Run as administrator.

The PowerShell behavior has changed in 2016:

psnowork_emptygetvm2016

The PowerShell cmdlets that I tried now show an appropriate error message. However, only the PowerShell module has been changed. The WMI provider behaves as it always has:

psnowork_wmigetvm2016

To clarify that messy output, I ran gwmi -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem -Filter 'Caption="Virtual Machine"' as a non-privileged user and the system gave no output. That window overlaps another window that contains the output from Get-VM in an elevated session.

Understanding the Effects of the Hyper-V Security Model

When we don’t have permissions to do something, we expect that the system will alert us. If we try to open a file, we get a helpful error message explaining why the system can’t allow it. We’ve all had that experience enough times that we’ve been trained to expect a red flag. The Hyper-V WMI provider does not exhibit that expected behavior. I have never attempted to program a WMI provider myself, so I don’t want to pass any judgment. I noticed that the MSCluster namespace acts the same way, so it may be something inherent to CIM/WMI that the provider authors have no control over.

In order for a WMI query to work against Hyper-V’s provider, you must be running with administrative privileges. Confusingly, “being a member of the Administrators group” and “running with administrative privileges” are not always the same thing. When working with the Hyper-V provider on the local system, you must always ensure that you run with elevated privileges (Run as administrator) — even if you log on with an administrative account. Remote processes don’t have that problem.

The administrative requirement presents another stumbling block: you cannot create a permanent WMI event watcher for anything in the Hyper-V provider. Permanent WMI registration operates anonymously; the Hyper-V provider requires confirmed administrative privileges. As with everything else, no errors are thrown. Permanent WMI watchers simply do not function.

The takeaway: when you unexpectedly get no output from a Hyper-V-related PowerShell command, you most likely do not have sufficient permissions. Because the behavior bubbles up from the bottom-most layer (CIM/WMI), the problem can manifest in any tool.

The Struggle for Scripters and Application Developers

People sometimes report that my tools don’t work. For example, I’ve been told that my KVP processing stack doesn’t do anything. Of course, the tool works perfectly well — as long as it has the necessary privileges. So, why didn’t I write that, and all of my other scripts, to check their privilege? Because it’s really hard, that’s why.

With a bit of searching, you’ll discover that I could just insert #requires -RunAsAdministrator at the top of all my scripts. Problem solved, right? Well, no. Sure, it would “fix” the problem when you run the script locally. But, sometimes you’ll run the script remotely. What happens if:

  • … you run the script with an account that has administrative privileges on the target host but not on the local system?
  • … you run the script with an account that has local administrative privileges but only user privileges on the target host?

The answer to both: the actual outcome will not match your desired outcome.

I would need to write a solution that:

  • Checks to see if you’re running locally (harder than you might think!)
  • Checks that you’re a member of the local administrators
  • If you’re running locally, checks if your process token has administrative privileges

That’s not too tough, right? No, it’s not awful. Unfortunately, that’s not the end of it. What if you’re running locally, but invoke PowerShell Remoting with -ComputerName or Enter-PSSession or Invoke-Command? Then the entire dynamic changes yet again, because you’re not exactly remote but you’re not exactly local, either.

I’ve only attempted to fully solve this problem one time. My advanced VM settings editor includes layers of checks to try to detect all of these conditions. I spent quite a bit of time devising what I hoped would be a foolproof way to ensure that my application would warn you of insufficient privileges. I still get messages telling me that it doesn’t show any virtual machines.

I get better mileage by asking you to run my tools properly.

How to Handle the Hyper-V WMI Provider’s Security

Simply put, always ensure that you are running with the necessary privileges. If you are working locally, open PowerShell with elevated permissions:

psnowork_runas

If running remotely, always ensure that the account that you use has the necessary permissions. If your current local administrator account does not have the necessary permissions on the target system, invoke PowerShell (or whatever tool you’re using) by [Shift]+right-clicking the icon and selecting Run as different user:

psnowork_runasdifferentuser

What About the “Hyper-V Administrators” Group?

Honestly, I do not deal with this group often. I don’t understand why anyone would be a Hyper-V Administrator but not a host administrator. I believe that a Hyper-V host should not perform any other function. Trying to distinguish between the two administrative levels gives off a strong “bad plan” odor.

That said, I’ve seen more than a few reports that membership in Hyper-V Administrators does not work as expected. I have not tested it extensively, but my experiences corroborate those reports.

The Provider Might Not Be Present

All this talk about WMI mostly covers instances when you have little or no output. What happens when you have permissions, yet the system throws completely unexpected errors? Well, many things could cause that. I can’t make this article into a comprehensive troubleshooting guide, unfortunately. However, you can be certain of one thing: you cannot tell Hyper-V to carry out an action if Hyper-V is not running!

Let’s start with an obvious example. I ran Get-VM on a Windows 10 system without Hyper-V:

psnowork_getvmnohv

Nice, clear error, right? 2012 R2/Win 8.1 have a slightly different message.

Things change a bit when using the VHD cmdlets. I don’t have any current screenshots to show you because the behavior changed somewhere along the way… perhaps with Update 1 for Windows Server 2012 R2. Windows Vista/Server 2008 and later include a native driver for mounting and reading/writing VHD files. Windows 8/Server 2012 and later include a native driver for mounting and reading/writing VHDX files. However, only Hyper-V can process any of the VHD cmdlets. Get-VHD, New-VHD, Optimize-VHD, Resize-VHD, and Set-VHD require a functioning installation of Hyper-V. Just installing the Hyper-V PowerShell module won’t do it.

Currently, all of these cmdlets will show the same or a similar message to the one above. However, older versions of the cmdlets give a very cryptic message that you can’t do much with.

How to Handle a Missing Provider

This seems straightforward enough: only run cmdlets from Hyper-V module against a system with a functioning installation of Hyper-V. You can determine which functions it owns with:

When running them from a system that doesn’t have Hyper-V installed, use the ComputerName parameter.

Further Troubleshooting

With this article, I wanted to knock out two very simple reasons that Hyper-V PowerShell cmdlets (and some other tools) might not work. Of course, I realize that any given cmdlet might error for a wide variety of reasons. I am currently only addressing issues that block all Hyper-V cmdlets from running.

For troubleshooting a failure of a specific cmdlet, make sure to pay careful attention to the error message. They’re not always perfect, but they do usually point you toward a solution. Sometimes they display explicit text messages. Sometimes they include the hexadecimal error code. If they’re not clear enough to understand immediately, you can use these things in Internet searches to guide you toward an answer. You must read the error, though. Far too many times, I see “administrators” go to a forum and explain what they tried to do, but then end with, “I got an error” or “it didn’t work”. If the error message had no value the authors wouldn’t have bothered to write it. Use it.

[the_ad_group id=”229″]

Hyper-V Key-Value Pair Data Exchange Part 3: Linux

Hyper-V Key-Value Pair Data Exchange Part 3: Linux

Some time ago, I discovered uses for Hyper-V Key-Value Pair Data Exchange services and began exploiting them on my Windows guests. Now that I’ve started building Linux guests, I need similar functionality. This article covers the differences in the Linux implementation and includes version 1.0 of a program that allows you to receive, send, and delete KVPs.

For a primer on Hyper-V KVP Exchange, start with this article: Hyper-V Key-Value Pair Data Exchange Part 1: Explanation.

The second part of that series presented PowerShell scripts for interacting with Hyper-V KVP Exchange from both the host and the guest sides. The guest script won’t be as useful in the context of Linux. Even if you install PowerShell on Linux, the script won’t work because it reads and writes registry keys. It might still spark some implementation ideas, I suppose.

What is Hyper-V Key-Value Pair Data Exchange?

To save you a few clicks and other reading, I’ll give a quick summary of Hyper-V KVP Exchange.

Virtual machines are intended to be “walled gardens”. The host and guest should have limited ability to interact with each other. That distance sometimes causes inconvenience, but the stronger the separation, the stronger the security. Hyper-V’s KVP Exchange provides one method for moving data across the wall without introducing a crippling security hazard. Either “side” (host or guest) can “send” a message at any time. The other side can receive it — or ignore it. Essentially, they pass notes by leaving them stuck in slots in the “wall” of the “walled garden”.

KVP stands for “key-value pair”. Each of these messages consists of one text key and one text value. The value can be completely empty.

How is Hyper-V KVP Exchange Different on Linux?

On Windows guests, a service runs (Hyper-V Data Exchange Service) that monitors the “wall”. When the host leaves a message, this service copies the information into the guest’s Windows registry. To send a message to the host, you (or an application) create or modify a KVP within a different key in the Windows registry. The service then places that “note” in the “wall” where the host can pick it up. More details can be found in the first article in this series.

Linux runs a daemon that is the analog to the Windows service. It has slightly different names on different platforms, but I’ve been able to locate it on all of my distributions with sudo service --status-all | grep kvp. It may not always be running; more on that in a bit.

Linux doesn’t have a native analog to the Windows registry. Instead, the daemon maintains a set of files. It receives inbound messages from the host and places them in particular files that you can read (or ignore). You can write to one of the files. The daemon will transfer those messages up to the host.

On Windows, I’m not entirely certain of any special limits on KVP sizes. A registry key can be 16,384 characters and there is no hard-coded limit on value size. I have not tested how KVP Exchange handles these extents on Windows. However, the Linux daemon has much tighter constraints. A key can be no longer than 512 bytes. A value can be no longer than 2,048 bytes.

The keys are case sensitive on the host and on Linux guests. So, key “LinuxKey” is not the same as key “linuxkey”. Windows guests just get confused by that, but Linux handles it easily.

How does Hyper-V KVP Exchange Function on Linux?

As with Windows guests, Data Exchange must be enabled on the virtual machine’s properties:

Hyper-V KVP Exchange on Linux

The daemon must also be installed and running within the guest. Currently-supported versions of the Linux kernel contain the Hyper-V KVP framework natively, so several distributions ship with it enabled. As mentioned in the previous section, the exact name of the daemon varies. You should be able to find it with: sudo service --status-all | grep kvp. If it’s not installed, check your distribution’s instruction page on TechNet.

All of the files that the daemon uses for Hyper-V KVP exchange can be found in the /var/lib/hyperv folder. They are hidden, but you can view them with ls‘s -a parameter:

Hyper-V KVP exchange

Anyone can read any of these files. Only the root account has write permissions, but that can be misleading. Writing to any of the files that are intended to carry data from the host to the guest has no real effect. The daemon is always monitoring them and only it can carry information from the host side.

What is the Purpose of Each Hyper-V KVP Exchange File?

Each of the files is used for a different purpose.

  • .kvp_pool_0: When an administrative user or an application in the host sends data to the guest, the daemon writes the message to this file. It is the equivalent of HKLMSOFTWAREMicrosoftVirtual MachineExternal on Windows guests. From the host side, the related commands are ModifyKvpItems, AddKvpItems, and RemoveKvpItems. The guest can read this file. Changing it has no useful effect.
  • .kvp_pool_1: The root account can write to this file from within the guest. It is the equivalent of HKLMSOFTWAREMicrosoftVirtual MachineGuest on Windows guests. The daemon will transfer messages up to the host. From the host side, its messages can be retrieved from the GuestExchangeItems field of the WMI object.
  • .kvp_pool_2: The daemon will automatically write information about the Linux guest into this file. However, you never see any of the information from the guest side. The host can retrieve it through the GuestIntrinsicExchangeItems field of the WMI object. It is the equivalent of the HKLMSOFTWAREMicrosoftVirtual MachineAuto key on Windows guests. You can’t do anything useful with the file on Linux.
  • .kvp_pool_3: The host will automatically send information about itself and the virtual machine through this file. You can read the contents of this file, but changing it does nothing useful. It is the equivalent of the HKLMSOFTWAREMicrosoftVirtual MachineGuestParameter key on Windows guests.
  • .kvp_pool_4: I have no idea what this file does or what it is for.

What is the Format of the Hyper-V KVP Exchange File on Linux?

Each file uses the same format.

One KVP entry is built like this:

  • 512 bytes for the key. The key is a sequence of non-null bytes, typically interpreted as char. According to the documentation, it will be processed as using UTF8 encoding. After the characters for the key, the remainder of the 512 bytes is padded with null characters.
  • 2,048 bytes for the value. As with the key, these are non-null bytes typically interpreted as char. After the characters for the value, the remainder of the 2,048 bytes is padded with null characters.

KVP entries are written end-to-end in the file with no spacing, headers, or footers.

For the most part, you’ll treat these as text strings, but that’s not strictly necessary. I’ve been on this rant before, but the difference between “text” data and “binary” data is 100% semantics, no matter how much code we write to enforce artificial distinctions. From now until the point when computers can process something other than low voltage/high voltage (0s and 1s), there will never be anything but binary data and binary files. On the Linux side, you have 512 bytes for the key and 2,048 bytes for the value. Do with them as you see fit. However, on the host side, you’ll still need to get through the WMI processing. I haven’t pushed that very far.

How Do I Use Hyper-V KVP Exchange for Linux?

This is the part where it gets fun. Microsoft only goes so far as to supply the daemon. If you want to push or pull data, that’s all up to you. Or third parties.

But really, all you need to do is read to and/or write from files. The trick is, you need to be able to do it using the binary format that I mentioned above. If you just use a tool that writes simple strings, it will improperly pad the fields, resulting in mangled transfers. So, you’ll need a bit of proficiency in whatever tool you use. The tool itself doesn’t matter, though. Perl, Python, bash scripts,… anything will do. Just remember these guidelines:

  • Writing to files _0, _2, _3, and _4 just wastes time. The host will never see it, it will break KVP clients, and the files’ contents will be reset when the daemon restarts.
  • You do not need special permission to read from any of the files.
  • _1 is the only file that it’s useful to write to. You can, of course, read from it.
    • Deleting the existing contents deletes those KVPs. You probably want to update existing or append new.
    • The host only receives the LAST time that a KVP is set. Meaning that if you write a KVP with key “NewKey” twice in the _1 file, the host will only receive the second one.
    • Delete a KVP by zeroing its fields.
  • If the byte lengths are not honored properly, you will damage that KVP and every KVP following.

Source Code for a Hyper-V KVP Exchange Utility on Linux

I’ve built a small utility that can be used to read, write, and delete Hyper-V KVPs on Linux. I wrote it in C++ so that it can be compiled into a single, neat executable.

Long-term, I will only be maintaining this project on my GitHub site. The listing on this article will be forever locked in a 1.0 state.

Compile Instructions

Each file is set so that they all live in the same directory. Use make to build the sources and sudo make install to put the executable into the /bin folder.

Install Instructions

Paste the contents of all of these files into accordingly-named files. File names are in the matching section header and in the code preview bar.

Transfer all of the files to your Linux system. It doesn’t really matter where. They just need to be in the same folder.

Run:

Usage Instructions

Get help with:

  • hvkvp –help
  • hvkvp read –help
  • hvkvp write –help
  • hvkvp delete –help

Each includes the related keys for that command and some examples.

Code Listing

The file list:

  • makefile
  • main.cpp
  • hvkvp.h
  • hvkvp.cpp
  • hvkvpfile.h
  • hvkvpfile.cpp
  • hvkvpreader.h
  • hvkvpreader.cpp
  • hvkvpremover.h
  • hvkvpremover.cpp
  • hvkvpwriter.h
  • hvkvpwriter.cpp

makefile

main.cpp

 

hvkvp.h

 

hvkvp.cpp

 

hvkvpfile.h

 

hvkvpfile.cpp

 

hvkvpreader.h

 

hvkvpreader.cpp

 

hvkvpremover.h

 

hvkvpremover.cpp

 

hvkvpwriter.h

 

hvkvpwriter.cpp

More in this series:

Part 1: Explanation

Part 2: Implementation

PowerShell Script: Change Advanced Settings of Hyper-V Virtual Machines

PowerShell Script: Change Advanced Settings of Hyper-V Virtual Machines

 

Each Hyper-V virtual machine sports a number of settings that can be changed, but not by any sanctioned GUI tools. If you’re familiar with WMI, these properties are part of the Msvm_VirtualSystemSettingData class. Whether you’re familiar with WMI or not, these properties are not simple to change. I previously created a script that modifies the BIOS GUID setting, but that left out all the other available fields. So, I took that script back into the workshop and rewired it to increase its reach.

If you’re fairly new to using PowerShell as a scripting language and use other people’s scripts to learn, there are some additional notes after the script contents that you might be interested in.

What this Script Does

This script can be used to modify the following properties of a Hyper-V virtual machine:

  • BIOS GUID: The BIOS of every modern computer should contain a Universally Unique Identifier (UUID). Microsoft’s implementation of the standard UUID is called a Globally Unique Identifier (GUID).  You can see it on any Windows computer with gwmi Win32_ComputerSystem | select UUID. On physical machines, I don’t believe that it’s possible to change the UUID. On virtual machines, it is possible and even necessary at times. You can provide your own GUID or specify a new one.
  • Baseboard serial number.
  • BIOS serial number.
  • Chassis asset tag.
  • Chassis serial number.

There are other modifiable fields on this particular WMI class, but these are the only fields that I’m certain have no effect on the way that Hyper-V handles the virtual machine.

Warning 1: Changes to these fields are irreversible without restoring from backup. Modification of the BIOS GUID field is likely to trigger software activation events. Other side effects, potentially damaging, may occur. Any of these fields may be tracked and used by software inside the virtual machine. Any of these fields may be tracked and used by third-party software that manipulates the virtual machine. Use this script at your own risk.

Warning 2: These settings cannot be modified while the virtual machine is on. It must be in an Off state (not Saved or Paused). This script will turn off a running virtual machine (you are prompted first). It will not change anything on saved or paused VMs.

Warning 3: Only the active virtual machine is impacted. If the virtual machine has any checkpoints, they are left as-is. That means that if you delete the checkpoints, the new settings will be retained. If you apply or revert to a checkpoint, the old settings will be restored. I made the assumption that this behavior would be expected.

The following safety measures are in place:

  • The script is marked as High impact, which means that it will prompt before doing anything unless you supply the -Force parameter or have your confirmation preference set to a dangerous level. It will prompt up to two times: once if the virtual machine is running (because the VM must be off before the change can occur) and when performing the change.
  • The script will only accept a single virtual machine at a time. Of course, it can operate within a foreach block so this barrier can be overcome. The intent was to prevent accidents.
  • If a running virtual machine does not shut down within the allotted time, the script exits. The default wait time is 5 minutes, overridable by specifying the Timeout parameter. The timeout is measured in seconds. If the virtual machine’s guest shutdown process was properly triggered, it will continue to attempt to shut down and this script will not try to turn it back on.
  • If a guest’s shutdown integration service does not respond (which includes guests that don’t have a shutdown integration service) the script will exit without making changes. If you’re really intent on making changes no matter what, I’d use the built-in Stop-VM cmdlet first.

Script Requirements

The script is designed to operate via WMI, so the Hyper-V PowerShell module is not required. However, it can accept output from Get-VM for its own VM parameter.

You must have administrative access on the target Hyper-V host. The script does not check for this status because you might be targeting a remote computer. I did not test the script with membership in “Hyper-V Administrators”. That group does not always behave as expected, but it might work.

Set-VMAdvancedSettings

Copy/paste the contents of the code block to a text editor on your system and save the file as Set-VMAdvancedSettings.ps1. As-is, you call the script directly. If you uncomment the first two lines and the last line, you will convert the script to an advanced function that can be dot-sourced or added to your profile.

Script Notes for Other Scripters

I hope that at least some of you are using my scripts to advance your own PowerShell knowledge. This script shows two internal functions used for two separate purposes.

Code/Script Reusability

Sometimes, you’ll find yourself needing the same functionality in multiple scripts. You could rewrite that functionality each time, but I’m sure you don’t need me to tell you what’s wrong with that. You could put that functionality into another script and dot-source it into each of the others that rely on it. That’s a perfectly viable approach, but I don’t use it in my public scripts because I can’t guarantee what scripts will be on readers’ systems and I want to provide one-stop wherever possible. That leads to the third option, which is reusability.

Find the line that says function Process-WmiJob. As the comments say, I have adapted that from someone else’s work. I commonly need to use its functionality in many of my WMI-based scripts. So, I modularized it to use a universal set of parameters. Now I just copy/paste it into any other script that uses WMI jobs.

Making your code/script reusable can save you a great deal of time. Reused blocks have predictable results. The more you use them, the more likely you are to work out long-standing bugs and fine-tune them.

The problem with reused blocks is that they become disjointed. If I fix a problem that I find in the function within this script, I might or might not go back and update it everywhere else that I use it. In your own local scripting, you can address that problem by having a single copy of a script dot-sourced into all of your others. However, if each script file has its own copy of the function, it’s easier to customize it when necessary.

There’s no “right” answer or approach when it comes to code/script reusability. The overall goal is to reduce duplication of work, not to make reusable blocks. Never be so bound up in making a block reusable that you end up doing more overall work.

Don’t Repeat Yourself

A lofty goal related to code/script reusability is the Don’t Repeat Yourself principle (DRY). As I was reworking the original version of this script, I found that I was essentially taking the script block for the previous virtual machine property, copy/pasting it, and then updating the property and variable names. There was a tiny bit of customization on a few of them, but overall the blocks were syntactically identical. The script worked, and it was easy to follow along, but that’s not really an efficient way to write a script. Computers are quite skilled at repeating tasks. Humans, on the contrary, quickly tire of repetition. Therefore, it only makes sense to let the computer do whatever you’d rather skip.

DRY also addresses the issue of tiny mistakes. Let’s say that I duplicated the script for changing the ChassisSerialNumber, but left in the property name for the ChassisAssetTag. That would mean that your update would result in the ChassisAssetTag that you specified being applied to the ChassisAssetTag field and the ChassisSerialNumber. These types of errors are extremely common when you copy/paste/modify blocks.

Look at the line that says Change-VMSetting. That contains a fairly short bit of script that changes the properties of an object. I won’t dive too deeply into the details; the important part is that this particular function might be called up to five times during each iteration of the script. It’s only typed once, though. If I (or you) find a bug in it, there’s only place that I need to make corrections.

Internal Functions in Your Own Scripts

Notice that I put my functions into a begin {} block. If this script is on the right side of a pipe, then its process {} block might be called multiple times. The functions only need to be defined once. Leaving them in the begin block provides a minor performance boost because that part of the script won’t need to be parsed on each pass.

I also chose to use non-standard verbs “Process” and “Change” for the functions. That’s because I can never be entirely certain about function names that might already be in the global namespace or that might be in other scripts that include mine. Programming languages tend to implement namespaces to avoid such naming collisions, but PowerShell does not have that level of namespace support just yet. Keep that problem in mind when writing your own internal functions.

Undocumented Changes to Hyper-V 2016 WMI

Undocumented Changes to Hyper-V 2016 WMI

 

We all know that IT is an ongoing educational experience. Most of that learning is incremental. I can only point to a few times in my career in which a single educational endeavor translated directly to a major change in the course of my career. One of those was reading Richard Siddaway’s PowerShell and WMI. It’s old enough that large patches of the examples in that work are outdated, but the lessons and principles are sound. I can tell you that it’s still worth the purchase price, and more importantly that if this man says anything about WMI, you should listen. You can imagine how excited I was to see that Richard had begun contributing to the Altaro blog.

WMI can be challenging though, and it doesn’t help when you can’t find solid information about it. I’m here to fill in some of the blanks for WMI and Hyper-V 2016.

What is WMI?

WMI stands for “Windows Management Instrumentation”. WMI itself essentially has no substance; it’s a Microsoft-specific implementation of the standardized Common Information Model (CIM), maintained by the DMTF. CIM defines common structures and interfaces that anyone can use for a wide range of purposes. Most purposes involve systems monitoring and management. The simplest way to explain WMI, and therefore CIM, is that it is an open API framework with standardized interfaces intended for usage in management systems. PowerShell has built-in capabilities to allow you to directly interact with those interfaces.

What is the Importance of Hyper-V and WMI?

When it comes to Hyper-V, all the GUIs are the beginner’s field. The PowerShell cmdlets are the intermediate level. The experts distinguish themselves in the WMI layer. Usually, when someone incredulously asks me, “How did you do that?”, WMI is the answer. WMI is the only true external interface for Hyper-V. All of the other tools that you know and love (or hate) rely on WMI. However, none of those tools touch all of the interfaces that Hyper-V exposes through WMI. That’s why we need to be able to access WMI ourselves.

How Do I Get Started with Hyper-V’s WMI Provider?

If you don’t already know WMI, then I would recommend Richard’s book that I linked in the first paragraph. The “warning” that I would tell you on that is to not spend a lot of time learning about associators. You won’t use them with v2 of the Hyper-V WMI provider. Instead, you’ll use $WMIObject.GetRelated(), which is much easier. There are other ways to learn WMI, of course, but that’s the one that I know. Many of the PowerShell scripts that I’ve published on this blog include WMI at some point, so feel free to tear into those. Also try to familiarize yourself with the WMI Query Language (WQL). It’s basically a baby SQL.

Get a copy of WMI Explorer and put it on a system running Hyper-V. Use this tool to navigate through the system. In this case, you’re especially interested in the rootvirtualizationv2 branch. No other tool or reference material that you’ll find will be as useful or as accurate. You can use it to generate PowerShell (check the Script tab). You can also use it to generate MOF definitions for classes (right-click one). It’s a fantastic hands-on way to learn how to use WMI and discover your system.

undoc_wmiexplorer

Microsoft does publish documentation on the Hyper-V WMI provider. Starting with 2016, it is not thorough, it is not current, and someone had the brilliant idea to leave it undated so that you won’t be able to determine if it’s ever been updated. There are more than a few notes that make it worthwhile enough to use as a reference.

Do not forget search engines! If you just drop in the name of a class, you’ll find something, and often a useful something. It doesn’t hurt to include “v2” in your search criteria.

Undocumented and Partially Documented WMI Changes for Hyper-V 2016

Some of this stuff isn’t so much “undocumented” so much as unorganized. The goal of this section is to compile information that isn’t readily accessible elsewhere.

Security and the Hyper-V WMI Provider

It is not possible to set a permanent WMI registration on any event, class, or instance in the Hyper-V WMI provider. The reason is that permanent subscriptions operate anonymously, and this particular provider does not allow that level of access. You can create temporary subscriptions, but that’s because they must always operate under a named security context. Specifically, a user name.

I don’t have much more to give you on this. You can see the symptoms, or side effects if you will, of the different security restrictions. Many things, like Get-VM, don’t produce any results unless you have sufficient permissions. Other than that, you’ll have to muddle through on your own just as I have. My best sources on the subject say that there is no documentation on this. Not just nothing public, just nothing. That means that there is probably a lot more that we could be doing in terms of providing controlled access to Hyper-V functions.

What Classes Were Removed from the Hyper-V WMI Provider in 2016?

I pulled a list of all classes from both a 2012 R2 system and a 2016 system and cross-referenced the results. The following classes appear in 2012 R2 but not in 2016:

I have never personally used any of these classes, so I’m not going to miss them. If you have any script or code that expects these classes to exist, that code will not function against a 2016 system.

One retired class of interest is “Msvm_ResourceTypeDefinition”. As we’ll see in a bit, the way that virtual machine components are tracked has changed, which could explain the removal of this particular class.

What Classes Were Added to the Hyper-V WMI Provider in 2016?

The results of the previous test produced a great many new classes in 2016.

If you’re aware of the many new features in 2016, then the existence of most of these new classes makes sense. You can’t find documentation, though. If you want to see one of the shortest Google results lists in history, go search for “Msvm_TPM”. I got a whopping three hits when I ran it, with no relation to Hyper-V. After publication of this article, we’ll be up to a staggering four!

Some of these class additions are related to a breaking change from the v2 namespace in 2012 R2: some items that were formerly a named subtype of the Msvm_ResourceAllocationSettingData class now have their own specialized classes.

What Happened to the Serial Port Subtype of Msvm_ResourceAllocationSettingData?

First, let’s look at an instance of the Msvm_ResourceAllocationSettingData class. The following was taken from WMI Explorer on a 2012 R2 system:

undoc_serialportsubtypeI’ve highlighted two items. The first is the ID of the virtual machine that this component belongs to. The second is the “ResourceSubType” field, which you can use to identify the component type. In this case, it’s a virtual serial port.

I chose to use WMI Explorer for this example because it’s a bit easier to read. The following code block shows three ways that I could have done it in WMI by starting from the virtual machine’s human-readable name:

The first technique utilizes the skills of the .Net and PowerShell savvy. The second and third methods invokes procedures familiar to SQL gurus.

Now that we’ve seen it in 2012 R2, let’s step over to 2016. I have configured the above virtual machine in Hyper-V Replica between 2012 R2 and 2016, so everything that you see is from the exact same virtual machine.

To begin, all three of the above methods return no results on 2016. The virtual machine still has its virtual serial ports, but they no longer appear as instances of Msvm_ResourceAllocationSettingData.

Now, we have:

Msvm_SerialPortSettingData

Msvm_SerialPortSettingData

I’ve highlighted a couple of things in that second entry that I believe are of interest. This entry certainly looks a great deal like the Msvm_ResourceAllocationSettingData class from 2012 R2, doesn’t it? However, it is an instance of Msvm_SerialPortSettingData. Otherwise, it’s structurally identical. You can even search for it using any of the three methods that I outlined above, provided that you change them to use the new class name.

I did not find any other missing subtypes, but I didn’t dig very deeply, either.

Associator Troubles?

I mentioned a bit earlier that I don’t use associators with the v2 namespace. I have seen a handful of reports that associator calls that did work in 2012 R2 do not work in 2016, although I have not investigated them myself. If that’s happened to you, just stop using associators. .Net and PowerShell automatically generate a GetRelated() method for every WMI object of type System.Management.ManagementObject. It has an optional String parameter that you can use to locate specific classes, if you know their names.

Find everything directly related to a specific virtual machine:

Find a specific class related to a specific virtual machine:

What the tools that I’ve shown you so far lack is the ability to quickly discover associations. The GetRelated() method allows you to discover connections yourself. To keep the output reasonable, filter it by the __CLASS field (that’s two leading underscores). The following shows the commands and the output from system:

You can use this technique on the Script tab in WMI Explorer (which will run the script in an external window) and then cross-reference the results in the class list to rapidly discover how the various classes connect to each other.

You can also chain the GetRelated() method. Use the following to find all the various components of a virtual machine:

Put WMI to Work

WMI is the most powerful tool that a Hyper-V administrator can call upon. You don’t need to worry about hurting anything, as you would need to directly call on some method in order to make any changes. The Get-WmiObject cmdlet that I’ve shown you has no such powers.

If you’re willing to go deeper, though, you can certainly use WMI to change things. There are several properties that can only be changed through WMI, such as the BIOS GUID. In previous versions, some people would modify the XML files, but that was never supported. In 2016, the virtual machine file format is now proprietary and copes with manual alterations even more poorly than the old XML format. To truly sharpen your skillset, you need to learn WMI.

6 High-Impact features webinar Q&A follow-up

6 High-Impact features webinar Q&A follow-up

 

Hello once again everyone! Today I bring you the follow up post for the webinar we put on back on the 14th of February!

I’ve put together a few different items in this follow-up post. I’ve got the recording of the webinar and the questions that were asked and the ones that went unanswered in the Q & A below. Additionally, I saw many requests during the webinar for the various scripts and code snippets that I used throughout the webinar, so I’ve included those as well along with some annotation that somewhat walks you through each particular demo.

NOTE: The Script that I mentioned to automated the nested cluster deployment will be published as a separate post in the coming weeks, so keep an eye out for that.

With that said, let’s start by taking another look at the webinar!

Revisit the Webinar

Q & A

Q. Will Node Fairness adhere to host placement rules?

A: Yes. If you have preferred owner rules in place in your cluster, node fairness will adhere to those rules when attempting to load balance a cluster.

Q: Is the startup delay for start order priorities configurable?

A: Yes. There is no need to stick with the default of 20 seconds if you don’t want to. Using the Set-ClusterGroupSet with the -StartupDelay parameter will allow you to configure the startup delay.

Q: Are all the mentioned features available on the free Hyper-V Server?

A: All features covered in the webinar are available on all editions of Hyper-V.

Q: I thought it was required that each nested Hyper-V host have 4GBs of memory?

A: I’m not aware of any such requirement. All the nested hosts in my demo had a static 2GBs of memory configured.

Q: Similar to Start Up Priorities, is there a feature to Power off VMs in a specific order?

A: Not in the same sense as Start-Up Priorities where one VM requires another VM be running to boot. What you can do is create a PowerShell script that calls the Stop-VM cmdlet to stop VMs one at a time in a specific order.

Q: Does Altaro VM Backup now support Windows Server 2016?

A: Yes! Windows Server 2016 support was added as part of our version 7 release.

Q: Is ReFS file level restore now supported in version 7 of Altaro VM Backup

A: While we don’t support doing file level restores of an ReFS volume, remember that ReFS was designed primarily with Storage Spaces Direct and Hyper-V in mind. The chances of you actually having to recover an individual file on an ReFS volume are remote. However, you could take advantage of some of the new ReFS features by hosting your Hyper-V VMs on an ReFS volume. Then, as long as the file system inside of the protected VM is NTFS, you can still do a file level restore with Altaro VM Backup even though that VM is hosted on an ReFS volume. The filesystem contained within the VM is the important one.

Scripts from the Webinar

NOTE – IMPORTANT: The below code blocks aren’t meant to be executed as scripts. They simply walk you through the steps (With commenting) and needed PowerShell Cmdlets for each feature mentioned in the webinar and are *NOT* intended for production use. They are simply intended to be informational.

Fixed VHDX Creation Demo

Start Order Priorities Demo

PowerShell Direct Demo

Nested Virtualization Configuration

Wrap-Up

That wraps things up for this webinar!

As always, if you have any further follow up questions feel free to use the comment form below and I’ll be sure to get back to you ASAP.

I hope these resources have been helpful!

Thanks for watching!

Nagios for Hyper-V: Alert on Failed Quorum

Nagios for Hyper-V: Alert on Failed Quorum

 

The health of a Microsoft Failover Cluster’s quorum leans most heavily on the state of the nodes. If you’re already using Nagios to monitor individual node states, then you’ll find out very quickly if any of them are down. Sometimes, though, the witness goes offline. If you haven’t got a monitor on that, then you can run into other problems. For instance, you may opt to manually pause a node for maintenance. If the witness is already down, the loss combination might cause the entire cluster to go offline. This article presents a short Nagios detection script for the status of your quorum witness.

This script is useful for any cluster, not just Hyper-V clusters.

If you’re new to Nagios, then you should probably start with the How To: Monitor Hyper-V with Nagios article first. I did publish a follow-up article with a script with some base functions for a cluster, but that script is not required to use this one.

NSClient++ Configuration

These changes are to be made to the NSClient++ files on all Windows nodes that are part of the cluster to be monitored. These instructions do not include configuring NSClient++ to operate PowerShell scripts. Please refer to the aforementioned how-to article for that.


C:Program FilesNSClient++nsclient.ini

If the indicated INI section does not exist, create it. Otherwise, just add the second line to the existing section.

The NSClient++ service must be restarted after all changes to its ini file.


C:Program FilesNSClient++scriptscheck_clusterquorumwitness.ps1

Create the file with the following contents:


Nagios Configuration

These changes are to be made on the Nagios host. I recommend using WinSCP as outlined in our main Nagios and Ubuntu Server articles.


/usr/local/nagios/etc/objects/commands.cfg

The Hyper-V Host Commands section should already exist if you followed our main Nagios article. Add this command there. If you are not working with a Hyper-V system, then you can create any section heading that makes sense to you, or just insert the command wherever you like.


/usr/local/nagios/etc/objects/hypervhost.cfg

This file and section were created in the Hyper-V base scripts article. As long as it appears somewhere in one of the activated .cfg files, it will work.

This is a sample! You must use your own cluster name object! If you have multiple clusters to monitor, remember that you can place them into a Nagios hostgroup. You can then apply this service to the group rather than the individual cluster name objects. Do not assign the service to the nodes! The monitor will still work, but it’s inefficient and failures will result in many duplicate notifications.

Nagios must be restarted after these files are modified. Remember to run these separately. Do not just copy/paste! If the first command indicates a validation failure, check your work and fix the problem before restarting the Nagios service!

Client Hyper-V in Windows 10

Client Hyper-V in Windows 10

 

Windows 8 introduced the first incarnation of Hyper-V for the desktop. It’s the same core hypervisor as the Hyper-V that ships with the server SKUs, minus a few features. Like its big brother on the server side, Windows 10 brings several new features to the desktop.

What is Client Hyper-V?

Client Hyper-V is an edition of Hyper-V that is geared toward desktop environments that could be thought of as “Hyper-V Lite”. It shares most of Hyper-V’s features and even brings some of its own. Highlights:

  • Type 1 hypervisor: A type 1 hypervisor is a complete kernel and performs direct hardware control. This means that when you enable Hyper-V in Windows 10, the physical hardware boots to Client Hyper-V, not your root Windows 10 installation. Client Hyper-V then starts up your pre-existing root Windows 10 environment as the management operating system. A management operating system is known as the “root partition” or “partition 0” or the “parent partition” in other hypervisors’ terminologies. It is a virtual machine, but it also has the special ability to exert control over the hypervisor. Contrast this with type 2 hypervisors, which are applications that run inside a normal host operating system and do not have direct access to hardware nor any control over the management operating system. Almost all other desktop-oriented hypervisors are type 2.
  • Guest interaction: Interoperability with guest operating systems is a crucial component for a desktop-oriented hypervisor. Client Hyper-V offers:
    • Sharing and mapping of most host hardware
    • Copy/paste of files from host-to-guest and vice versa (supported guests only)
    • Copy/paste of clipboard content from host-to-guest and vice versa (supported guests only)
  • RemoteFX: Windows 10 brings support for some RemoteFX features into Client Hyper-V. Most importantly, the full functionality of your graphics adapter will be made available to guests for both 2D and 3D acceleration.
  • Connected Standby: If your management operating system goes to sleep, your guests will be OK. When you resume, they will be exactly where they left off.
  • Linux guests: Client Hyper-V directly supports the same guest operating systems that Hyper-V does. This does not necessarily exclude other Linux distributions, but your mileage may vary.
  • Fully virtualized environment: That phrase could be taken to mean a great many things, but what I mostly intend to convey is that whether or not a specific operating system is directly supported as a guest does not indicate whether or not it will function. Hyper-V’s virtual machines are complete x86/AMD64 environments. If an operating system would otherwise run in that environment (most importantly, on your physical CPU’s architecture), then it will almost certainly operate under Hyper-V. Without direct support, however, it may run poorly.
  • Secure environment: Client Hyper-V provides the same security offerings as Hyper-V:
    • Secure boot: If Client Hyper-V doesn’t recognize the boot signature in the guest operating system, it won’t start it. This provides solid protection against root kits.
    • Shielded VMs: The topic of Shielded VMs is very large and won’t be covered in detail in this article. Microsoft’s Windows Server blog has decent starter material on the subject. Essentially, if you are concerned that someone copying the files of your virtual machine to their own local machine is of concern, you have options.
  • Storage Live Migration: You can move a virtual machine from one physical storage location to another without taking it offline.
  • Run VMs from remote storage: Your virtual machines can be stored locally, which is the most typical configuration. You can also run virtual machines from SMB and iSCSI storage.
  • Full-screen support: You can run Client Hyper-V guests within a window, allow them to consume an entire screen, or have them consume all screens on a multi-monitor system. Unfortunately, there is no native way to use only a subset of screens in a multi-monitor setup.
  • Nested virtualization: Need to test detailed environments on Client Hyper-V? No problem! As long as you’ve got sufficient hardware, you can run Hyper-V and Client Hyper-V within Hyper-V. The software does not impose any limitations on depth.
  • Containers. Hyper-V Containers are also available with Client Hyper-V.
  • Network Address Translation in the virtual switch. One place that Microsoft’s desktop hypervisor has consistently lagged behind the competition is its guest networking capabilities. One thing that it has sorely lacked is the ability to perform NAT operations for guests. That meant that you had to have an available IP address on the existing network for each Client Hyper-V guest. Client Hyper-V in Windows 10 will provide network address translation (NAT) services for its guests. This especially comes in handy when you’ve got a wireless adapter that just won’t work with the virtual switch.

What Features does Client Hyper-V Lack in Comparison to Hyper-V?

Most of the features that are “missing” in Client Hyper-V are not especially useful in a desktop-oriented hypervisor environment anyway.

  • Live Migration and Shared Nothing Live Migration: Windows 10 can’t be clustered, so it’s only natural that Live Migration wouldn’t be supported. Shared Nothing Live Migration would have its uses, but it’s not available.
  • Hyper-V Replica: Windows 10 can’t participate as a member in Hyper-V Replica. This particular feature is intended for server-side disaster recovery, so it makes sense that it’s not available in Client Hyper-V.
  • Advanced networking functionality: The only advanced networking available for Client Hyper-V guests is NAT. There is no teaming in the host, not the standard LBFO configuration or switch-embedded teaming (SET).
  • Advanced hardware functionality: virtual fiber channel and some SR-IOV features are not available. The hardware that these features apply to are almost never found in desktop-grade equipment.

Licensing and Client Hyper-V

We’ve produced extensive work around licensing and Hyper-V with articles, eBooks, and webinars. None of them have meaningfully touched on Client Hyper-V. Simply put, a Windows 10 license provides for exactly one instance, period. It does not contain any guest instance rights whatsoever. If you want to run a guest instance of Windows 10, then you must purchase another license to cover that instance. If you wish to run any Windows Server guests on Windows 10, you must license the hardware to cover those instances in accordance with the new per-core rules. Linux distributions will follow their distributors’ rules.

Uses for Client Hyper-V

The benefits of server virtualization are quite clear. They generally center around the fact that server hardware is typically underutilized. That’s usually not the case for client hardware. Desktop and laptop computers don’t usually have as many resources as server computers before you consider cutting them up. CPU is usually the only resource with significant capacity to spare, and even that doesn’t have much availability for some users. So, why would you want to split up limited resources on your desktop system? Here are a few reasons:

  • Software development: Software developers have many reasons to use virtualization.
    • Sandbox environment: If you’re writing systems-level programs, it’s usually not a good idea to allow a bug to cripple the computer that you’re developing on. Checkpoints and kernel isolation alleviate this concern. I particularly like using virtual machines for developing Windows installer packages. Recent versions of Visual Studio rely on Client Hyper-V for testing mobile device applications.
    • Multi-OS targeting: Whatever version of Windows you’re running, almost no developers can guarantee that their users will have the same. Having virtual machines on your desktop allow you to quickly verify that your application runs the same on different operating systems and different bitnesses (32- vs. 64-bit).
  • Systems administration: Systems administrators have many uses for virtualization on the desktop, even though many suffer in silence without realizing that there are solutions to many of their daily headaches.
    • Proper security levels. You know that you are supposed to run in a lowered security environment so that your administrative account isn’t signed in all of the time. You also know that it’s much easier to say than it is to do, especially since even some of Microsoft’s tools don’t work appropriately with Run As. Using virtualization on your desktop allows you to be signed in with multiple accounts simultaneously without the headaches of Run As.
    • User access testing. Another oft-overlooked usage is testing privilege levels for non-administrative accounts. For instance, you can create a test account with the same membership as one of your domain users to test that account’s ability to connect to certain resources. Run As can only take you so far. Logging into a virtual instance with alternative credentials without interrupting anything else that you’re doing is an invaluable capability.
    • Application testing. Software developers may test their software to some degree, but you need to know how it’s going to interact in your environment before pushing it out to your users.
  • Security operations: A virtual machine provides a great many opportunities for information security workers:
    • Sandbox environment: If you’re not certain if something is malicious software, build an environment that it’s free to destroy. Virtual machines present a wonderful walled garden. You can place suspect material inside a VHDX, mark it read-only, then attach it to your checkpointed test virtual machine. If it turns out to be malicious, you can revert the checkpoint or just delete the virtual machine outright.
    • Penetration testing: Build a duplicate of your production environment inside Client Hyper-V instances and hack away. Obviously, there are cons as well as pros to testing against a duplicate of your production environment instead of the actual environment, but this is a good place to start.
    • Forensics labs: Most computer forensic tasks need to be performed on the impacted system(s), but sometimes you need a place to tear into a chunk of code or a data file. Virtual machines provide the perfect environment.
  • Down-level environments: Windows 7 Pro and Enterprise shipped with “Windows XP Mode”, a pre-built Windows XP environment that ran under the built-in Virtual PC type 2 hypervisor. We lost that free virtualized instance along with Virtual PC in Windows 8, but Client Hyper-V still provides the base capability to run down-level operating systems. Unfortunately, Windows XP isn’t on the supported list for Client Hyper-V in Windows 10, but it does work (slowly). Between the defunct Windows XP and the current Windows 10 are four versions of Microsoft’s desktop operating system. There are any number of reasons that you might need one of those environments, at least on a part-time or temporary basis. Client Hyper-V might be exactly what you need.
  • Demonstrations: If you need to demonstrate software or software environments and your simple laptop instance isn’t adequate, you can build very complex structures within Client Hyper-V for use on the road.

Client Hyper-V Requirements

With Windows 10, Client Hyper-V and the server-based Hyper-V have the same hardware requirements. Client Hyper-V is not available in every Windows 10 SKU.

  • Windows 10 Professional, Enterprise, or Education editions. Windows 10 Home edition does not contain Hyper-V, nor do any of the various mobile SKUs.
  • Hardware-assisted virtualization. Intel calls it “VT-x”, AMD calls it “AMD-V”. Most BIOSs usually just have a simple option to enable virtualization features. This technology has been commonplace for long enough that most functional systems will support it.
  • Data execution prevention. An old malware technique involves placing malicious code into a data segment and then directing the CPU to execute it. Data execution prevention forces the system to rigidly respect data segments as not being executable. Intel calls theirs “XD” and AMD calls theirs “NX”. Microsoft unifies them as “DEP”. BIOSs will have various labels that are generally easy to identify. This technology also enough years to be ubiquitous. It’s also typically enabled by default, so you can almost always simply expect it to be present.
  • 4GB of memory. I’m not certain if there is a hard check in place for this condition, but your experience would likely be fairly miserable if you’ve got less.
  • VM Monitor Mode extensions. Intel names theirs “VT-c”. I don’t believe that AMD has any particular name for it. This is a new requirement over Client Hyper-V in Windows 8.x. Even though the name is somewhat foreign to many people, you usually won’t have difficulty providing it. It’s not quite as common as DEP and hardware-assisted virtualization, though. If Client Hyper-V won’t run on your system, this might be why.
  • Second-level Address Translation. Second-level Address Translation (SLAT) has been commonplace on CPUs for several generations. It has always been a requirement for Client Hyper-V. It is an always-on native feature of CPUs and there is no activity to enable or disable it. Check your CPU’s specification sheet to determine if it has SLAT support.
  • (For nested virtualization) Intel VT-x and EPT technology. I don’t know the technical (or perhaps political) details, but AMD users are not welcome in Hyper-V’s nested virtualization world. You need an Intel chip with these technologies available and enabled.

You can quickly and easily verify if you can run Hyper-V on your current system by opening an elevated command or PowerShell prompt and running systeminfo . Look toward the end of the output for the following section:

System Info Hyper-V Check

System Info Hyper-V Check

 

Enabling Client Hyper-V

Client Hyper-V ships as a Windows 10 component, so you don’t “install” it, per se. You enable it.

  1. Right-click on the Start button (or press Win+[X]) and select Programs and Features.
    WinX Menu

    WinX Menu

     

  2. In the Programs and Features window, click Turn Windows features on or off. If UAC is on, you’ll need to confirm switching to administrative mode.
    Programs and Features

    Programs and Features

     

  3. Choose the Hyper-V options that best suit your intent. The only required item is Hyper-V Hypervisor but it will be difficult to do anything with if you don’t enable the other components as well.  This article isn’t going to discuss Containers, but those are enabled here as well, as shown in the screenshot.
    Client Hyper-V Features

    Client Hyper-V Features

     

  4. After clicking OK, you’ll need to restart the computer.

Fewer steps are required to enable Client Hyper-V in PowerShell. In an elevated prompt:

If you’re looking to install a subset of the components from within PowerShell, our earlier article has greater detail.

Using Client Hyper-V

I want to reiterate that, as a type 1 hypervisor, Client Hyper-V is always running. You do not need to start the hypervisor and there is no service that you can go look at or start or stop. There is the Hyper-V Virtual Machine Management service (VMMS.exe), but, as its name explicitly states, it is a management service. Without it, you as the administrator cannot interact with Client Hyper-V, but it is still there and doing its job.

Management Tools

There are three built-in tools that you’ll use to interact with Client Hyper-V:

  • PowerShell. PowerShell is the most thorough way to manage with Hyper-V. You can start it within an elevated standard command prompt by typing PowerShell and pressing [Enter]. I tend to dig it out of the Start menu and pin it to the taskbar.
  • Hyper-V Manager. Hyper-V Manager is not as robust as PowerShell for management, but it is adequate. It is also helpful for connecting to virtual machines’ consoles. Hyper-V Manager can be found in Administrative Tools. I tend to pin this to the Start menu. You must Run As Administrator if you are logged in with a non-administrative account.
  • Virtual Machine Connection. This tool can be invoked within Hyper-V Manager by right-clicking on a virtual machine and clicking Connect. You can also enter vmconnect into any elevated prompt (including the Cortana local search). You will need to Run As Administrator. Once it opens, you can pick the virtual machine that you want to connect to from the drop-down.

It’s worth reiterating that you must always interact with Hyper-V using elevated prompts or graphical applications opened with Run As Administrator. VMConnect is kind enough to tell you when you don’t have sufficient permissions, but most other tools will be silent. For instance, running Get-VM as a non-administrator will simply return nothing, even when virtual machines are present and operational. Hyper-V Manager’s virtual machine list will also be empty.

Configuring Client Hyper-V

I’m not going to take you through every option available for Client Hyper-V, but I’m going to touch on the biggest points. Client Hyper-V works perfectly well immediately after you enable it and reboot, so it’s really just a matter of putting a few final touches on it.

To get started, open up Hyper-V Manager. In Windows versions past, you could simply open the Start menu and start typing “Hyper-V Manager” and after a few keystrokes, the built-in search tool would find it. This still works for most people, but many have encountered a bug where Cortana struggles to find things on the local computer. That went away for me after a few updates but the suggestions that I found to fix it directly did not work for me. If you find the “Windows Administrative Tools” group in the Start menu, Hyper-V Manager is there. I suggest pinning it to the Start menu or something similar so that you can easily reach it later.

Once you have Hyper-V Manager open, it should already have your local computer selected. Right-click on it and click Hyper-V Settings. If that option isn’t available, you didn’t Run as administrator.

A screenshot of the window that you’ll see is below. I’ve changed it to the Physical GPU tab so that you can see that RemoteFX is functioning and has automatically selected the video adapter. Sift through the other tabs and check that items are set as you expect. Feel free to change things as suit your needs. I would recommend keeping Enhanced Session Mode enabled everywhere you find it, or you’ll lose some host/guest interaction capabilities with your virtual machines. If you’re not certain about a setting, the best thing to do is leave it alone.

Basic Configuration

Basic Configuration

 

Once you’re finished there, right-click on the local computer again and click Virtual Switch Manager. Make certain that, on the right side, the selected type is External and click Create Virtual Switch.

Starting Virtual Switch Manager

Starting Virtual Switch Manager

 

Set the following options on the new virtual switch page:

  • Name the virtual switch. There is no need to get fancy with this. Use something that you can remember and that you can type. Future you will thank you.
  • Next to the External network dot, choose the physical network adapter that will host the virtual switch. You may need to look in your network adapter list if it’s not obvious which is which.
  • Unless you have multiple virtual network adapters, leave Allow management operating system to share this network adapter. If you don’t, the physical adapter that you choose will be able to connect virtual machines to the physical network, but you’ll have to manually create a virtual NIC for the management operating system (that’s the Windows 10 installation that’s running Client Hyper-V) to continue using the physical network (or come back in here and check the box).
  • If your management operating system currently participates in a VLAN, check the Enable virtual LAN identification for the management operating system and enter the necessary VLAN ID in the text box. If you’re at home using regular home networking equipment, you’ll definitely want to skip this box. If you’re connected to commercial-grade equipment at work and don’t already know what to do, it’s highly likely that you will skip this configuration. Otherwise, talk to your network administrator.
Virtual Switch Manager

Virtual Switch Manager

 

When you’re done with setting up the virtual switch and you OK out, you might lose connectivity for a few moments while the networking settles down. It needs to recreate your networking stack on a new virtual adapter, so expect that to take a bit of time.

If you connected to a wireless network adapter, you might face some difficulties. You wouldn’t be the first. I do not personally have much expertise in addressing these problems but your odds of finding suitable resolution are not great. Usually, it either works in the beginning or it never works at all. You can try updating drivers. If you just can’t get it to work, never fear! You can follow the steps in the next section to create a NAT network so that you don’t need a virtual switch on top of the physical adapter.

Configuring NAT Networking in Client Hyper-V

This process has changed several times since the feature was introduced in a technical preview of Client Hyper-V and a lot of the currently available instructions are wrong. Even Get-Help for New-VMSwitch shows options that don’t work. The following instructions were tested and known good for Client Hyper-V on Windows 10 build 14393.447 (run “winver” from the Start menu).

As with many things in Windows, there is more than one way to make this all happen. There is only a single step that absolutely requires PowerShell, which means that I’m going to counsel you to do the whole thing in PowerShell. You can do all the other steps in the GUI if you prefer. So, I’ll start with a basic outline of the steps, then I’ll show you the PowerShell that can make it happen:

  1. Determine what network range you want your NAT network to be. You only get a single NAT network on a Client Hyper-V system.
  2. Create an internal virtual switch.
  3. On the management operating system’s adapter for the internal virtual switch from step 2, assign an IP that will function as the router IP on that network that you thought up in step 1.
  4. Create the NAT network (PowerShell only).
  5. Attach virtual machine(s) to the virtual switch that you created in step 2 on the network that you created in step 1 using the IP that you assigned in step 3 as the router.
  6. Assign IPs from within the guest operating systems.

Be mindful of step 6. Client Hyper-V does not contain a DHCP server and will not distribute addresses for that NAT network. In case you were about to ask, no, Client Hyper-V does not support DHCP relay, either. You must either create a virtual machine running DHCP in that network or you must manually assign IPs. I’d go with the latter.

Here are steps 2-4 in PowerShell for the network 192.168.100.0/24 (192.168.100.1 through 192.168.100.254):

The first line creates an internal virtual switch named “vSwitchNAT” (could be done in Hyper-V Manager, as you saw above). An internal switch allows the host operating system and guest operating systems to use the same virtual switch, which, by definition, means that a virtual adapter will be automatically created for the management operating system. When such a virtual adapter is automatically created, its name is always in the format of vEthernet (name of the virtual switch), so I know that this one will be named “vEthernet (vSwitchNAT)”. If you name your virtual switch differently, use that name on your second line. I have also decided to pick the first valid IP in the network that I created, hence the 192.168.100.1 (this could be done in network connections). Note that I do not give it any routing information, such as a default gateway. The third line creates the NAT network. It will see the adapter with IP 192.168.100.1 and automatically treat it is as the router for that network.

Now, I just need to connect virtual machines to it. On the properties for a virtual machine, I do exactly that:

Select NAT Switch

Select NAT Switch

 

I finish up by accessing the guest’s networking and giving it an IP on that network and using the host management adapter as the default gateway:

NAT Client IPv4

NAT Client IPv4

 

NAT in Windows 10 has more capability than what I’ve shown you, but this should be enough for most. Start on the NAT PowerShell page for more information.

Continuing On…

There are a great many other things that I could show you, much more than would fit in a simple blog post. If this is your first time using Client Hyper-V, or any Hyper-V, spend some time kicking the tires. Begin by right-clicking your host in Hyper-V Manager and clicking New and Virtual Machine. The wizard should be easy enough to follow. Once your new VM is created, right-click on it and click Connect. That’s VMConnect. You’ll find the start and stop controls. You’re now on your way to being a Client Hyper-V guru!

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.

Page 1 of 812345...Last »