The Processor option is used to set the number of virtual CPUs and the CPU type.   The latter sure is confusing, and according to the online help:

These settings do not specify actual hardware, however, VMM uses these settings to calculate host ratings and to set CPU resource allocation.

VMM, not Hyper-V, uses that CPU type for something, but it does not sound like resource management of running VMs.  I suspect this is limited to the intelligent placement feature, the one-time recommendation of a host when provisioning or migrating a VM.

The Priority option looks like CPU shares on VMware ESX –  a means of specifying which VMs will receive priority when there is contention for resources.

As far as I can tell, there are no more CPU resource settings available in SCVMM.

It turns out that with Hyper-V Manager, the other single pane of glass, it is possible to set CPU reservations and limits for individual VMs:

It’s hard to understand why this configuration option did not make it into the SCVMM administrator console, which is supposed to be a panacea for “physical and virtual management.”  Virtualization administrators that need to control VM CPU resources are forced to open another management tool in order to do so.  (And that other utility does not run on Windows XP, by the way.)

Not only do VMware VI3 administrators have a single client for managing all aspects of their hosts and virtual machines, they have something else: resource pools.  Why manage resources for individual machines when you can place them in containers that partition CPU and memory from an entire hypervisor farm?

No experienced administrator would make a practice of applying permissions to individual user accounts instead of a group.  That doesn’t scale and just increases your OpEx.  Why not expect the same maturity in your VM resource management?

Related posts:

1. Don’t know much about resource pools
2. New: vSphere Resource Distribution Chart
3. Managing VI3 with SCVMM considered harmful
4. Network World weighs in on SCVMM-VI3 Management

The resource pool is a means of partitioning CPU and memory, and it is also convenient for configuring access control.  Let’s say you have a DRS cluster with a resource pool for your web QA team.  When a QA engineer logs in with VI Client, he sees only the virtual machines that he has permission to access.

Now, let’s say that one of your fellow administrators wants to use SCVMM to manage this VMware environment.  He uses the SCVMM console to migrate a QA virtual machine from one ESX host to another in order to perform maintenance.

The VMotion completes without incident and everything seems OK…

Before too long, a QA engineer is on the phone asking what happened to his VM.  From his perspective, the VM has disappeared.

It’s not really gone, it has just been moved out of the resource pool.  Fortunately, you can log in with the VI Client and fix this problem by moving the VM back to the resource pool.

Do you really think that SCVMM is going to be your single pane of glass for virtualization management?

Related posts:

1. Managing VI3 with SCVMM considered harmful
2. VM Resource Management: Hyper-V versus SCVMM
3. SCVMM Damage Control
4. SCVMM ignores own plank, emphasizes VirtualCenter’s speck