From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.ebner@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 1CE83A78A
for <pve-devel@lists.proxmox.com>; Mon, 7 Aug 2023 14:52:47 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 0492435601
for <pve-devel@lists.proxmox.com>; Mon, 7 Aug 2023 14:52:47 +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 ESMTPS
for <pve-devel@lists.proxmox.com>; Mon, 7 Aug 2023 14:52:46 +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 2A913430E3
for <pve-devel@lists.proxmox.com>; Mon, 7 Aug 2023 14:52:46 +0200 (CEST)
Message-ID: <b81bdeef-9841-e4b8-d228-c8e349dc54dc@proxmox.com>
Date: Mon, 7 Aug 2023 14:52:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.1
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Filip Schauer <f.schauer@proxmox.com>
References: <20230807100802.328313-1-f.schauer@proxmox.com>
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <20230807100802.328313-1-f.schauer@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 2.019 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
NICE_REPLY_A -4.139 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
Subject: Re: [pve-devel] [PATCH qemu] fix #1534: vma: Add extract filter for
disk images
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: Mon, 07 Aug 2023 12:52:47 -0000
Am 07.08.23 um 12:08 schrieb Filip Schauer:
> Add a filter to the "vma extract" command. A wildcard can be passed with
> "-f" to match disk images that should be extracted.
The bug report doesn't mention wildcards, but a list of image names.
Restoring drive-ide2 and drive-scsi0 becomes awkward with a single
pattern and I don't see why a list of just the names shouldn't suffice.
Cases with many disks are rather rare and even in extreme cases it won't
be more than ~30 disks or so. And if users request patterns, we can
still add it on top.
> @@ -2064,12 +2069,12 @@ index 0000000000..304f02bc84
> +
> + int i;
> + int vmstate_fd = -1;
> -+ guint8 vmstate_stream = 0;
> ++ uint8_t filter_bitmap[256 / 8];
I'd rather use a bool array (if the compiler optimizes it to a bitmap
great, otherwise it's still easier to read), but...
> ++ memset(filter_bitmap, 0, sizeof(filter_bitmap));
> +
> + for (i = 1; i < 255; i++) {
> + VmaDeviceInfo *di = vma_reader_get_device_info(vmar, i);
> + if (di && (strcmp(di->devname, "vmstate") == 0)) {
> -+ vmstate_stream = i;
> + char *statefn = g_strdup_printf("%s/vmstate.bin", dirname);
> + vmstate_fd = open(statefn, O_WRONLY|O_CREAT|O_EXCL, 0644);
> + if (vmstate_fd < 0) {
> @@ -2078,6 +2083,16 @@ index 0000000000..304f02bc84
> + }
> + g_free(statefn);
> + } else if (di) {
> ++ if (filter && (fnmatch(filter, di->devname, 0) != 0)) {
> ++ if (vma_reader_register_bs(vmar, i, NULL, true, true, &errp) < 0) {
> ++ g_error("%s", error_get_pretty(errp));
> ++ }
> ++
> ++ continue;
> ++ }
...instead of doing this, you could also just make sure not to allocate
an image when the name is not included and set the skip flag when
calling vma_reader_register_bs(), re-using the existing mechanism for
partial restore.
Does not registering all even work? I thought vma was written in such a
way that it would read everything, which is why the skip logic was
necessary IIRC. Peeking at the code, doesn't restore_write_data() call
restore_write_data() with a dev_id from the backup we didn't register
the stream for at some point otherwise?