Introduction to Microsoft’s Private Cloud with System Center 2012

With System Center 2012, Microsoft introduces data center administrators to their solution for hosting and administering private clouds.

Private clouds are an abstraction of all of the hardware that already exists in your data center: servers, clusters, networking, and storage, but they’re more than just a collection of hardware. Private clouds allow a faster delivery of services, and a more categorical approach to your datacenters and your method of delivering services. You can span geographies with a single private cloud, or you can have multiple clouds located in the same datacenter.

Private clouds leverage 4 concepts in making the whole cloud function correctly:

  • abstraction
  • heterogeneity
  • access
  • control

Each one plays a part in how your private clouds will function.


You can abstract the hardware in your datacenters into logical private clouds.

Using Microsoft System Center 2012, you can create private clouds which are built upon hosts running Citrix XenServer, VMware’s ESX, and Microsoft’s Hyper-V. The private cloud acts as a common fabric which runs throughout the cloud, and makes it possible to run applications all together.

Private clouds are logical, not physical. The hardware that goes into making the cloud is not the cloud itself. Instead, you can have hardware that serves multiple clouds, and clouds that span multiple hardware and even multiple datacenters in geographically diverse locations.

For instance, if you had 2 datacenters on opposite sides of the world, and you wanted SharePoint servers in each datacenter, you can have a private cloud which encompasses both of those datacenters. The administration of the VMs in your SharePoint farm, even if they are in separate datacenters, and even if those datacenters are running different hypervisors (VMware and Citrix), can all be administered by using System Center Virtual Machine Manager 2012.

Your VM hosts are not going to be the only thing abstracted, either. You will also abstract your storage and your networks.


There are already infrastructures from different vendors in place. You can keep it all because of heterogeneity.

Yes, your private clouds can include VMware, Hyper-V, and XenServer farms — at the same time, and in the same cloud. The app fabric takes care of all of the coordination between the different VM platforms, and so when one of your customers requests a new server they are not presented with options to select which platform it is installed on. After all, what your customers demand is processors, RAM, networking and an operating system, not which vendor OS the datacenter is operating on.

You may have a service ready to deploy onto a Hyper-V server. With System Center VMM 2012 and private clouds, you don’t have to do anything differently to deploy the service onto a VM run on the Citrix or VMware servers.

There is the ability to import the templates from a vCenter server into System Center VMM library. Technically, it does not actually copy the VMDK files into the VMM library. It stores the data for the VM, leaving the full disk image with vCenter. This speeds up deployment since VMM won’t then have to copy back the VMDK before the VM can be deployed.

For simplicity when working with XenServer, you can create templates in System Center Virtual Machine Manager 2012 that will deploy onto the XenServer hosts, but XenServer templates are not used by SCVMM 2012.

And no matter which hypervisor you’re using, Virtual Machine Manager 2012 provides the ability to perform all of the advanced virtual machine operations you expect it would: VM live migration, snapshots, and advanced power management of hosts (both powering off when underutilized or spinning up when more horsepower is needed).


Once your private cloud is up, you need to ensure the right people can access it.

Access to the cloud is not assigned to everyone by default. You will be able to completely control who who has permission to access the cloud, and who can administer it. Not only that, but you can specify who has permissions for services within the cloud. You can add your SharePoint administrators to have administrative control over the SharePoint service. Your Exchange administrators can have administrative access to the Exchange service.

There is a distinction between being an administrator for the cloud service, such as Exchange (which could have the application installation and multiple VMs to support it), and being an administrator for the program that the service provides. If you’re an Exchange administrator, you can handle all of the tasks that you need to perform on email accounts, Exchange itself, and the Exchange server’s operating system. If you are an administrator on the Exchange cloud service, you can administer the VM’s, the virtual networks, and the templates that the VM’s use.

It’s possible to set it up so that the person in charge of the VM’s for the Exchange service in your private cloud can’t actually administer any email accounts. Likewise, you can be a fully functional Exchange administrator and perform email administration all day long, but unless you are granted the permission to do so, you can’t make changes to the cloud service itself.


Finally, control is used to fine-tune what the different groups can do – exactly.

With fine grained role-based controls, you can specify exactly what each group (you could use people, but best is to assign roles to groups and add people into the groups) has rights to do.

You can specify that some people can start VM’s for a particular service, but cannot stop them. They can take snapshots, but not revert to them. You can be as specific as you desire. People can be placed in multiple roles. Roles can be assigned to different services, to whole clouds, multiple clouds, or even to different specific services within separate clouds.

You can also use quotas to help control what groups can do. There are 2 quotas in effect for each role/service: The individual quota, and the group quota. The individual quota is applied to each person, and the group quota is the maximum resource assignment for the group. For example, an individual quota of 2 VM’s, along with a group quota of 10 VM’s would thus be applied:

Each user in the role may create a maximum of 2 VM’s. Once the group has 10 VM’s total, nobody can create another VM, even if they have created less than 2 VM’s themselves.


System Center 2012 is bringing private clouds into the datacenters. Private clouds are administered through System Center Virtual Machine Manager 2012. These private clouds were designed with 4 key concepts in mind: Abstract the hardware (hosts, networking, and storage) into logical clouds; Use heterogeneity to keep the existing infrastructure in place, so that people with VMware Citrix, and Microsoft hypervisors can use what they have already got; Provide access to not only the clouds themselves, but can provide different levels of permissions across services, and clouds; And to put controls in place that can limit the specific actions that users can take in the services, and apply quotas to both the groups and the individuals.