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

[Friedrich Weber]

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'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?

> 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).