# SCVMM template preparation
> Prepare a Linux or Windows VM template, and the surrounding SCVMM fabric, so that Cloud Management Platform (CMP) can provision from it
---
Site [llms.txt](/llms.txt)
---
CMP reads a new guest's hostname and IP address back through Hyper-V KVP, which is part of Integration Services, and applies the hostname, address, and user data through guest customization: cloud-init on Linux, Sysprep and unattend.xml on Windows. The steps below make both mechanisms work.
This topic covers template and fabric preparation. For resource handler setup and provisioning behavior, see [SCVMM](/docs/cmp/configure/infrastructure/resource-handlers/scvmm/).
## Prepare a Linux template
Perform these steps inside the running Linux VM **before** you generalize and seal it.
1. **Install cloud-init, version 18.x or newer.**
```bash
# RHEL / Rocky / Alma
sudo dnf install -y cloud-init
# Debian / Ubuntu
sudo apt-get install -y cloud-init
```
1. **Install and enable Hyper-V Integration Services, which provides the KVP daemon.**
```bash
# RHEL / Rocky / Alma
sudo dnf install -y hyperv-daemons
sudo systemctl enable --now hypervkvpd
# Debian / Ubuntu
sudo apt-get install -y hyperv-daemons
sudo systemctl enable --now hv-kvp-daemon
```
CMP uses KVP to confirm the guest's hostname and address after boot. Without the daemon running, provisioning times out waiting for the guest.
1. **Pin cloud-init to the NoCloud datasource.** Create `/etc/cloud/cloud.cfg.d/99-cb-nocloud.cfg`:
```yaml
datasource_list: [ NoCloud, None ]
```
Listing `None` last stops the VM from hanging at boot when no seed is present.
1. **Generalize and seal the template.** Run this last, immediately before shutdown:
```bash
sudo cloud-init clean --logs --machine-id
sudo rm -f /etc/ssh/ssh_host_*
sudo shutdown -h now
```
This clears the cached instance ID, so cloud-init runs again on the next boot, and removes the SSH host keys, which are regenerated per VM on first boot.
1. **Import the VHDX into the SCVMM library and create a template from it.**
**Do not** configure a Guest OS Profile for the template. SCVMM's Guest OS Profile customization for Linux uses a method that newer Linux versions do not support, and a template that has one defined times out and fails during customization.
## Prepare a Windows template
1. **Verify Integration Services are running.** They are included by default on Windows Server 2012 R2 and later. Confirm that the service state is Running:
```powershell
Get-Service vmickvpexchange
```
CMP uses the KVP exchange service to confirm the guest's hostname and address after boot.
1. **Generalize the guest with Sysprep**, then shut it down:
```powershell
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
```
1. **Import the VHDX into the SCVMM library and create a template from it.**
1. **On the template's hardware configuration, set the network adapter's IP mode:**
- **Dynamic IP** for DHCP networks. CMP passes no address, and the guest gets one from DHCP.
- **Static IP, from a static IP pool**, for static addresses assigned by CMP.
1. **On the template's OS Configuration tab, fill in the required values.** Placeholder values are acceptable; SCVMM uses these when it generates the unattend.xml.
- Domain
- Administrator password
- Product key
1. **Set the template's OS family to Windows.**
## Prepare the SCVMM fabric
These steps apply to every template, whatever the guest OS.
1. **Author the template as highly available.** On the template's hardware configuration, enable **Make this virtual machine highly available**. CMP deploys onto clustered storage, where a VM that is not highly available cannot come online, and the deployed VM inherits the setting from the template. CMP checks the template before it deploys and stops with a message naming the template if the setting is missing.
1. **Configure a MAC address pool** with addresses available. Do not assign a static MAC address on the template; CMP triggers pool allocation when it creates the VM.
1. **Confirm the VM generation on each template.** CMP inherits the generation from the template and never overrides it, so the template decides whether VMs are Generation 1 or Generation 2.
1. **Provide a DVD drive on Linux templates.** If one is missing, CMP adds it on SCSI bus 1, LUN 0. Generation 2 VMs commonly ship without a DVD drive.
1. **For Windows static addressing, configure a static IP address pool** reachable through the VM network:
- **Isolated network:** VM network, VM subnet, static IP address pool.
- **Connected (no isolation) network:** VM network, logical network, logical network definition, static IP address pool.
The pool's subnet definition must specify the subnet in CIDR notation, the default gateway, a DNS server, and a DNS suffix.
1. **Grant the SCVMM service account write and delete rights** on the `CloudBolt\seeds` folder in the library share. CMP writes a per-VM seed ISO there during provisioning and removes it afterwards.
## Enable day-2 actions
For CMP to run scripts against a provisioned VM:
- **Linux templates** need SSH enabled on port 22, valid SSH credentials, and a network route from the CMP appliance to the guest's address.
- **Windows templates** need WinRM enabled on port 5985 or 5986, valid Windows credentials, and a network route from the CMP appliance to the guest's address.
## What CMP does not configure
Bake the following into the template, or supply them yourself. On Linux, you can use the `scvmm_user_data` parameter.
- Windows product-key injection and domain join
- Guest firewall rules
- Antivirus and endpoint security software
- Adding, editing, or removing extra NICs as a day-2 action. The Networks tab is read-only.
## Related
- [SCVMM](/docs/cmp/configure/infrastructure/resource-handlers/scvmm/): connecting the resource handler and how CMP provisions, customizes, and stores the VMs it deploys.
- [Customize VMs during provisioning](/docs/cmp/use/servers/customize-vms/): the customization CMP applies to every technology, and how long it waits for a guest to report ready.