[pve-devel] [PATCH qemu-server] fix 4493: cloud-init: fix generated Windows config

Mira Limbeck m.limbeck at proxmox.com
Mon Jul 22 12:01:49 CEST 2024


Thank you for testing it!

On 7/18/24 17:51, Friedrich Weber wrote:
> On 09/07/2024 17:12, Mira Limbeck wrote:
>> cloudbase-init, a cloud-init reimplementation for Windows, supports only
>> a subset of the configuration options of cloud-init. Some features
>> depend on support by the Metadata Service (ConfigDrive2 here) and have
>> further limitations [0].
>>
>> To support a basic setup the following changes were made:
>>  - password is saved as plaintext for any Windows guests (ostype)
>>  - DNS servers are added to each of the interfaces
>>  - SSH public keys are passed via metadata
>>
>> Network and metadata generation for cloudbase-init is separate from the
>> default ConfigDrive2 one so as to not interfere with any other OSes that
>> depend on the current ConfigDrive2 implementation.
> 
> I tested the following:
> 
> - Install cloudbase-init beta in a Windows 2022 Server VM
> - Shutdown VM
> - Attach cloudinit drive, set network config
> - Start VM
> - After some time, Windows renames itself to the VM name and reboots
> - Network config gets applied after some time (see below)
> 
> One thing I noticed: Without modifying the the standard in-guest
> cloudbase-init configuration, it takes ~2min until cloudbase-init does
> anything (in particular apply the network config). Apparently
> cloudbase-init tries to find an HTTP server with the cloudinit data
> first, and only looks into the configdrive after a timeout.
> 
> To avoid that, Mira suggested to change `metadata_services` [1] in the
> cloudbase-init config to
> `cloudbaseinit.metadata.services.configdrive.ConfigDriveService`.
> Indeed, with this setting the network config gets applied immediately on
> boot. It may be nice to add this to the documentation.
>
I'll add the `metadata_services` config option to the docs as well in a v2.

> I'm not sure if the default behavior of changing the hostname to match
> the VM name is something that Windows admins expect? Should the docs
> mention more prominently how to disable this?

I'd say it makes sense to use the VM name as hostname. This keeps the
names in sync and makes it easy to match one to the other.
Would you like to make it configurable via VM config instead? Or what
would you expect?

> 
>> There seems to be an issue with the network adapter. Whenever the guest
>> is shutdown and started again it finds a new network adapter. Rebooting
>> instead of shutting down doesn't show the same behavior.
>>
>> I'm not sure yet why this happens, but it seems to be caused by
>> cloudbase-init.
> 
> I couldn't reproduce this issue so far (using a virtio NIC).





More information about the pve-devel mailing list