CloudStack ConfigDrive support

[aleskxyz]

Summary

Adds Apache CloudStack ConfigDrive metadata support and makes admin-password handling safer for both the HTTP DataServer and ConfigDrive paths.

CloudStack ConfigDrive

• New cloudbaseinit.metadata.services.cloudstack.ConfigDrive service for offline CloudStack metadata on ISO/CD-ROM.
• Discovers drives labeled config-2 (configurable via cloudstack.disk_label) using the marker cloudstack/metadata/instance-id.txt, so plain OpenStack config drives are not claimed.
• Registered in the default metadata_services list before OpenStack ConfigDrive.
• Supports instance id, hostname, public keys, user data, static network (network_data.json), and admin password from cloudstack/password/vm_password.txt.
• Detects password updates by storing a SHA-256 hash after apply and comparing on later boots.

DataServer (HTTP) refactor

• Renames the HTTP service class to DataServer; CloudStack remains as a backward-compatible alias.
• Defaults metadata_base_url to http://data-server/.
• Stops deleting the Password Server password on get_admin_password(); deletion happens only via confirm_admin_password() after successful guest apply.

Shared password confirm flow

• Adds no-op confirm_admin_password() on BaseMetadataService.
• SetUserPasswordPlugin confirms the password after it is set (injected or metadata), so password state is not consumed before a successful apply and metadata passwords are not re-applied every boot.

Other

• Config-drive volume label matching is case-insensitive.
• Docs and unit tests updated for DataServer, ConfigDrive, password confirm, and label matching.

Test plan

• Unit tests pass for cloudstack, setuserpassword, base metadata, and osconfigdrive Windows manager
• Boot a CloudStack VM with ConfigDrive ISO only (no metadata network) and verify instance id / hostname / userdata / network
• Verify admin password from ConfigDrive is applied once, then unchanged on reboot until a new password is present
• Verify DataServer path: password is applied, then removed from Password Server only after success
• Confirm OpenStack ConfigDrive VMs are not claimed by the CloudStack ConfigDrive service

[ader1990]

Hello @aleskxyz,

We are currently using opendev for patches:
https://review.opendev.org/q/project:x/cloudbase-init

How to create an account and contribute to:
https://docs.openstack.org/contributors/common/setup-gerrit.html

Thank you,
Adrian Vladu.

[jeanvetorello]

is it working?

[EduFrazao]

is it working?

Yes.
It is working very well!
I've done a build based on 1.1.19 with this patch and its working very fine, tested with both Virtual Router setup (that run faster) and with config drive.
Some of our users have network setups without virtual routers. In this case, configdrive is vital.

@ader1990 please, consider merge this feature. It does not change the current behavior and add a very nice feature!

[ader1990]

is it working?

Yes. It is working very well! I've done a build based on 1.1.19 with this patch and its working very fine, tested with both Virtual Router setup (that run faster) and with config drive. Some of our users have network setups without virtual routers. In this case, configdrive is vital.

@ader1990 please, consider merge this feature. It does not change the current behavior and add a very nice feature!

Hello all, would like to merge this feature!

@aleskxyz can you please rebase the patches on top of the latest HEAD and sign the commits. Would be also nice to squash all the commits to one, but it is not required, as I can squash them on merge as well.

@EduFrazao Thanks alot for testing it out.

[aleskxyz]

Hi @ader1990
Since this PR is from the pre-AI era, I reviewed it with AI agents and cleaned it up a bit. Back then I had a CloudStack cluster and could test it, but I don’t have the infra for a real e2e run anymore — so I’d appreciate if @EduFrazao could run a full Linux + Windows test with VR and ConfigDrive. Fingers crossed it goes smoothly.
Branch is rebased on master, commits are squashed and signed.
Thanks

[EduFrazao]

Hi @ader1990 Since this PR is from the pre-AI era, I reviewed it with AI agents and cleaned it up a bit. Back then I had a CloudStack cluster and could test it, but I don’t have the infra for a real e2e run anymore — so I’d appreciate if @EduFrazao could run a full Linux + Windows test with VR and ConfigDrive. Fingers crossed it goes smoothly. Branch is rebased on master, commits are squashed and signed. Thanks

Hi! Thank you for the rebase.
I'm running a build I will do tests in the next hours and let you guys know about the results!

[EduFrazao]

Hi @aleskxyz, @ader1990

Sorry for the late response.
I've run my tests with Windows Server 2019, 2022 and 2025, with ConfigDrive and DataServer (Virtual Router Networking) and everything I tested works.
Initial provisioning, password reset.

Same config works with Linux cloud images (tested with Debian, Alma, Arch, Rocky) and thoses Windows that I prepared.

cloudbase-init.conf

[DEFAULT]
logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init.log
verbose=true
debug=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer
plugins=cloudbaseinit.plugins.common.userdata.UserDataPlugin,cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin

username=Administrator
groups=Administrators

rename_admin_user=false
inject_user_password=true
first_logon_behaviour=no
allow_reboot=true
check_latest_version=false

bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

cloudbase-init-unattend.conf

[DEFAULT]
username=Administrator
groups=Administrators

inject_user_password=false

verbose=true
debug=false

logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init-unattend.log

check_latest_version=false

allow_reboot=false
stop_service_on_exit=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer

plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.mtu.MTUPlugin

# Adições para o Config Drive / bsdtar
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

[aleskxyz]

Hi @aleskxyz, @ader1990

Sorry for the late response.
I've run my tests with Windows Server 2019, 2022 and 2025, with ConfigDrive and DataServer (Virtual Router Networking) and everything I tested works.
Initial provisioning, password reset.

Same config works with Linux cloud images (tested with Debian, Alma, Arch, Rocky) and thoses Windows that I prepared.

cloudbase-init.conf

[DEFAULT]
logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init.log
verbose=true
debug=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer
plugins=cloudbaseinit.plugins.common.userdata.UserDataPlugin,cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin

username=Administrator
groups=Administrators

rename_admin_user=false
inject_user_password=true
first_logon_behaviour=no
allow_reboot=true
check_latest_version=false

bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

cloudbase-init-unattend.conf

[DEFAULT]
username=Administrator
groups=Administrators

inject_user_password=false

verbose=true
debug=false

logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init-unattend.log

check_latest_version=false

allow_reboot=false
stop_service_on_exit=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer

plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.mtu.MTUPlugin

# Adições para o Config Drive / bsdtar
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

Thanks, @EduFrazao.

Generally, this should work out of the box on a freshly installed Linux server with cloud-init, without any extra configuration. Cloud-init should detect the correct method to fetch the data.

One thing that's worth testing more closely is password reset behavior.

For both VR and ConfigDrive, we should run the following test:

1. Request a new password.
2. Reboot the VM.
3. Log in with the new password.
4. Change the password from within the VM.
5. Reboot the VM.
6. Log in with the changed password.

This is to make sure that cloud-init doesn't revert the password, especially when using ConfigDrive.

I'm not sure if you've already tested this or not.

[EduFrazao]

Hi @aleskxyz, @ader1990
Sorry for the late response.
I've run my tests with Windows Server 2019, 2022 and 2025, with ConfigDrive and DataServer (Virtual Router Networking) and everything I tested works.
Initial provisioning, password reset.
Same config works with Linux cloud images (tested with Debian, Alma, Arch, Rocky) and thoses Windows that I prepared.
cloudbase-init.conf

[DEFAULT]
logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init.log
verbose=true
debug=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer
plugins=cloudbaseinit.plugins.common.userdata.UserDataPlugin,cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin

username=Administrator
groups=Administrators

rename_admin_user=false
inject_user_password=true
first_logon_behaviour=no
allow_reboot=true
check_latest_version=false

bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

cloudbase-init-unattend.conf

[DEFAULT]
username=Administrator
groups=Administrators

inject_user_password=false

verbose=true
debug=false

logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init-unattend.log

check_latest_version=false

allow_reboot=false
stop_service_on_exit=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer

plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.mtu.MTUPlugin

# Adições para o Config Drive / bsdtar
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

Thanks, @EduFrazao.

Generally, this should work out of the box on a freshly installed Linux server with cloud-init, without any extra configuration. Cloud-init should detect the correct method to fetch the data.

One thing that's worth testing more closely is password reset behavior.

For both VR and ConfigDrive, we should run the following test:

1. Request a new password.

2. Reboot the VM.

3. Log in with the new password.

4. Change the password from within the VM.

5. Reboot the VM.

6. Log in with the changed password.

This is to make sure that cloud-init doesn't revert the password, especially when using ConfigDrive.

I'm not sure if you've already tested this or not.

Tested!
VM starts with a password generated by cloudstack.
I changed the password. Shutdown.
New password works.

Ask for a password reset on cloudstack.
Works.

Change password again directly on Windows:
Works after reboot and after a complete shutdown.

Tested with VR and ConfigDrive on Windows Server 2025

[aleskxyz]

Hi @aleskxyz, @ader1990
Sorry for the late response.
I've run my tests with Windows Server 2019, 2022 and 2025, with ConfigDrive and DataServer (Virtual Router Networking) and everything I tested works.
Initial provisioning, password reset.
Same config works with Linux cloud images (tested with Debian, Alma, Arch, Rocky) and thoses Windows that I prepared.
cloudbase-init.conf

[DEFAULT]
logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init.log
verbose=true
debug=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer
plugins=cloudbaseinit.plugins.common.userdata.UserDataPlugin,cloudbaseinit.plugins.common.setuserpassword.SetUserPasswordPlugin,cloudbaseinit.plugins.windows.extendvolumes.ExtendVolumesPlugin

username=Administrator
groups=Administrators

rename_admin_user=false
inject_user_password=true
first_logon_behaviour=no
allow_reboot=true
check_latest_version=false

bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

cloudbase-init-unattend.conf

[DEFAULT]
username=Administrator
groups=Administrators

inject_user_password=false

verbose=true
debug=false

logdir=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\log
logfile=cloudbase-init-unattend.log

check_latest_version=false

allow_reboot=false
stop_service_on_exit=false

metadata_services=cloudbaseinit.metadata.services.cloudstack.ConfigDrive,cloudbaseinit.metadata.services.cloudstack.DataServer

plugins=cloudbaseinit.plugins.common.sethostname.SetHostNamePlugin,cloudbaseinit.plugins.common.mtu.MTUPlugin

# Adições para o Config Drive / bsdtar
bsdtar_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\bsdtar.exe
mtools_path=C:\Program Files\Cloudbase Solutions\Cloudbase-Init\bin\
config_drive_cdrom=true
config_drive_vfat=true
config_drive_raw_hhd=true
locations=cdrom

Thanks, @EduFrazao.

Generally, this should work out of the box on a freshly installed Linux server with cloud-init, without any extra configuration. Cloud-init should detect the correct method to fetch the data.

One thing that's worth testing more closely is password reset behavior.

For both VR and ConfigDrive, we should run the following test:

1. Request a new password.

2. Reboot the VM.

3. Log in with the new password.

4. Change the password from within the VM.

5. Reboot the VM.

6. Log in with the changed password.

This is to make sure that cloud-init doesn't revert the password, especially when using ConfigDrive.

I'm not sure if you've already tested this or not.

Tested!
VM starts with a password generated by cloudstack.
I changed the password. Shutdown.
New password works.

Ask for a password reset on cloudstack.
Works.

Change password again directly on Windows:
Works after reboot and after a complete shutdown.

Tested with VR and ConfigDrive on Windows Server 2025

Thanks man! 🫡

[EduFrazao]

Thanks man! 🫡

Thank you for your PR!

[ader1990]

@aleskxyz if you can, https://github.com/cloudbase/cloudbase-init/pull/68/checks -> there are some pep8/flake8 issues with the some lines being too long, can you please fix them?

All good to merge afterwards.

Thanks!

[aleskxyz]

@aleskxyz if you can, https://github.com/cloudbase/cloudbase-init/pull/68/checks -> there are some pep8/flake8 issues with the some lines being too long, can you please fix them?

All good to merge afterwards.

Thanks!

Hi @ader1990
Fixed and local test passed.