cloudbase-init is a software that aims to provide the same functionality as cloud-init on linux but for Microsoft Windows. It is an open source project developed by Cloudbase Solutions.

While Proxmox does support cloud-init as we know from the normal linux template stuff, cloudbase-init itself does not support all the features that Proxmox implements OR they function differently, so there are some limitations currently.

Currently, things that do not work or do not work properly are:

• Setting a users password (cloudbase-init needs the password in clear-text, Proxmox only provides an encoded variant. You can create users, but that’s not worth much if you can’t set the password)
• Configure multiple interfaces (cloudbase-init uses MAC-Address matching, which Proxmox does not add to the configuration files)
• Configure DNS and search-domain. Even though cloud-init would take the settings set in the host, this does not work for cloudbase-init. You have to set the settings in the network adapater of the template.

Now that I’ve set the mood, there are still things we can do so that we can at least automatically provision new Windows Instances and add an IP to them. Thanks to the Windows Sysprepping we can force a password change on the first boot, making the Administrator user available to the customer.

Prerequisites 🔗

To get started, we need a normal Windows VM, this might be a version of Windows Server or just some Windows 10/11 VM. I assume that you’ve fully installed the VM including the virtio drivers. There are tons of tutorials out there and even the Proxmox Documentation has some (e.g.: Windows Server 2019).

Installing & configuring cloudbase-init 🔗

Download the cloudbase-init installer from the official website. The continuous build should be used, since the latest release may not include important fixes.

After downloading, run the setup. As the username, enter the name of the user with which you are currently logged in and uncheck the metadata password checkbox, so cloudbase-init doesn’t even try to replace the password and shows the reset dialog on the first boot.

On the last page, make sure to check that you want to sysprep the system but don’t check the box to reboot, since we need to change some config files first.

Now a dialog should open, telling you that the image is currently sysprepping. We can wait until that finishes.

Next, we need to enable the Windows cloudbase-init service that is responsible to do actions whenever the VM boots. To do this, type “Services” in the search bar. A window should open, search for “cloudbase-init”, right click and go to “Properties”. Change the “Startup” type to “Automatic”:

Next, we need to modify the cloudbase-init config files. These can be found in the C:\Programs\Cloudbase Solutions\Cloudbase-Init\conf folder. You can copy the files i’m showing here, but make sure to change the username and groups property to reflect your system language.

cloudbase-init.conf:

[DEFAULT]
username=Administrator
groups=Administratoren
inject_user_password=false
config_drive_raw_hhd=true
config_drive_cdrom=true
config_drive_vfat=true
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
verbose=true
debug=true
log_dir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\
log_file=cloudbase-init.log
default_log_levels=comtypes=INFO,suds=INFO,iso8601=WARN,requests=WARN
logging_serial_port_settings=
mtu_use_dhcp_config=true
ntp_use_dhcp_config=true
local_scripts_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\LocalScripts\
check_latest_version=false
plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,
	cloudbaseinit.plugins.common.networkconfig.NetworkConfigPlugin,
	cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin
metadata_services=cloudbaseinit.metadata.services.configdrive.ConfigDriveService

cloudbase-init-unattend.conf:

[DEFAULT]
username=Administrator
groups=Administratoren
inject_user_password=false
config_drive_raw_hhd=true
config_drive_cdrom=true
config_drive_vfat=true
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
verbose=true
debug=true
log_dir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log\
log_file=cloudbase-init-unattend.log
default_log_levels=comtypes=INFO,suds=INFO,iso8601=WARN,requests=WARN
logging_serial_port_settings=
mtu_use_dhcp_config=false
ntp_use_dhcp_config=false
local_scripts_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\LocalScripts\
check_latest_version=false
plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,
	cloudbaseinit.plugins.common.networkconfig.NetworkConfigPlugin,
	cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin
metadata_services=cloudbaseinit.metadata.services.configdrive.ConfigDriveService
allow_reboot=true
stop_service_on_exit=false

the notable points here are the plugins and metadata_services. We tell cloudbase-init to load the relevant data from the ConfigDriveService, which is the way the data is presented to the VM. It’s based on the OpenStack format. The plugins are the things that are actually done. Setting the hostname, configuring the network and expanding volumes that are attached to the VM. We also disable the updates and disable the NTP & MTU gathering via DHCP, which would delay actions in a network without a DHCP server.

Now, our image is golden and we can shut it down.

Testing 🔗

To test, we convert our VM into a template and clone it:

We browse to the Cloud-Init tab, update our IP configuration and click on “Regenerate Image” to apply those changes.

Next, we can start the VM. The VM will do some setup stuff and then restart once. After that, you should be greeted with the default login screen where you can then change your password:

After changing it, we will automatically get logged in and can check the network configuration using the ipconfig cmd command:

As you can see, our network configuration has been applied. Now, let’s test the disk resizing. I’m incrementing the VMs Harddrive by 18GB, resulting in a 50GB volume. After rebooting the VM we can check in the Diskmanager if our changes were applied automatially:

Conclusion 🔗

From what information I can gather, this is currently the simplest way to automize the creation and deployment of cloudbase-init based Windows VMs using the tools Proxmox provides, without patching the Proxmox Host itself. Sure, it kinda sucks that we cannot create a user and set a password, configure multiple interfaces reliable or add SSH keys, but it’s better than nothing. From here on, the user has admin privileges on the VM and can continue his work.