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 UTF8SMTPS id 1B817713C6 for ; Thu, 10 Jun 2021 13:28:30 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with UTF8SMTP id 0F72E2E3AB for ; Thu, 10 Jun 2021 13:28:30 +0200 (CEST) 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 UTF8SMTPS id 2E2232E3A0 for ; Thu, 10 Jun 2021 13:28:29 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with UTF8SMTP id F4129465F9; Thu, 10 Jun 2021 13:28:28 +0200 (CEST) Message-ID: <5c144071-bc03-3a27-3240-d2160dae60c4@proxmox.com> Date: Thu, 10 Jun 2021 13:28:27 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Thunderbird/90.0 Content-Language: en-US To: Stefan Reiter , Proxmox VE development discussion References: <20210610073719.26504-1-d.csapak@proxmox.com> <7c83fc86-6c20-b9bd-e72b-b7d2d2a8c216@proxmox.com> From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.941 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH manager] ui: file-restore: start the file-restore on the selected node 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: Thu, 10 Jun 2021 11:28:30 -0000 On 6/10/21 11:29, Stefan Reiter wrote: > On 6/10/21 10:40 AM, Dominik Csapak wrote: >> On 6/10/21 10:23, Stefan Reiter wrote: >>> On 6/10/21 9:37 AM, Dominik Csapak wrote: >>>> and not the node where the browser connects. >>>> there are at least two good reasons for this: >>>> * it is confusing, since the user would expect it to start where >>>>    the ui is pointint to >>>> * the storage may not be available on the node the browser connects >>>>    to, but it must be available on the node selected in the ui >>>> >>>> Signed-off-by: Dominik Csapak >>>> --- >>> >>> Does this work with the proxying code for downloading files? I >>> believe my original reasoning behind this was because my >>> implementation for quickly forwarding data between the unprivileged >>> and privileged daemons uses a local Unix socket. Thus forwarding >>> between nodes (as I understand this will do?) would be subject to >>> caching the data at the node being contacted, before sending it to >>> the browser. >> >> well it does work, since i sucessfully downloaded some files from a >> backup >> >> what exactly do you mean with >>  > would be subject to caching the data at the node being >>  > contacted, before sending it to the browser. >> > > Try downloading a larger file (multiple GB) - is it streamed directly to > the browser or first transferred to node1 (from your example below), > cached in memory there, and only once it's fully in RAM transferred to > the client? I believe with this patch, the second variant will happen. > > This whole idea was the reason for these shenanigans: > https://git.proxmox.com/?p=pve-http-server.git;a=commitdiff;h=51841e98fa5d4ad4d5b5250523c45f88769c577f > > from a short test it seem you're right (have a pveproxy worker that sits at 2GiB RES atm) but the solution here is probably to drop the 'proxyto' in the api call, and do the same as we do for vnc proxying? ssh tunnel and starting the file restore on the target node >> yes the download api call goes afaiu >> >> proxy@node1(the one the browser connects to) -> >> proxy@node2 (node selected from tree) -> >> daemon@node2 -> >> vm@node2 >> >>>