Latest posts by Paul Schnackenburg (see all)
- Interview with Ben Armstrong at Ignite Australia 2017 - Fri, Jun 2 2017
- Microsoft Ignite 2017 Australia - Mon, Mar 6 2017
- Storage Spaces Direct (S2D) - Part 2: setup and monitoring - Tue, Jan 24 2017
There are some key differences in how SCVMM 2012 integrates with VMware’s infrastructure compared to SCVMM 2008. It no longer imports, merges or synchronizes the tree structure from vCenter to SCVMM, instead you manually add ESX servers to any VMM host group.
Integrating SCVMM 2012 with VMware’s platform ^
When you import a VMware template to the library the .vmdk file is left in the ESX data store and only the metadata is copied to the library. HTTPS is used for all data transfers between ESX hosts and the VMM library which means there’s no longer the need to enable root Secure Shell (SSH) access to ESX hosts to support the Secure File Transfer Protocol (SFTP).
SCVMM Services can be deployed to ESX hosts but they’re not compatible with VMware vApps, likewise ESX hosts resources can underlie a SCVMM private cloud but it’s not compatible with vCloud. SCVMM supports up to 8 virtual CPUs for VMs on ESX/ESXi 4.0 hosts and up to 255 GB of memory and also recognises VMware fault tolerant machines.
Integrating SCVMM 2012 with Citrix XenServer ^
Unlike VMware, XenServer hosts and pools are managed directly from SCVMM 2012 so there’s no reliance on the XenCenter server. Migrations are supported through Citrix XenMotion, the equivalent of Hyper-V Live Migration. Both hypervisor and paravirtualization in XenServer is supported. If you have XenServer vhd files stored in the library set the virtualization platform to XenServer to distinguish them from Hyper-V vhd files.
Small catches to be aware of in this beta is that your hostnames have to match exactly (including case) to the self-signed certificates that XenServer creates and all the different virtual network switches that XenServer creates are represented as one switch inside of SCVMM.
Patching cluster hosts in SCVMM 2012 ^
One of the trickier things to manage in a clustered environment is updating the hosts. While management platforms such as Systems Center Configuration Manager can do it they’re not cluster / virtualization aware and are likely to push out patches to all hosts simultaneously, causing an outage as they all reboot. SCVMM works around the issue by integration with a dedicated 64 bit WSUS 3.0 SP2 server and orchestrating cluster patching by Live migrating VMs to other nodes, patching and rebooting the host, moving VMs back and the repeating the process on the next cluster node. The actual patch requirements are determined by Update Baselines which specify which patches are required on hosts, library servers, PXE servers and the SCVMM management server itself. Once you have assigned a baseline to a group of computers they’re scanned to determine if they’re out of compliance and patching can then take place to make them compliant. There’s also an option for exemptions if a particular patch is causing issues on one or more hosts.