Now available: The Release Candidate for System Center Virtual Machine Manager 2012

Really pleased to see the Release Candidate made available:

http://blogs.technet.com/b/scvmm/archive/2011/09/08/now-available-the-release-candidate-for-system-center-virtual-machine-manager-2012.aspx

It has been interesting learning about VMM 2012 by using the beta VHD but it became frustrating recently when the provided copy of SQL Server expired. I didn’t have the mental energy to move the databases onto our production SQL Server so I’m glad that a refresh of the VHD is now out.

Evaluating VMM 2012 by using the VHD is, in my opinion, the simplest way to start playing around with VMM and learning what it can do. Download, attach to a virtual server and away you go!

It is also possible – and supported – to upgrade from VMM 2008 R2 SP1 to VMM 2012 RC and then to VMM 2012 RTM, so if you have an existing VMM 2008 R2 SP1 estate, you can upgrade to VMM 2012 RC safe in the knowledge that you’ll be able to upgrade to RTM when it arrives.

Speaking of which, I wonder when it will arrive? Are the various System Center products going to be released independently or in one big hit? If the latter, I suspect we may be waiting a while because I think VMM is the first Release Candidate … DPM has only recently hit beta!

I can’t see any support listed for Linux, though, which is a shame given that RHEL, amongst others, are supposed to be supported guests of Hyper-V.

SCVMM 2012: Server Fabric Lifecycle

… or all about high availability, update management and dynamic optimization.

The goal of the HA feature in VMM is to ensure that a VM can recover from failure, e.g. the failure of a host, and to ensure that a VM can easily be migrated. Over and above the capabilities of HA in previous versions of VMM, VMM 2010 adds the ability to create & delete clusters, manage clusters in untrusted domains, have a non-HA VM on a cluster and have VMM Server itself HA. VMM 2012 also adds the functionality manage Citrix XenServer (over the already existing functionality to manage VMware).

Update management is a new feature of VMM 2012 and aims to keep Windows fabric servers up to date. The reason why this has been added to VMM is to enable management of the complete fabric from a single pane of glass – and that includes all aspects of the server fabric lifecycle.

The feature requires a pre-existing, dedicated, root WSUS 3.0 SP2 64 bit server. If the WSUS server is remote, the WSUS console is required on the VMM server. It supports WSUS in SSL mode.

VMM gets a catalog of updates from the update server. It points the fabric servers to the correct update server, i.e. configures the WUA agent on each fabric server.

A baseline is then created. The baseline is a logical grouping of updates to assess compliance. VMM provides two sample baselines for Security and Critical updates. You can assign the baseline to hosts, host groups and host clusters, plus VMM server roles (library server, PXE server, Update server and VMM server). You cannot assign it to VMs (running or stored) or VHDs in the library.

A scan is then conducted to see if the server is compliant or not for the assigned baseline. VMM leverages WUA for applicability and compliance. Scan is on demand and automatable using PowerShell. VMM then makes the server compliant by installing missing updates. Update installation progress can be tracked in the VMM console and remediation is on demand and automatable using PowerShell.

There is an orchestrated workflow for remediating a Hyper-V cluster whereby each node in turn is put into maintenance mode, evacuating the node using Live Migration, install the missing updates based on baselines assigned, take the node out of maintenance mode, go to the next node and repeat. It supports Windows Server 2008 as well as R2 clusters and is automatable using PowerShell.

Dynamic Optimization is another new feature of VMM 2012. It keeps a cluster balanced for resource usage; Live Migration avoids VM downtime and the feature does not require Operations Manager. It supports Hyper-V, VMware and Citrix XenServer clusters.

DO has two modes – manual and automatic, with the default being manual. The feature optimises for CPU, memory, Disk I/O and Network I/O. It optimises when resource usage goes above the DO threshold. There is a configurable level of aggressiveness … more aggressive = more migrations = more balanced. The default is least aggressive.

There is also Power Optimisation, which extends DO and can only be enabled if DO is in automatic mode. It optimises for the same resources as in DO and optimises when resource usage goes below PO threshold. What PO does is powers off and on the physical hosts when it can move guests elsewhere. It evacuates a host before powering off and ensures that evacuation will not cause other nodes to go above the DO threshold, or that powering off will not violate cluster quorum requirements. It leverages out-of-band management for power off/on.

I need to follow up with Microsoft on the cluster quorum requirements because as I understand it, an even-node cluster requires a file share witness, whilst an odd-node cluster doesn’t … so if you turn off any node in a cluster, you are changing the quorum requirements!

SCVMM 2012: Storage Overview

VMM aims to expose a common model for storage across different arrays, with end-to-end visibility of storage as it relates to hypervisor hosts. The aim is to allow IT to do more, providing deep integration into the UI and PowerShell with a minimal learning curve, streamlining storage tasks across different arrays, taking advantage of more advanced storage features.

That said, VMM is not a storage resource manager. There is no value in trying to replace partner specific tools, it is not possible to keep up with new capabilities and to attempt to be an SRM product would mean that VMM would not ship on time!

What this functionality offers the administrator is the ability to control what host groups can access in terms of available storage logical units and available storage pools.

The standard used by VMM is SMI-S and the four companies announced as supported so far are EMC, HP, HDS and NetApp.

There is support for VDS but it is largely deprecated with the future focus being on SMI-S.

For me, this presents quite a challenge if I want to use VMM to manage the storage used with the VMs because I’ve now go to make sure that the storage is “compatible” with VMM. No real news about Dell, which is my preferred supplier, which makes things extra tricky. It may be that I’ll have to stick with something like Dell’s MD3000i array which supports VDS and wait a few years until there is more clarity around SMI-S and VMM’s storage capability, and change to an SMI-S array at that time.

Having said all of that, it looks like it might be possible to get hold of an SMI-S provider for Dell’s MD arrays – both iSCSI and DAS!

http://www1.euro.dell.com/content/topics/topic.aspx/global/shared/services/en/smi_form?c

… however, that appears to be for an early version of the software that Dell were working on. There seems to be a newer version from what I can gather in a manual I found:

http://support.dell.com/support/edocs/systems/RBOD_com/SMIS/SMIS.pdf

but I haven’t been able to find the corresponding download. I am encouraged, though, that it should be technically feasible to control a Dell MD array from VMM 2012 so the hunt continues!

SCVMM 2012: Overview of Networking

Just as an aside, it is worth noting that VMM 2012 has the following user role profiles:

• VMM Admin
• Scope: Entire system
• Can take any action
• Can use Administrator console or PowerShell
• Delegated Admin
• Scope: host groups and clouds
• Set up fabric by configuring hosts, networking and storage
• Create cloud from physical capacity
• Assign cloud to self-service users
• Can use Administrator console or PowerShell
• Self-Service User
• Scope: clouds only
• Author templates
• Deploy/manage VMs and Services
• Share resources
• Revocable actions
• Quota as a shared and per-user limit
• Can use Administrator console, PowerShell and Self-service portal
• Read-only Administrator
• Scope: host groups and clouds
• No actions

Network Fabric Management

• Define logical networks using VLANs and Subnets per datacentre location
• Address management for static IPs, Load Balancer VIPs and MAC addresses
• Automated provisioning of Load Balancers

A logical network is the abstraction of the physical network infrastructure, which allows you to model the network based on business needs. You can use them to describe networks for different purposes, e.g. traffic isolation, provision network for different SLAs.

It can span host groups in different locations with different IP subnets or VLANs. For each IP subnet/VLAN, it is possible to define IP pools of addresses to be used by VMM. Pools can contain IPv4 addresses or IPv6 addresses but not both.

An IP pool consists of a range of addresses, which is then described in terms of static IPs, reserved IPs and virtual IPs. Once the pool is defined, when a new VM is created, an IP address is checked-out. When the VM is deleted or migrated, the IP address is checked-in.

The virtual IPs are used for load balancers; they are similarly checked out from the IP Pool. Adding a load balancer to VMM requires a PowerShell provider. Once the provider has been added, a load balancer is defined through its connection properties and the connection validated. A VIP template is then defined in terms of the protocol, LB method, persistency and health monitors. There is support for f5, Citrix and Brocade, along with Microsoft’s NLB. There will also be a published interface if you want to develop your own PowerShell provider .

VMM also supports MAC Address Pool management. You define the MAC range, associate it to a host group and then, when a VM is created, a MAC address is checked out and when the VM is deleted, the MAC address is checked in.

SCVMM 2012: Bare Metal Deployment in Action!

As promised, here is a bare metal deployment in screenshots as initiated from SCVMM 2012. One thing to note is that the bare metal server must be configured to have network booting as the first option so that an unattended PXE boot can be initiated.

In part 2, I covered the steps required in VMM to initiate a bare metal deployment. The following screenshots show what happens on the bare metal server once VMM has kicked off the job.

So the first thing that the host does is a PXE boot. Once that is successful (and you may need to review this post), the host starts to transfer the boot file from the WDS server:

This allows the server to boot into WinPE:

and the VMM bare metal deployment starts:

The principle behind bare metal deployment is that VMM actually deploys a VHD rather than installing the OS onto the raw hard drive.

Once that is done, there is a customisation stage:

and the enabling of the Hyper-V role:

(Remember that this is the bare metal deployment of a new Hyper-V host because this is VMM doing this)

The install then cleans up …

and the host reboots. Although the host is configured to try PXE booting first, the WDS server refuses the PXE boot so the hardware then continues to boot to the hard drive.

From here on, it is a standard OS installation.

One more reboot …

.. and the server finally finishes with a complete installation of Windows Server 2008 R2 SP1 and, in my case, ready joined to the domain.

Very painless and very fast – the above deployment took about 30 minutes.

SCVMM 2012: Getting WDS to work!

In SCVMM 2012- Preparing for Bare Metal Deployment, part 3, I looked at setting up WDS as one of the key parts to getting bare metal deployment to work.

One of the screens in the WDS configuration wizard is the PXE server initial settings:

In the blog posting, I said to leave that setting as “Do not respond to any client computers”. I said this because I was under the impression that the provider that VMM installs onto the WDS server would cause WDS to behave in the way it needs to behave for VMM.

That is not the case.

Indeed, it seems that setting the option to the middle choice – respond only to known client computers – is not the correct option either despite the fact that Microsoft explained that when the bare metal server does a boot from PXE, the PXE server talks to VMM to authorise the PXE boot.

In testing, it looks like the only way WDS will respond is if you set the option to the last choice – respond to all client computers (known and unknown). For my testing, I also selected the checkbox: require administrator approval for unknown computers. That way, you won’t suddenly get a bunch of systems trying to boot off your WDS server!

The setting can be changed retrospectively from the WDS console by right-clicking on the server, choosing Properties and then selecting the PXE Response tab:

I’ll post a separate blog showing the various stages that a bare metal server goes through as the deployment proceeds but hopefully the above change will get everything going for you.

SCVMM 2012: Protecting with DPM

The whole of System Centre is getting a revamp this year so we aren’t just looking at a new version of Virtual Machine Manager, but also a new version of Data Protection Manager.

In DPM 2012, there is support for protecting VMM 2012 and 2008 R2, along with item level recovery of VM contents even when DPM is running inside a VM (it used to require a physical host so that it could use the Hyper-V role) and rapid block level backups of VMs running on stand-alone hosts.

As ever with DPM, you can protect at the host level or the guest level.

If you back up at the host level, you can protect or recover the whole machine. You can protect non-Windows servers and line-of-business applications without VSS writers. However, there is no granularity of backup – it is the whole thing.

By comparison, if you back up on the guest, you protect or recover data specifically, e.g. SQL database, Exchange, SharePoint, etc. It is equivalent to protecting a physical version of that server.

Backing up VMM provides full application backup of the VMM database to disk and tape, and supports original location recovery and restore as files to a network location.

DPM seamlessly protects Live Migrating VMs on CSV (cluster shared volume) Clusters. However, in my experience, for this to work optimally, the storage hardware must support VSS. Without that support, DPM can only backup through the node that “owns” the CSV storage. Either way, the VM is backed up regardless of which node in the cluster hosts the VM.

For recovery, you can restore the VM back to the original host or cluster, or you can restore the VM to a different host or cluster, or you can perform item level recovery (individual files from within the VHDs) to a file share.

If you have primary & secondary DPM sites and the primary site goes down, the DPM admin switches protection to the DPM DR server and backup & recovery of production servers continues seamlessly. DPM does a good job of bare metal recovery as well.

SCVMM 2012: Preparing for Bare Metal Deployment, part 4

In this long-awaited post, I’ll be looking at logical networks as far as SCVMM 2012 understands them.

A logical network defines the IP subnets and VLANs that go together. The process of doing this starts by selecting Logical Networks under Fabric > Networking and then Create Logical Network on the ribbon bar:

At this stage, all you need is a name and an optional description. Type that in and click OK. This will be the “container” for the other parts that go up to make the logical network.

If you’ve got the console showing the Overview, after a brief pause, the newly created network should appear under the IP pool usage section:

The column headings (cropped from this screenshot) show the number of IP addresses allocated for the network, total defined and number available. I’ll cover that in more detail later.

So, having created the top level object, the next step is to create the definition. To do this, you need to click on Fabric Resources in the Show section of the ribbon bar, select your new logical network and then click Create Definition in the ribbon bar.

VMM provides a default definition name (the same as the network name with _1 appended) but you can change it. You then define the host groups that this network is appropriate to. This is useful if you’ve got multiple sites with different physical hosts in each site and therefore each with their own set of logical networks – some of which might have the same address pool under certain circumstances.

On the next part, you define the IP subnets and VLANs. VMM supports both IPv4 and IPv6.

The final screen confirms the settings, you click Finish and the definition is completed.

You can stop here if you like but it is possible to go further and get VMM to be even more useful by defining an IP pool for each subnet specified in the logical network definition. Select a subnet and then click Create IP Pool in the ribbon bar.

The wizard automatically fills out what should be the correct begin and end IP address for the subnet as you’ve defined it. All you need to do on this page is enter a name for the range and an optional description. You can reduce the pool if you so wish but there is the ability to “block out” addresses from the pool so that VMM doesn’t try to use them all and this may be the better approach. One of the reasons I say this is because later on in the wizard, you need to define the default gateway and it must be an IP address within the pool definition.

This is the screen where you can reserve IP addresses, either because you have got a separate DHCP pool or because you’ve statically assigned some addresses already. You can also specify VIP addresses used by load balancers here.

On this screen, you specify one or more default gateway addresses. As the screen notes, the gateway addresses must be within the range of the IP pool. Now, I’m not sure why you would specify more than one default gateway address or how VMM would use more than one default gateway address … but you must specify at least one otherwise you can’t move on in the wizard.

You can specify a metric against each gateway address but that doesn’t clear up the “multiple default gateway” question in my mind.

On this screen, you define the DNS servers, the DNS suffix and the DNS search suffixes. Somewhat annoyingly from a user interface perspective, the screen says “DNS servers in order of use” which makes sense but when you enter them, the Insert button does just that and inserts the next entry at the top of the list, so you actually have to enter them in reverse order in order to get them entered in the correct order! Thankfully, there are move up and move down buttons.

You must specify at least one DNS server and you must specify the DNS suffix.

On this screen, you define any WINS servers in use. The screen says “Specify one or more WINS servers” but you don’t have to specify any … which is just as well given that this is an old technology that isn’t needed by newer products and operating systems.

The final screen summarises the settings, you click Finish and the IP pool is created.

What the definition of an IP pool does for you is allows VMM to automatically assign IP addresses when you create hosts or new VMs. It can do this because host profiles can specify a logical network to be used.

You can also manually associate a network adapter with a logical network. The UI for this is a bit buried so I’ll document it here. Start by right-clicking a host and choosing Properties. In the window that opens, select Hardware on the left hand side, and a network adapter in the centre column. On the right hand side, you’ll then see the network adapter properties, including the opportunity to select as many logical networks as are appropriate for this adapter:

SCVMM 2012: Preparing for Bare Metal Deployment, part 3

In the series so far:

• SCVMM 2012: Bare Metal Deployment covers what SCVMM 2012 will actually do for bare metal deployment and what infrastructure is required to support it.
• SCVMM 2012: Preparing for Bare Metal Deployment, part 1 looks at the steps required to get a copy of Windows Server 2008 R2 SP1 set up as a VHD on the VMM Library.
• SCVMM 2012: Preparing for Bare Metal Deployment, part 2 looks at setting up the BMC account, defining a host profile and adding a physical host to SCVMM.

In this post, I’m going to cover setting up the WDS server that is required to support the PXE boot for bare metal deployment. Note that I’ve missed out the creation of the network definitions and I’m still planning to cover that is this series of posts … I’m just doing things slightly out of sequence .

Setting Up WDS

Please note that you must use Windows Server 2008 R2 as a minimum for the WDS used by VMM. With that said, the next step is to add the Windows Deployment Services role:

So basically you use the Add Roles Wizard and step through the default settings. After installation, go to Server Manager and expand Roles > Windows Deployment Services > Servers. You will see that the new server has a warning triangle over it because it hasn’t been configured.

Right-click on the server and choose Configure Server.

I’ve only got one drive on this server (it is a very simple VM) so I’m happy for the installation folder to be on the same volume as the system volume.

Leaving this set to Do not respond to any client computers.

Deselecting Add images to the server now because VMM will do that for itself in a moment.

So here is our finished installation of WDS:

Telling VMM about WDS

Under Fabric, choose Add resources > Add PXE Server. Enter the name of the WDS server and administrator credentials.

VMM then proceeds to set up what it needs to have on the WDS server:

When the modifications have been completed, you can run wdsutil /get-server /show:config on the WDS server to confirm that VMM has added a provider to the list:

Note that nothing done by VMM will show up in the WDS GUI. That is because the GUI only shows stuff handled “natively” by WDS, which doesn’t cover VMM.

SCVMM 2012: Bare Metal Deployment

Having written two parts so far on preparing for bare metal deployment, I thought that I’d take a bit of a step back and write about what SCVMM 2012 will do and will require in order to achieve bare metal deployment.

Microsoft understand the following to be the VM host lifecycle:

VMM 2008 didn’t support all of that lifecycle. VMM 2012, by comparison, has gained improvements in the following areas:

• Out of band management: control of bare metal machine using baseboard management controller (BMC).
• OS deployment: provision OS with Hyper-V onto bare metal machine.
• Cluster creation: fully automated Hyper-V cluster creation.

The goal for VMM 2012 is to discover bare metal machines and bring them to a fully provisioned state with Hyper-V enabled. To achieve that, the following functionality is incorporated into VMM 2012:

• VHD image-based deployment to bare metal
• Host profiles are used for a consistent configuration to a variety of hardware
• The Add Resource Wizard provides for selection and customisation at deployment time
• Out-of-band communication and WDS/PXE allow for the bare metal computer to boot into the VMM deployment agent.

Setting up the PXE server for bare metal deployment of Hyper-V requires Windows Deployment Server (WDS) on Windows Server 2008 R2 and the installation of the VMM OSD provider and agent. This provider coexists with other providers and responds to VMM-initiated PXE requests, resulting in the deployment of WinPE. I’m planning to write more about setting up the PXE server in a future blog entry.

Deploying onto bare metal requires:

• The VHD in the VMM library
• Device drivers for the hardware in the VMM library
• Logical network definition
• Static IP addresses from a defined VMM pool or DHCP if preferred
• Optional “generic” commands to do some configuration of hardware before the OS gets deployed, e.g. configuration of RAID hardware
• Disk partition layout definition
• OS settings

… all of which builds into the Host Profile.

Once you have all of the pieces in place, deploying onto bare metal looks like this:

Simple, huh?

In a nutshell:

• VMM performs an out-of-band reboot of the bare metal hardware.
• The bare metal server does a boot from PXE.
• The PXE server talks to VMM to authorise the PXE boot.
• The bare metal server downloads WinPE from the PXE server.
• If defined, the bare metal server runs any generic commands, and then configures the drive partitions.
• The bare metal server downloads the VHD from the library server (which can be the VMM server) and then injects the drivers.
• The bare metal server finishes off the customisation and joins the domain.
• Finally, Hyper-V is enabled.

One thing about this approach is that deployment to bare metal only supports Windows Server 2008 R2 because the deployment actually sets up the host to boot from a VHD file, rather than deploying the OS “natively” onto the host’s hard drive. That shouldn’t be too big an issue as the performance of VHD is very close to that of native IO.

Best practice when booting from VHD is that the VHD is of fixed size so that you know how much space is going to be required for that VHD. However, it should be noted that when booting from VHD, the page file for that operating system gets stored on the native hard drive and not in the VHD. It is therefore important that the native hard drive is big enough for that boot VHD and the page file (which will be the same size as the amount of memory in the server).