From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
"f.gruenbichler@proxmox.com" <f.gruenbichler@proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES v3 pve-storage/qemu-server/pve-qemu] add external qcow2 snapshot support
Date: Mon, 13 Jan 2025 12:54:05 +0100 [thread overview]
Message-ID: <a09b6f3d-c0bc-4694-9735-7a455ae4c209@proxmox.com> (raw)
In-Reply-To: <mailman.247.1736765898.441.pve-devel@lists.proxmox.com>
Am 13.01.25 um 11:57 schrieb DERUMIER, Alexandre via pve-devel:
>> Hmm, sounds like it might a bug, I can look into it. If really
>> required
>> to make it work, we can still set fixed node-names on the
>> commandline,
>> but also query them before usage to be sure we have the correct, i.e.
>> currently inserted node.
>
>>> AFAICT, this is because the node name is not set in the original
>>> options
>>> for the block driver state and then it wrongly detects an attempt to
>>> change the node name (even if specifying the correct auto-generated
>>> one
>>> during reopen). However, it is rather ugly to try and use a -drive
>>> together with blockdev-reopen in any case, blockdev-reopen is really
>>> written with -blockdev in mind and -blockdev necessarily requires
>>> setting node-name up front.
>
> you are too fast ^_^
>
>>> I don't think it's even worth fixing that bug. We should use
>>> blockdev-reopen only after switching to -blockdev, it's much nicer
>>> like
>>> that 🙂
>>>
>>> I'd still be in favor of querying the node-name of drives with
>>> query-block before doing QMP operations though. Like that, we can
>>> warn/error if it doesn't match what we expect for example, to catch
>>> unexpected situations.
>
> ok, so the question is : how to query to node-noname of different disk
> (+snapshot chain).
>
> Fabian is against the use of the path.
>
> So, I'm a little bit out of idea ^_^
>
For almost all QMP commands, we only need to care about the node that's
inserted for the drive. And for your use-case, checking that the top
node of the chain matches what we expect is already a good first step.
The lookup itself is a different question, I'll also answer to the other
mail.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-01-13 11:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 9:12 Alexandre Derumier via pve-devel
2025-01-09 14:13 ` Fabian Grünbichler
2025-01-10 7:44 ` DERUMIER, Alexandre via pve-devel
2025-01-10 9:55 ` Fiona Ebner
2025-01-10 12:30 ` DERUMIER, Alexandre via pve-devel
[not found] ` <8f309dfe189379acf72db07398a37a98e8fc3550.camel@groupe-cyllene.com>
2025-01-13 10:06 ` Fiona Ebner
2025-01-13 10:54 ` Fiona Ebner
2025-01-13 10:57 ` DERUMIER, Alexandre via pve-devel
2025-01-13 11:54 ` Fiona Ebner [this message]
2025-01-13 11:58 ` DERUMIER, Alexandre via pve-devel
[not found] ` <2cbef7d2a33ed5ea6fab15b97f611fc4bf207c0f.camel@groupe-cyllene.com>
2025-01-13 13:42 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a09b6f3d-c0bc-4694-9735-7a455ae4c209@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox