This is a webcast for the System Center Influencers. I’ll do my best to blog as it goes along. It follows the recent beta release of VMST 3.0. This is the release I’ve been waiting for. Prior to this, it really only handled VM’s stored in an offline state in the library. But now there is patching for:
- Offline virtual machines in a SCVMM library
- Stopped and saved state virtual machines on a host
- Virtual machine templates
- Offline virtual hard disks in a SCVMM library by injecting update packages (DISM)
- Automated patching of Windows Server 2008 R2 failover cluster hosts running Hyper-V (using Live Migration for zero VM downtime)
Now that’s what I’m talking about!!! We’re very slowly moving towards some of the cool patching functionality for templates that is in VMM v.Next. That last one is a biggie!
- Dormant VM’s miss patch Tuesday.
- When they wake up they are non-compliant and vulnerable to network threats.
- Patching without VMST is a manual process which is a waste of effort.
- Works with stored VM’s in the VMM library
- Patches via WSUS & ConfigMgr with VMM
- Move VM to maintenance host, start VM, patch it, shutdown, move to library.
- Uses VMM PowerShell cmdlets.
- Supports Hyper-V and Virtual Server 2005 R2 SP1
VSMT 3.0 Beta
Note that it is no longer called the “Offline …” tool. See the previous features for the reason why.
The offline VM process works as usual, by moving it onto a maintenance host, starting, patching, shutting down and restoring it to the library.
Demo of Configuration and Offline Servicing
We see a VMM library with offline VM’s and template VHD’s. There are 2 hosts. Some VM’s are stopped, some are in saved state. One host is labelled as being a maintenance host. The VMST GUI is the usual System Center MMC “wunderbar” GUI. The VMM server is selected, along with ConfigMgr and/or WSUS. The maintenance host is selected in the wizard. Credentials for servicing offline VHD’s is entered. Timeouts for copies and updates are also entered (be careful with service pack updates which can be VERY time consuming – lesson learned from SMS updating process back in 2005).
You can create groups for VHD’s, from VM’s in the library, from VM’s in template groups, and from VM’s in host groups. You now create a servicing job for selected VM’s from the group(s). You can also specify if the VM should use its own configured virtual network or from a selected VLAN (maintenance network). A schedule is entered for the job, e.g. now, later or on a recurring basis. You can track the job process in VMST or in VMM.
Servicing Shutdown VM’s on a Host
The VM is moved from the production host to a maintenance host. Here it is started and patched. The VM is shutdown and returned to the original host. The configuration is pretty similar, just using a “stopped VM group” instead. You can include VM’s with a saved state – these VM’s will lose their saved state. This is because the VM is powered (woken) up and powered down.
Patching Virtual Machine Templates
These are files stored in the VMM library along with metadata in the VMM SQL database. Patching these requires using a different method. VMST creates a “gold VM” from the template and maintains a mapping to it. The gold VM is started on the maintenance host. The gold VM is updated. The gold VM is cloned (not moved or new template). The cloned VM is sysprepped and replaced the template VHD. The gold VM is left in place for the next patching.
In the demo, you can select a pre-existing VM from the template that you are going to maintain. This means you need to deploy 1 VM from each 1 template you keep in the library. You can choose to backup the template in the library (1 version only per template), just in case the patching breaks the template.
Patching Offline (not template) VHD’s
The VHD can be mounted using Diskpart on a maintenance host (not necc. Hyper-V: W7 or W2008 R2) and DISM is used to inject the update packages into the VHD.
Patching W2008 R2 Clustered Hyper-V Hosts
Must be W2008 R2 hosts and must be clustered. It puts a host into VMM maintenance mode –> Live Migrates the VM’s to another host. It patches the host and removes VMM maintenance mode. The process repeats through the cluster nodes.
There is no integration with OpsMgr so you’ll need to configure a scheduled maintenance mode (by yourself) there for all of your hosts in the cluster to prevent all sorts of nasty alerts.
This was a good presentation – very demo focused which I like. The product is now at a point where I think all VMM users should implement it.