At the office, I use Microsoft System Center Virtual Machine Manager 2008 R2 to manage a few dozen Hyper-V servers hosting around 150 virtualized services. SCVMM allows me to manage all the servers across different high-availability clusters and physical locations easily from a single console, and also facilitates users managing their own virtual machines through the Virtual Machine Self Service portal, a nice web front-end to the management interface that doesn’t require the desktop console to be installed.
In order to allow a virtual machine to be managed by self-service, that virtual machine must be assigned an owner through its properties. This is typical for Active Directory-integrated services and objects such as managed Virtual Machines – but comes with a quirk that makes it almost useless, at least in my company’s needs.
Shown above, the virtual machine’s owner is assigned to a domain universal security group. This is also a very common configuration, supported by other Microsoft products: assigning ownership of a resource to “Engineering”, and adding members to the “Engineering” group allows all the users in the group to access that resource.
Unfortunately, SCVMM doesn’t correctly handle security groups. Assigning a virtual machine to a group is a valid assignment – but prevents that virtual machine from being managed, because the group does not have a valid “group login” to use (you use your own logins in a security group, and the Active Directory manages permissions for that group) and SCVMM blocks transitive ownership to the group members. In other words: unlike every other Microsoft product, a member “Bob” who is a member of the “Server Access Group” will not be able to manage a virtual machine whose ownership is assigned to that very same group. The correct behavior, would be to allow every member of the group to manage every virtual machine associated with that group. It’s frustrating finding out that you cannot assign a virtual machine to a security group and have it work, but even more-so because it doesn’t follow the behavior of every other similar product.
In my company, we have a stack of application servers that are self-administered by some of our software engineers to break as often as they want while testing early builds of our application. It makes sense to allow any of them the ability to manage the virtual machines at a hardware level, but because of the broken group mechanics, it would have been impossible to do this and I’d have needed to pick a single engineer for the task. Because that would unfairly load one individual, I tend to handle most virtual machine maintenance myself using the console. The self-service portal sits idle.
A new service pack for SCVMM is due out shortly (following up on Server 2008 R2 SP1 which introduced important new features into Hyper-V), hopefully it will address this glaring oversight.