From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id A16D01FF2D9 for ; Mon, 22 Jul 2024 12:01:20 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 51DDA1FE4C; Mon, 22 Jul 2024 12:01:53 +0200 (CEST) Message-ID: Date: Mon, 22 Jul 2024 12:01:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Friedrich Weber , Proxmox VE development discussion References: <20240709151219.346691-1-m.limbeck@proxmox.com> <59295e1a-b33f-4c81-b12f-c20b00288017@proxmox.com> Content-Language: en-US From: Mira Limbeck In-Reply-To: <59295e1a-b33f-4c81-b12f-c20b00288017@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.314 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" 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). _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel