From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 753D61FF179 for ; Wed, 12 Nov 2025 20:21:16 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 46771BD14; Wed, 12 Nov 2025 20:22:08 +0100 (CET) Message-ID: <289bbaa2-11ff-48e8-ab91-6d334dce816a@proxmox.com> Date: Wed, 12 Nov 2025 20:22:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox VE development discussion , Filip Schauer References: <20251008171028.196998-1-f.schauer@proxmox.com> <20251008171028.196998-7-f.schauer@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20251008171028.196998-7-f.schauer@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762975298509 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.026 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [lxc.pm] Subject: Re: [pve-devel] [PATCH container v5 06/17] add support for OCI images as container templates X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 08.10.25 um 19:11 schrieb Filip Schauer: > This aims to add basic support for the Open Container Initiative image > format according to the specification. [0] > This commit would do well with including some rationale and describing trade offs and limitations, as do most others for that matter. > [0] https://github.com/opencontainers/image-spec/blob/main/spec.md > > Signed-off-by: Filip Schauer > --- > This patch depends on changes made to proxmox-perl-rs in patch 04/17. > Meaning that proxmox-perl-rs needs to be bumped and a dependency & build > dependency to libpve-rs-perl needs to be added to debian/control. > > Changed since v3: > * correctly handle case where $archive is '-' > * replace unnecessary regex comparisons with `eq` > * pass environment variables to container via `lxc.container.runtime` > > Changed since v2: > * rebase onto newest master (5a8b3f962f16) and re-format with > proxmox-perltidy > * check whether archive is an OCI image before trying to parse it as one > > Changed since v1: > * fix entrypoint command missing Cmd > * set lxc.signal.halt according to StopSignal (Fixes container shutdown) > > src/PVE/API2/LXC.pm | 94 ++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 84 insertions(+), 10 deletions(-) > > diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm > index e53b388..7a44547 100644 > --- a/src/PVE/API2/LXC.pm > +++ b/src/PVE/API2/LXC.pm > @@ -19,9 +19,11 @@ use PVE::Storage; > use PVE::RESTHandler; > use PVE::RPCEnvironment; > use PVE::ReplicationConfig; > +use PVE::RS::OCI; > use PVE::LXC; > use PVE::LXC::Create; > use PVE::LXC::Migrate; > +use PVE::LXC::Namespaces; > use PVE::GuestHelpers; > use PVE::VZDump::Plugin; > use PVE::API2::LXC::Config; > @@ -536,19 +538,91 @@ __PACKAGE__->register_method({ > > eval { > my $rootdir = PVE::LXC::mount_all($vmid, $storage_cfg, $conf, 1); > + my $archivepath = '-'; > + $archivepath = PVE::Storage::abs_filesystem_path($storage_cfg, $archive) > + if ($archive ne '-'); > $bwlimit = PVE::Storage::get_bandwidth_limit( > 'restore', [keys %used_storages], $bwlimit, > ); > - print "restoring '$archive' now..\n" > - if $restore && $archive ne '-'; > - PVE::LXC::Create::restore_archive( > - $storage_cfg, > - $archive, > - $rootdir, > - $conf, > - $ignore_unpack_errors, > - $bwlimit, > - ); > + my $is_oci = 0; > + > + if ($restore && $archive ne '-') { > + print "restoring '$archive' now..\n"; > + } elsif ($archivepath =~ /\.tar$/) { Is there a reason that this got all "shoved" into the API method directly? IMO it would be much nicer to have a method that takes care of this. Btw. did you explore creating a PVE::LXC::Setup::OCI module where most of this is handled, or at least encapsulated? That way the OCI CTs could have a "real" ostype that makes it easy to detect what's going on and allow implied special casing (like if network needs to be set up by the host). It could also base of the "unmanaged" setup module, if there's really nothing else to setup by default. If there's a reason for why that is not a good solution it really needs to be stated so in the commit message, as for me that'd be the obvious first route to explore such an integration. > + # Check whether archive is an OCI image > + my ($has_oci_layout, $has_index_json, $has_blobs) = (0, 0, 0); > + PVE::Tools::run_command( > + ['tar', '-tf', $archivepath], > + outfunc => sub { > + my $line = shift; > + $has_oci_layout = 1 if $line eq 'oci-layout'; > + $has_index_json = 1 if $line eq 'index.json'; > + $has_blobs = 1 if $line =~ /^blobs\//m; > + }, > + ); > + > + $is_oci = 1 if $has_oci_layout && $has_index_json && $has_blobs; > + } > + > + if ($is_oci) { > + # Extract the OCI image > + my ($id_map, undef, undef) = PVE::LXC::parse_id_maps($conf); > + my $oci_config = PVE::LXC::Namespaces::run_in_userns( > + sub { > + PVE::RS::OCI::parse_and_extract_image($archivepath, $rootdir); > + }, > + $id_map, > + ); > + > + # Set the entrypoint and arguments if specified by the OCI image > + my @init_cmd = (); > + push(@init_cmd, @{ $oci_config->{Entrypoint} }) > + if $oci_config->{Entrypoint}; > + push(@init_cmd, @{ $oci_config->{Cmd} }) if $oci_config->{Cmd}; > + if (@init_cmd) { > + my $init_cmd_str = shift(@init_cmd); > + if (@init_cmd) { > + $init_cmd_str .= ' '; > + $init_cmd_str .= join( > + ' ', > + map { > + my $s = $_; > + $s =~ s/"/\\"/g; > + qq{"$_"} > + } @init_cmd, Don't we got a shell quote method in PVE::Tools? And FWIW, $_ is the implied default for lots of perl stuff, so the following (untested!) should do the same: map { s/"/\\"/g; qq{"$_"} } @init_cmd, > + ); > + } > + if ($init_cmd_str ne '/sbin/init') { > + push @{ $conf->{lxc} }, ['lxc.init.cmd', $init_cmd_str]; > + > + # An entrypoint other than /sbin/init breaks the tty console mode. > + # This is fixed by setting cmode: console > + $conf->{cmode} = 'console'; > + } > + } > + > + push @{ $conf->{lxc} }, ['lxc.init.cwd', $oci_config->{WorkingDir}] above would be slightly easier to follow as: push $conf->{lxc}->@*, ... > + if ($oci_config->{WorkingDir}); > + > + if (my $envs = $oci_config->{Env}) { > + for my $env (@{$envs}) { rather: for my $env ($envs->@*) { > + push @{ $conf->{lxc} }, ['lxc.environment.runtime', $env]; same as above w.r.t. ->@* > + } > + } > + > + my $stop_signal = $oci_config->{StopSignal} // "SIGTERM"; > + push @{ $conf->{lxc} }, ['lxc.signal.halt', $stop_signal]; same as above w.r.t. ->@* > + } else { > + # Not an OCI image, so restore it as an LXC image instead > + PVE::LXC::Create::restore_archive( > + $storage_cfg, > + $archive, > + $rootdir, > + $conf, > + $ignore_unpack_errors, > + $bwlimit, > + ); > + } > > if ($restore) { > print "merging backed-up and given configuration..\n"; _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel