SCVMM

CMP discovers templates, networks, and existing VMs on your Hyper-V hosts and clusters, deploys new Windows and Linux VMs, manages disks and checkpoints, and controls VMs through their full lifecycle. It reaches the SCVMM management server over WinRM (PowerShell remoting) and installs no agent, so WinRM only has to be reachable and correctly authenticated.

Before you begin

Confirm the following before you add an SCVMM resource handler.

Network and WinRM

• The CMP appliance reaches the SCVMM management server over WinRM:
  • HTTPS: TCP 5986 (recommended)
  • HTTP: TCP 5985
• The SCVMM PowerShell module is installed on the SCVMM management server.
• You have a Windows domain service account with rights in SCVMM. See Minimum permissions.

Choosing a WinRM transport

CMP supports three WinRM authentication transports. Choose one and complete its setup before you connect.

NTLM

NTLM needs no additional setup. Select NTLM as the transport.

CredSSP

CredSSP requires HTTPS. CMP rejects CredSSP over HTTP when you save the connection.

1. On the SCVMM management server, enable the CredSSP server role:

   Enable-WSManCredSSP -Role Server
   

2. In CMP, set WinRM Protocol to HTTPS and WinRM Transport to CredSSP.

Kerberos

Kerberos requires configuration on the CMP appliance.

1. Add a [realms] entry to the Kerberos client configuration file, krb5.conf, giving the realm name, kdc, and admin_server. Replace every instance of domain.com, DOMAIN.COM, and dc01 with your own values:

   [libdefaults]
       default_realm = DOMAIN.COM
       dns_lookup_realm = false
       dns_lookup_kdc = true
       rdns = false
       forwardable = true
   
   [realms]
       DOMAIN.COM = {
           kdc = dc01.domain.com
           admin_server = dc01.domain.com
       }
   
   [domain_realm]
       .domain.com = DOMAIN.COM
       domain.com = DOMAIN.COM
   

2. Obtain a ticket with kinit and confirm it with klist:

   kinit username@DOMAIN.COM
   klist
   

3. In CMP, enter the SCVMM server’s fully qualified domain name in the IP address field. Kerberos validates against the server’s SPN, so a bare IP address is rejected. You may also need to enter the account with the domain in capitals, for example username@DOMAIN.COM, to match the realm in krb5.conf.

Library permissions

CMP writes a per-VM cloud-init seed ISO to the SCVMM library share when it provisions a Linux VM, then deletes it afterward. Create the folder once and grant the service account rights on it.

1. Create CloudBolt\seeds under the SCVMM library share. CMP does not create the folder. The library share’s path is a UNC path, so set the NTFS permissions on the underlying local folder on the library server.

   • On the VMM server, get the share’s UNC path and the server hosting it:

     Get-SCLibraryShare | Select-Object Name, Path, @{n='LibraryServer';e={$_.LibraryServer.Name}}
     

   • On that library server, resolve the UNC share to its local disk path:

     Get-SmbShare -Name 'MSSCVMMLibrary' | Select-Object Name, Path
     

   • Create the subfolder if it does not already exist:

     New-Item -ItemType Directory -Path '<Path From Get-SmbShare>\CloudBolt\seeds'
     

2. Grant the SCVMM run-as account rights on that subfolder only, not on the rest of the library. Grant Modify on the CloudBolt\seeds folder, with inheritance to child items.

   $folder  = '<Path From Get-SmbShare>\CloudBolt\seeds'
   $account = 'LAB\svc-cloudbolt'
   
   $acl  = Get-Acl $folder
   $rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
       $account, 'Modify',
       'ContainerInherit,ObjectInherit', 'None', 'Allow')
   $acl.AddAccessRule($rule)
   Set-Acl $folder $acl
   

3. If the path resolves to a UNC path rather than a local path on the VMM or library server, also grant share-level Change:

   Grant-SmbShareAccess -Name 'MSSCVMMLibrary' -AccountName $account -AccessRight Change -Force
   

Minimum permissions

The Windows domain service account the resource handler connects with needs:

• WinRM and PowerShell remoting access to the SCVMM management server. Grant it at least Remote Management Users.
• At least the Fabric Administrator (Delegated Administrator) SCVMM role. SCVMM’s other built-in roles do not grant everything CMP needs.
• Write and delete on the account’s temporary directory.
• Write and delete, over SMB and NTFS, on the CloudBolt\seeds folder in the library share.

Add an SCVMM resource handler

1. Go to Admin > Resource Handlers.
2. Select Add, then select SCVMM.
3. Complete the connection fields described below, then select Continue. CMP validates the connection and reports any authentication or certificate errors in the dialog.
4. Enter a Name and, optionally, a Description.
5. Under Import clusters, select the SCVMM clusters to bring in. CMP creates one environment for each cluster you select.
6. Select Done.

After the handler is created, the Import clusters field becomes read-only. Manage clusters from the handler’s Clusters tab instead.

Connection options

HTTP or HTTPS: the WinRM Protocol setting controls both the encryption and the port.

• HTTPS (5986): encrypted WinRM. Recommended everywhere, and required for CredSSP. Enable SSL Verification when the server has a trusted certificate; leave it disabled for a self-signed certificate you have not distributed to the appliance.
• HTTP (5985): unencrypted WinRM. Available with NTLM or Kerberos, but not with CredSSP.

Templates

CMP discovers SCVMM VM templates from the library and lists them as deployment sources. Each template reports its name and OS family (Windows or Linux), and CMP customizes the deployed VM accordingly.

• The template must be a valid VM template in the SCVMM library with its OS family set correctly.
• The template must be authored as highly available. A deployed VM inherits its settings from its template, and CMP deploys to clustered storage, where a VM that is not highly available cannot come online. CMP checks the template before it deploys and stops with a message naming the template if the setting is missing.
• Windows templates should be built from a generalized VHDX, with the OS Configuration tab populated (domain, administrator password, product key) and Hyper-V Integration Services running.
• Linux templates need cloud-init with the NoCloud datasource enabled and the Hyper-V KVP daemon installed.

CMP confirms a new VM’s hostname and IP address via Hyper-V KVP, part of Integration Services, and applies them via guest customization: cloud-init on Linux, and Sysprep with unattend.xml on Windows. Both mechanisms have to be prepared on the template.

Networks

CMP automatically discovers SCVMM networks: VM networks on SCVMM 2022 and newer (SDN-aware) and virtual networks on earlier versions. At deploy time, it binds the VM’s network adapter to the selected VM network.

CMP drives the IP mode

The CMP network you select overrides the template, and its addressing scheme decides how the adapter is configured:

• No network selected: the template’s addressing is left untouched.
• DHCP network: CMP forces DHCP on the adapter.
• Static network with an IP address: CMP applies the static address.
• Static network without an IP address: provisioning fails.

Where the static IP address comes from

When a VM is deployed with a static address, CMP chooses the address, not SCVMM. The value is resolved from the CMP network in this order:

1. An IPAM integration associated with the network, such as Infoblox, which allocates the address.
2. A CMP static IP pool tied to the network.
3. A static IP address entered by the requestor on the order form.

CMP then writes that address into SCVMM: onto the network adapter for Windows, and into the cloud-init seed network configuration for Linux.

How CMP uses the SCVMM network topology

For Windows static addresses, CMP also resolves the SCVMM network objects so the adapter binds to the correct subnet and SCVMM records the allocation against the right network. It walks one of two supported topologies:

• Isolated (VLAN or HNV): VM network, VM subnet, static IP address pool.
• Connected (no isolation): VM network, logical network, logical network definition, static IP address pool.

This walk does not select the IP address. It confirms that the subnet and pool exist and gives the adapter its binding context. On Windows, the SCVMM static IP address pool is also where the gateway, netmask, and DNS in the generated unattend.xml come from; the address itself comes from CMP. CMP takes the first match at each step rather than selecting a pool by name, so make the intended subnet and pool the first ones associated with the network.

Link-local APIPA addresses in 169.254.0.0/16 are ignored and treated as no address assigned.

VM customization

Customization is applied per OS family after the VM is created.

• Linux: CMP writes a per-VM NoCloud seed ISO holding the hostname, the network configuration (address, netmask, gateway, and DNS from the CMP network), and any custom cloud-init user data. The template’s cloud-init applies it on first boot.
• Windows with a static address: CMP assigns the address from IPAM, a CMP pool, or the requestor, and applies it to the adapter. Netmask, gateway, and DNS come from the SCVMM static IP pool’s subnet definition rather than from CMP, so configure them on the pool in SCVMM.
• Windows with DHCP: the template’s OS configuration is used.

Tags

CMP writes tags to SCVMM as VM custom properties during provisioning. Any CMP taggable attribute mapped to the SCVMM resource handler is written to the VM, and CMP creates the custom property in SCVMM if it does not already exist. Attributes with more than one value are written as a comma-separated string.

• Tags are applied at provision time, then read back so the values reconcile onto the server in CMP.
• Tagging is best-effort. If a custom property cannot be set, the failure is logged and provisioning continues.

Storage placement

Every SCVMM VM lands on cluster-connected shared storage, either a Cluster Shared Volume mount point or an SMB3 file share. Two environment parameters choose that storage:

Use Import parameters from resource handler on the environment to populate the list of valid mount points and classifications discovered from SCVMM.

Free-space guardrail

scvmm_volume_min_freespace sets a minimum free-space floor that gates volume selection. Give it a percentage, such as 10%, or a fixed size, such as 50 GB, 250mb, or 1 TB. It applies to an explicit mount point and to a classification-selected volume alike, and a volume that fails the floor is a hard error. Free space is measured at provision time and does not account for the size of the VM being placed. Leave it unset to disable the check.

SCVMM parameters

The SCVMM resource handler reads a set of CMP parameters prefixed with scvmm_ that control where and how VMs are provisioned. CMP creates these parameters when you add the handler, so you only set their values, usually as environment parameters (Admin > Environments > your SCVMM environment > Parameters) or on a blueprint or order form.

* Set only one of scvmm_vm_mount_point and scvmm_storage_classification per environment. See Storage placement.

Using each parameter

• scvmm_host_cluster: the target cluster for the environment. Required for every deployment.
• scvmm_vm_mount_point: explicit placement. Choose the Cluster Shared Volume mount point or SMB3 share where new VMs land. Use Import parameters from resource handler to populate the choices.
• scvmm_storage_classification: automatic placement. Choose a storage classification, and CMP places the VM on the volume with the most free space in that classification.
• scvmm_volume_min_freespace: optional guardrail. See Free-space guardrail.
• scvmm_library_share: optional, Linux only. Override it only when your seed ISOs must come from a library share other than MSSCVMMLibrary, which is typical in multi-library or multi-cluster setups. The service account needs write and delete rights on the CloudBolt\seeds folder in that share.
• scvmm_user_data: optional, Linux only. Enter cloud-init YAML to run on first boot. The value is rendered through CMP’s template engine with the server object in context, so you can reference fields such as {{ server.hostname }}. Wrap literal cloud-init or Jinja syntax that CMP should not render in {% verbatim %}…{% endverbatim %} tags. Setting it on a Windows server has no effect.

Other parameters the handler reads

These parameters exist in every install and are not specific to SCVMM, but the handler reads them:

• sc_nic_0: the VM network for the primary NIC.
• sc_nic_0_ip: the static address for the primary NIC. The literal value dhcp forces DHCP. It may be filled by an IPAM integration, a CMP static IP pool, or the requestor.
• sc_nic_0_netmask and sc_nic_0_gateway: read from the NIC or its network for Linux customization. For a Windows static address, netmask, gateway, and DNS come from the SCVMM pool’s subnet definition instead.
• hostname: the guest hostname. On Windows, it must be 15 characters or fewer.
• vm_customization_timeout: how many seconds to wait for the guest OS to report ready after boot.
• dns_domain and domain_name_server: the DNS suffix and servers, for Linux customization.

Disks

CMP manages virtual disks as dynamic VHDX files on the SCSI bus.

Disk path and placement

The disk storage path is set automatically and cannot be configured by the user. A data disk added as a day-2 action is placed alongside the VM, in the VM’s own folder, so it follows the storage location chosen at provision time by scvmm_vm_mount_point or scvmm_storage_classification. CMP names the file <hostname>-disk<N>.vhdx.

Operations

• Add disk: creates a dynamic VHDX on SCSI bus 0 at the next free LUN, alongside the VM.
• Extend disk: SCSI disks are resized while the VM runs. IDE disks need a brief power-off, expand, and power-on cycle.
• Delete disk: detaches the VHDX and deletes the file from storage.

Snapshots (checkpoints)

CMP can create, restore, and delete SCVMM checkpoints.

• Create: creates a named checkpoint. Whether it is a production or a standard checkpoint is governed by the Hyper-V host’s checkpoint setting; CMP has no per-snapshot memory option.
• Restore: reverts the VM to the selected checkpoint. The VM returns to the power state the checkpoint captured, and CMP can optionally power it back on.
• Delete: removes the checkpoint.

Notes and limitations

• High availability comes from the template. A deployed VM inherits the setting, so the template has to be authored as highly available. CMP checks it before deploying and stops with a message naming the template if the setting is missing.
• Only highly available VMs are imported. When CMP brings existing SCVMM VMs under management, it skips any that are not highly available, and reports how many it skipped.
• Storage method: set only one of scvmm_vm_mount_point or scvmm_storage_classification per environment. If both are set, the explicit mount point wins.
• WinRM is single-hop: CredSSP and Kerberos both authenticate only the connection from CMP to SCVMM. Neither delegates credentials onward to the Hyper-V hosts.
• Disk placement is delegated to SCVMM. Data disks must be attached to the VM and cannot be placed separately.
• Windows static networking: netmask, gateway, and DNS come from the SCVMM IP pool, so configure those pools correctly in SCVMM.
• Static IP pool selection: CMP uses the first pool it finds along the network topology, not a pool chosen by name.