From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: applied: [PATCH v2 qemu-server] cloud-init: commit: activate volume early enough to fix regression with qcow2 on LVM
Date: Mon, 17 Aug 2026 14:29:46 +0200 [thread overview]
Message-ID: <1a0890cd-f5f7-450f-8408-25618aecb061@proxmox.com> (raw)
In-Reply-To: <20260817103032.73185-1-f.ebner@proxmox.com>
Am 17.08.26 um 12:30 PM schrieb Fiona Ebner:
> Since pve-storage commit 05032c5 ("fix #7811: storage: lvm: reject
> allocation on format and volume name mismatch") and its follow-ups,
> cloud-init disks are named with a '.qcow2' extension on LVM storages
> with snapshot-as-volume-chain enabled.
>
> This causes a regression, because volume_size_info() fails and returns
> undef when the qcow2 volume is not active. When the size cannot be
> determined, commit_cloudinit_disk() function assumes that the disk
> does not yet exist and tries to allocate new disk with the same name,
> which fails.
>
> # qm start 100
> failed to stat '/dev/lvm/vm-100-cloudinit.qcow2'
> Rounding up size to full physical extent 8.00 MiB
> lvcreate 'lvm/vm-100-cloudinit.qcow2' error: Logical Volume
> "vm-100-cloudinit.qcow2" already exists in volume group "lvm"
>
> Fix the issue by activating the volume early enough.
>
> Note that activate_volumes() also activates the storage, which fixes
> another bug, since nothing ensured that the storage was active before.
> For a VM with just the cloud-init disk on the 'nfs' storage:
>
> # umount /mnt/pve/nfs && qm start 100
> failed to stat '/mnt/pve/nfs/images/100/vm-100-cloudinit.raw'
> disk image '/mnt/pve/nfs/images/100/vm-100-cloudinit.raw' already exists
>
> Once there is a proper existence check function in the storage layer,
> that can be used instead. For vdisk_list(), not all plugin
> implementations filter early for $vollist, so there can be overhead
> and some plugins even might fail when there are issues with unrelated
> volumes. Even if using an eval block, if the cloud-init volume already
> exists, but vdisk_list() fails, it would be detected as the volume not
> existing and then allocation would fail. The current approach with
> activation avoids that an issue with a different volume blocks VM
> start.
>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Applied, with Dominik's feedback incorporated, thank you very much for
the review!
[1/1] cloud-init: commit: activate volume early enough to fix regression
with qcow2 on LVM
commit f0c2cc3bee10daadd153cbfae8e92d5678032a6a
prev parent reply other threads:[~2026-08-17 12:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 10:29 [PATCH v2 qemu-server] cloud-init: commit: activate volume early enough to fix regression with qcow2 on LVM Fiona Ebner
2026-08-17 11:25 ` Dominik Csapak
2026-08-17 11:29 ` Fiona Ebner
2026-08-17 12:29 ` Fiona Ebner [this message]
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=1a0890cd-f5f7-450f-8408-25618aecb061@proxmox.com \
--to=f.ebner@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.