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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 31464638CA for ; Mon, 5 Oct 2020 15:42:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1B4D01B04C for ; Mon, 5 Oct 2020 15:42:10 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id C08951B03F for ; Mon, 5 Oct 2020 15:42:08 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 88E0D4545B; Mon, 5 Oct 2020 15:42:08 +0200 (CEST) To: Proxmox Backup Server development discussion , Graeme Seaton References: <7072d246-960d-1d1b-be3f-04edb39e8033@graemes.com> From: Thomas Lamprecht Message-ID: <32fe64ea-90b4-abb4-85e9-324420e9776c@proxmox.com> Date: Mon, 5 Oct 2020 15:42:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Thunderbird/82.0 MIME-Version: 1.0 In-Reply-To: <7072d246-960d-1d1b-be3f-04edb39e8033@graemes.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.153 Adjusted score from AWL reputation of From: address 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) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] Templates starting on backup X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 13:42:40 -0000 Hi, On 05.10.20 14:15, Graeme Seaton wrote: > I store my templates on a common host and move to deployment host as ne= cessary.=C2=A0 Unfortunately, when backup up the process tries to start t= he template and then fails if there is a difference in the hardware confi= guration between the current host and it's definition. >=20 > Given that templates (if I understand correctly) are not run directly s= houldn't the backup just work with the images since there won't be any di= rty blocks to be detected? >=20 Yes, they have no dirty bitmap by definition, but we start them up so tha= t we can re-use our QEMU backup integration for PBS. The VM is not started = for real, just a QEMU process is running - this shows up in the webinterface (because it's a cheap check) - but the backup lock symbol should avoid confusions. Re-using the QEMU built in block drivers to access the templates disks al= lows to avoid duplicating quite some logic and functionality, and solves a few= edge cases "for free". That's the main reason we use it here. What HW differences are talking here? cheers, Thomas