From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.weber@proxmox.com>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <f.weber@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=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
>
>