From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 7EF181FF29F for ; Thu, 18 Jul 2024 17:51:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id EECB8F5B9; Thu, 18 Jul 2024 17:51:43 +0200 (CEST) Message-ID: <59295e1a-b33f-4c81-b12f-c20b00288017@proxmox.com> Date: Thu, 18 Jul 2024 17:51:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Mira Limbeck References: <20240709151219.346691-1-m.limbeck@proxmox.com> Content-Language: en-US From: Friedrich Weber In-Reply-To: <20240709151219.346691-1-m.limbeck@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.028 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH qemu-server] fix 4493: cloud-init: fix generated Windows config X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel