From: "Max R. Carrara" <m.carrara@proxmox.com>
To: "Song Hu" <kellyhu258@gmail.com>, <pve-devel@lists.proxmox.com>
Subject: Re: Need access to `bin/pve-osd-lvm-enable-autoactivation` (Bug #6652)
Date: Fri, 20 Mar 2026 11:58:30 +0100 [thread overview]
Message-ID: <DH7K1LKSWJ5L.1C5RTYFUFH025@proxmox.com> (raw)
In-Reply-To: <CAA4=k41_FX6EMVR=ZJMVirs-OLLN3sBLK3cStxgFH4kcgiRGvQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
On Fri Mar 20, 2026 at 5:28 AM CET, Song Hu wrote:
> Need access to `bin/pve-osd-lvm-enable-autoactivation` (Bug #6652)
>
> Hi Proxmox team,
>
> I’m running into the issue described in bug #6652 “LVM Autoactivation
> Missing for Ceph OSD LVs”, and I need the helper script
> `bin/pve-osd-lvm-enable-autoactivation` in order to enable autoactivation
> for existing OSD logical volumes.
>
> I’m using:
> - Proxmox VE: 8.x (based on Debian bookworm)
> - pve-manager package: `pve-manager/8.x.x` (you can fill in the exact
> version)
> - Kernel: `6.8.xx-pve` (adjust if needed)
>
> I’ve read the fix series for #6652:
> - v1:
> https://lore.proxmox.com/pve-devel/20250812164631.428424-1-m.carrara@proxmox.com/T/
>
> - v2:
> https://lore.proxmox.com/pve-devel/20250813134028.292213-1-m.carrara@proxmox.com/T/
>
>
> From the “applied: (subset)” reply, I understand that only the first patch
> (changing `PVE/API2/Ceph/OSD.pm`) has been merged so far:
> > Applied the first patch, thanks!
> > [1/2] fix #6652: ceph: osd: enable autoactivation for OSD LVs on creation
>
> > commit: 92bbc0c89fe7331ab122ff396f5e23ab31fa0765
>
> The second patch, which introduces `bin/pve-osd-lvm-enable-autoactivation`
> and adjusts `debian/postinst`, has not been applied yet.
>
> I’ve checked the `pve-manager.git` repository:
> - https://git.proxmox.com/?p=pve-manager.git;a=tree;hb=refs/heads/master
> - https://git.proxmox.com/?p=pve-manager.git;a=tree;hb=refs/heads/stable-8
>
> and I can confirm that `bin/pve-osd-lvm-enable-autoactivation` is not
> present in either the `master` or `stable-8` branches. The `bin/` directory
> contains many other helpers (e.g. `pve-lvm-disable-autoactivation`,
> `pve-init-ceph-crash`, etc.) but not this one.
> Since I’m affected by #6652 on nodes that already have OSDs with missing
> autoactivation, I would like to run this helper script instead of manually
> invoking `lvchange --setautoactivation y` on each LV.
>
Hello!
Yeah, we have been on the fence regarding the
`pve-osd-lvm-enable-autoactivation` helper, because it touches a lot of
things during the "postinst" phase of Debian package installation /
updates. So, since the script is rather invasive to just run in postinst
and given that not many users are affected (you're the first to show up,
in fact), we decided not to merge it, AFAIK.
To answer your questions:
> Could you please clarify:
> 1. Is there an official recommended way to obtain the
> `pve-osd-lvm-enable-autoactivation` script for existing deployments while
> the second patch is still pending?
There currently is not.
> 2. If not, would it be possible to provide a standalone copy of the script
> (e.g. as a downloadable blob or via a tagged commit) that users can safely
> use on production clusters?
I've attached a slightly improved version to this mail -- should
hopefully not be filtered out. This isn't really the same as officially
shipping it with PVE, but I hope that it helps.
NOTE: You still have to reboot the node after running the script.
I'm curious, how many hosts are affected on your end? There shouldn't be
any issues anymore if you update to the latest version of Proxmox VE
right after installation -- then newly created OSDs should have
autoactivation enabled, just as expected.
> 3. Is there a timeline or additional work required before the second patch
> can be merged? I’m happy to help with testing or providing feedback on the
> behavior in a real-world setup.
The help is much appreciated, but given that you're the first and only
person to have also run into this apart from the handful of people on
our Bugzilla, we probably won't package this. Should more people than
expected be affected by this for some reason, we might reconsider,
though.
>
> In the meantime, I’m manually working around the issue by:
>
> - Listing OSD LVs with:
> `lvs --options lv_name,vg_name,autoactivation,active`
> - For LVs named `osd-db-*` or `osd-wal-*` in VGs named `ceph-*` where
> “AutoAct” is empty:
> `lvchange --setautoactivation y <vg_name>/<lv_name>`
> - Then reactivating OSDs as described in the v2 cover letter.
> Any guidance you can provide would be greatly appreciated.
> Thanks,
>
> buladou
Glad that workaround helped so far at least! Let me know if the script
gets the job done, too.
- Max
[-- Attachment #2: pve-osd-lvm-enable-autoactivation --]
[-- Type: text/plain, Size: 3887 bytes --]
#!/usr/bin/perl
use v5.36;
use JSON qw(decode_json);
use PVE::Tools;
my sub ceph_volume_lvm_osd_info : prototype() () {
my $cmd = [
"/usr/sbin/ceph-volume", "lvm", "list", "--format", "json",
];
my $stdout = '';
my $outfunc = sub($line) {
$stdout .= "$line\n";
};
my $stderr = '';
my $errfunc = sub($line) {
$stderr .= "$line\n";
};
eval {
PVE::Tools::run_command(
$cmd,
timeout => 10,
outfunc => $outfunc,
errfunc => $errfunc,
);
};
if (my $err = $@) {
$err = "$err\n" if $err !~ m/\n$/;
print STDERR $stderr;
*STDERR->flush();
die $err;
}
my $osd_info = decode_json($stdout);
return $osd_info;
}
my sub lvs : prototype() () {
my $cmd = [
"/usr/sbin/lvs",
"--noheadings",
"--separator",
":",
"--options",
"lv_name,vg_name,autoactivation",
];
my $all_lvs = {};
my $outfunc = sub($line) {
$line = PVE::Tools::trim($line);
my ($lv_name, $vg_name, $autoactivation) = split(':', $line, -1);
return undef if ($lv_name eq '' || $vg_name eq '');
$all_lvs->{"$vg_name/$lv_name"} = {
autoactivation => $autoactivation,
};
};
my $stderr = '';
my $errfunc = sub($line) {
$stderr .= "$line\n";
};
eval {
PVE::Tools::run_command(
$cmd,
timeout => 10,
outfunc => $outfunc,
errfunc => $errfunc,
);
};
if (my $err = $@) {
$err = "$err\n" if $err !~ m/\n$/;
print STDERR $stderr;
*STDERR->flush();
die $err;
}
return $all_lvs;
}
my sub main : prototype() () {
my $osd_info = ceph_volume_lvm_osd_info();
my $all_lvs = lvs();
my $re_uuid4 = qr/
\b
[0-9a-fA-F]{8}
- [0-9a-fA-F]{4}
- [0-9a-fA-F]{4}
- [0-9a-fA-F]{4}
- [0-9a-fA-F]{12}
\b
/x;
# $re_lv_name and $re_vg_name specifically match the LV and VG names we
# assign in OSD.pm in order to avoid modifying LVs created through means
# other than our API.
# Also include osd-block LVs for good measure.
my $re_lv_name = qr/^ osd-(db|wal|block) - $re_uuid4 $/nx;
my $re_vg_name = qr/^ (ceph) - $re_uuid4 $/nx;
my @osd_lvs_no_autoactivation = ();
for my $osd (keys $osd_info->%*) {
for my $osd_lv ($osd_info->{$osd}->@*) {
my ($lv_name, $vg_name) = $osd_lv->@{qw(lv_name vg_name)};
next if $all_lvs->{$osd_lv}->{autoactivation};
next if $lv_name !~ $re_lv_name;
next if $vg_name !~ $re_vg_name;
my $osd_lv = "$vg_name/$lv_name";
push(@osd_lvs_no_autoactivation, $osd_lv) if !$all_lvs->{$osd_lv}->{autoactivation};
}
}
my $has_err = 0;
# Logical volumes are formatted as "vg_name/lv_name", which is necessary for lvchange
for my $lv (@osd_lvs_no_autoactivation) {
my $log = '';
my $logfunc = sub($line) {
$log .= "$line\n";
};
eval {
my $cmd = [
'/usr/sbin/lvchange', '--setautoactivation', 'y', $lv,
];
PVE::Tools::run_command(
$cmd,
logfunc => $logfunc,
timeout => 10,
);
};
if (my $err = $@) {
$has_err = 1;
$err = "$err\n" if $err !~ m/\n$/;
print STDERR $log;
*STDERR->flush();
warn("Error: Failed to enable autoactivation for Ceph OSD logical volume '$lv'\n");
warn("$err");
next;
}
}
if ($has_err) {
warn("Couldn't enable autoactivation for all Ceph OSD DB/WAL/BLOCK logical volumes.\n");
exit 1;
}
return undef;
}
main();
prev parent reply other threads:[~2026-03-20 10:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 4:28 Song Hu
2026-03-20 10:58 ` Max R. Carrara [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=DH7K1LKSWJ5L.1C5RTYFUFH025@proxmox.com \
--to=m.carrara@proxmox.com \
--cc=kellyhu258@gmail.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.