From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 5A9E49A78B for ; Fri, 17 Nov 2023 13:37:34 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3142E32C7C for ; Fri, 17 Nov 2023 13:37:04 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 17 Nov 2023 13:37:02 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 66F2E43DE6 for ; Fri, 17 Nov 2023 13:37:02 +0100 (CET) Message-ID: <1e4ed889-71a6-4b22-81c4-dbe66e5b2575@proxmox.com> Date: Fri, 17 Nov 2023 13:37:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US From: Friedrich Weber To: Fiona Ebner , Proxmox VE development discussion Reply-To: Proxmox VE development discussion References: <20231113170916.184994-1-f.weber@proxmox.com> <20231113170916.184994-2-f.weber@proxmox.com> <39993056-a0d8-418b-8abd-71df1b86be99@proxmox.com> <7b260560-7394-4908-bd85-42f0c6f517d2@proxmox.com> In-Reply-To: <7b260560-7394-4908-bd85-42f0c6f517d2@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.123 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH docs 1/2] pci passthrough: mention incompatibility with ballooning 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: , X-List-Received-Date: Fri, 17 Nov 2023 12:37:34 -0000 I took another look at ballooning+PCI passthrough and reporting of memory usage with Markus. Apparently QEMU does not *always* map the complete guest memory -- at least it didn't with a passed-through NIC. So both the warning as well as the docs section may be worded too strongly ("Ballooning is not possible", "VM will use maximum configured memory", "QEMU needs to map" ...). I'll have to take another look at this to see how we can phrase this correctly (and hopefully somewhat precisely) for v2. On 14/11/2023 11:20, Friedrich Weber wrote: > On 14/11/2023 09:30, Fiona Ebner wrote: >> Am 13.11.23 um 18:09 schrieb Friedrich Weber: >>> >>> +xref:qm_ballooning[Automatic memory allocation (ballooning)] is not possible >>> +when using PCI(e) passthrough. As the PCI device may use DMA (Direct Memory >>> +Access), QEMU needs to map the complete guest memory on VM startup. Hence, the >>> +QEMU process will use at least the (maximum) configured amount of VM memory and >>> +setting a minimum amount does not have any effect. When using PCI(e) >>> +passthrough, it is recommended to set memory and minimum memory to the same >>> +amount and keep the balloning device enabled. However, keep in mind that the >> >> typo: s/balloning/ballooning/ > > Oops, thanks. > >> Is there any advantage to keeping the ballooning device enabled? >> >>> +memory consumption reported in the GUI for the VM may be much lower than the >>> +memory consumption of the QEMU process. >> >> Maybe mention what the reported value is? > > In my understanding: If the ballooning device is enabled (and a balloon > driver present in the guest), the VM memory usage numbers are taken as > reported by the balloon driver [1] (I'd say "as seen from within the > guest"?). If the ballooning device is disabled, they are inferred from > the rss and vsize of the QEMU process [2], so I'd say "as seen from the > host". > > I guess in the end the user has to decide which perspective they care > about? I'll try to make this clearer in the v2. > > [1] > https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer.pm;h=c465fb6f64ae30dec5112fc4439f9181c2eba4e9;hb=feb51881d#l3013 > [2] > https://git.proxmox.com/?p=qemu-server.git;a=blob;f=PVE/QemuServer.pm;h=c465fb6f64ae30dec5112fc4439f9181c2eba4e9;hb=feb51881d#l2967 > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > >