Hyper V Core Assignments

before you poo-poo Hyper-V
heh. poo poo... I got a kick out of that.

Not sure why you think that's what I'm trying to do.
I would expect you to run the identical tests using ESX server, XenServer, VirtualBox, Oracle VM, VirtualIron and any other hypervisor that you can find.
Not sure why you think this is a Hyper-V vs ::whatever:: , either. I haven't even mention any other hypervisor. No trolls here, please look under a different bridge.
In regards to your threads moving, the virtual processors can only move when an exection finishes.  If CPUBrurn runs as a constant thread load (never pausing, never burping, never resting) then the virtual process will never cycle to another processor.  Thus the process will never be allowed to be passed to other cores.
I do suspect that the way CPUBi works is affecting my results (I mentioned that before). If what you say about "constant thread load " is true then it kind of explains what I'm seeing.

However every single instance of CPUBi was opened a few minutes apart from each other. I find odd that when a new CPUBi process was open it didn't get move automatically to a different Logical Processor by Hyper-V.

One possibility is that Hyper-V by default only assigns "x, y and z LP " to each VM, and data gets move to a different LP only when it stops or goes idle for a second. Anyone knows if this is how it works?

Anyway, the next test I'm doing involves running tons of processes with a small CPU footprint. I'll make sure to add a pause/stop here and there.
I am having a difficult time understanding what you are trying to accomplish.  What the desired outcome is?  What you are attempting to discover or demonstrate.
One thing and one thing only:

I have a Hyper-V Server with 16 LPs, if I install a single VM... Will this VM access ALL 16 LPs "at the same time " if it's required? Or is this VM only going to be able to access some of the LPs?

So far it looks like my VM is only able to access 7 LP out of 16 at once. Processes with a smaller CPU footprint may yield a different result. We'll see.
I have no idea why you think that you are unable to virtualize a Terminal Server.
I have no idea why you think I think that.
You will never acheive the same density of users on a virtual Terminal Server that you have on a physical server
I did mention on a previous post that I do not expect the VM to have the same performance as a baremetal installation. But I do not expect the 50% performance hit I've seen so far, either.
From my personal experience of virtualizing Terminal Servers, in the end it comes down to the applications that are running within the users, session, and how that application behaves.
That's true for any Terminal Server, not only the virtualized ones :)
Don't discount it until you actually virtualize a terminal server and load test it with the real applications.
I haven't! The goal is to gain the redundancy that having two Hyper-V servers offers, but at the end of the day performance > redundancy (See my second post)


The burdens of managing security permissions are rarely seen as exciting, but they're an essential duty to which...

we systems administrators are sworn to carry out. In this tip, I'll talk about how you can configure and manage permissions for your Hyper-V host servers.

We all rely on a variety of different security methods to ensure that only authorized users can access data center resources. Specific components of overall security range from physical access limitations to network authentication and permissions management. Virtualization brings with it some new requirements, namely the ability to specify which types of actions users can take on host systems.

It's certainly possible for administrators to manage virtual machines when they don't have access to the guest OSes themselves. The ability to granularly define authorization rules is essential for production servers. Fortunately, Hyper-V provides methods for defining and maintaining these permissions. But, as you'll soon see, it's not an entirely intuitive approach.

Default permissions in Hyper-V
By default, Hyper-V is configured to allow members of the local server's administrators group to have full permissions on the Hyper-V installation. In domain environments, individuals that are members of the domain admin's group will, by default, have full permissions to create and manage VMs on host servers. Members of the users group have a much more limited set of functions, including connecting to and starting virtual machines.

While these default settings might work well in smaller environments and for test labs, it's often necessary to grant additional permissions – such as the ability to start and stop VMs – to other users who should not also have full administrative permissions. Let's look at how that's done.

Introduction to Authorization Manager
Unless you have specifically looked for this information, the way in which you assign permissions on Hyper-V servers might not be apparent. You can't, for example, simply right-click on a host server or VM object and set permissions in a properties page as you could with a file system folder. Authorization Manager, also known as AzMan (not to be confused with Cosmo Kramer's infamous license plate on Seinfeld), is the primary method for defining and managing permissions for Hyper-V.

Authorization settings can be stored in XML files (the default for new Hyper-V installations), or within the Active Directory domain database. The default location for the permissions settings is in the following path: %ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.xml. If you're planning to make changes to the settings, I highly recommend you create a backup (just make a copy of the initial configuration file and store it someplace safe).

Using Authorization Manager
Windows Server 2008 does not include an Administrative Tools shortcut for accessing the Authorization Manager, so you'll have to add it manually. To access the AzMan Snap-In on full installations of Windows Server 2008, follow these steps:

  1. Click Start  Run and then type MMC and press Enter. This will launch a new, default Microsoft Management Console (MMC) shell.
  2. To add Authorization Manager, Add/Remove Snap-In from the File Menu. Select Authorization Manager and then click the Add button. Note that you can also include other snap-ins, such as the Hyper-V Manager, the Services applet, and anything else you tend to use often.
  3. By default, AzMan is not connected to any specific security data store. To access the default Hyper-V settings, right-click on the Authorization Manager object and select Open Authorization Store. Select the XML File option and then browse to %ProgramData%\Microsoft\Windows\Hyper-V\InitialStore.xml. Note that you can also access security settings that are stored in Active Directory or in a SQL Server database.
  4. At this point, you can save this new MMC view by selecting the Save As option in the File menu. This will allow you to quickly access Authorization Manager from the Administrative Tools program group (or wherever else you choose to save it).

At this point, you're ready to start managing settings.

Managing role assignments
Authorization Manager uses a role-based permissions model that should be familiar to anyone who is used to managing security in Windows. The first stop on our guided tour of Authorization Manager is the single default role assignment called Administrator (see Figure 1).


Figure 1: Accessing role assignments using AzMan

Despite the name, it's important not to confuse this role assignment with a built-in Windows or Active Directory user or group. To give non-administrator users full permissions on Hyper-V, simply right-click the Administrator object and select "Assign Users And Groups". Note that you can add Windows security principals, or AzMan roles (which I'll mention later in this tip).

Creating role definitions
Often, you'll want to allow specific users to perform a limited set of operations on a Hyper-V server. To do this, you should start by creating new role definition objects. Each role definition can include a set of permissions that apply to members of the role. Figure 2 shows the default operations options that are included with Hyper-V.


Figure 2: Viewing available operations for new role assignments.

The names of most of them are self-explanatory and should meet most security admins' needs. A few checkmarks are all that is needed to, for example, create a role that allows for creating, starting and stopping VMs without permissions to manage virtual network and other server settings.

Other AzMan features
Despite its seemingly basic user interface, Authorization Manager allows you to perform many other security-related features. I won't go into these in depth, but here's a sample of some of the options:

  • Creating tasks: While Hyper-V does not include any Tasks by default, you can create your own set of operations that define which types operations can be performed. We already saw the list of built-in operations which will meet most basic security needs. However, the Tasks approach provides a quick and organized method of defining groups of settings based on the needs of your organization.
  • Managing scopes: By default, permissions will apply to the entire Hyper-V server. But what if you want specific users to have control over specific VMs? Scopes allow you to define specific objects to which permissions apply so you can, for example, allow a user to start and stop only test/development VMs.
  • Application groups: If you find that you're often assigning the same permissions to a specific group of individuals, you can define Application Groups within AzMan. Using these groups, you can avoid having to create Windows or Active Directory groups, while efficiently managing permission assignments.
  • Auditing: You can enable auditing of changes to AzMan-based security settings to keep track of when permissions are changed. Of course, you can also manage which users have access to make changes to security settings using AzMan.
  • Scripting and automation: You can use VBScript, JScript, and/or Windows PowerShell to automate the creation and management of security permissions. This is especially helpful if you need to propagate changes to a large number of host servers.
  • Summary
    The process for managing Hyper-V permissions isn't something that you're likely to stumble upon by accident and it might seem rather arcane at first. Using AzMan requires numerous steps (at least the first time you access it). What it lacks in intuitive appeal, though, Authorization Manager makes up for in security-related flexibility. Using this tool, you can define which users have permissions to which operations and actions – an important aspect of managing production virtualization host servers. Remember, I never claimed that security was exciting, but that doesn't make it any less necessary.

    About the author:Anil Desai is an independent consultant based in Austin, TX. He specializes in evaluating, implementing, and managing IT solutions. He has worked extensively with Microsoft's Server products and the .NET development platform and has managed environments that support thousands of virtual machines. Anil is an MCITP, MCSE, MCSD, and MCDBA, and a Microsoft MVP.


Leave a Reply

Your email address will not be published. Required fields are marked *